Jump to content

Recommended Posts

Posted
10 hours ago, RUSerious said:


Via win10, I’ve got all the BCD files in place on a stick for it to be bootable.
And WinNTSetup 5.2.6 gives stick 3 green lights as a Boot drive;  But I know from previous boot attempts that this stick is not BIOS bootable -- will not be seen during boot process.
Is there any way for WinNTSetup, or any windows app, to see this BIOS bootable bit within a stick’s ‘firmware’?
Thanks for the awesome app!!

Maybe the issue is "elsewhere", there is no reason why a "normal" USB stick (properly prepared/partitioned/formatted) should not be bootable.

There is actually in the USB stick controller a "flippable" bit that can tell to the OS whether the device is "removable" or "fixed", but that does not change if it is bootable or not.

The issue could be related to the motherboard BIOS/UEFI settings or (for whatever reasons) expecting something "particular".

Is that MBR or GPT?

And are you booting BIOS or UEFI?

You could start a new thread, possibly here:

https://msfn.org/board/forum/169-hard-drive-and-removable-media/

detailing the make/model of the stick, how you partitioned/formatted it, etc., and  we could check it and (hopefully) find out a way to make it bootable (up to loading - say - the BOOTMGR and BCD ).

jaclaz


Posted (edited)
5 hours ago, jaclaz said:

There is actually in the USB stick controller a "flippable" bit that can tell to the OS whether the device is "removable" or "fixed", but that does not change if it is bootable or not.
jaclaz

Big thanks for your reply, correction, and link to more relevant thread.
Using the same setup used for many other USB sticks with no problems. BIOS MBR win10 64bit.
Booting an OS within a VHDX on a USB stick seems to be a very good stress test for a USB stick.  Most cheap sticks don’t make it through the first boot attempt. I’m guessing a desire to use lower quality chips without any heat ‘ speed adaptations.  Some sticks will also hang the boot process.  Had one SanDisk Extreme stick where SanDisk went back and forth (fixed or not) on the exact same model.  I came to the conclusion at the time -- from info I could find -- that a stick ’HDD’ was not bootable because it was not seen as fixed.  I must be missing some other issue tied to this.  Thanks again for the reply / correction / direction.

edit:
https://msfn.org/board/topic/184310-any-relation-between-a-usb-stick-being-bootable-or-not-and-fixed-or-not-‘-removable/

Edited by RUSerious
Posted (edited)

well, ultimate \Programdata, \Windows, \windows\system32 and \windows\syswow64 subfolder purge.

 

the following subfolders might as well not be present in your win10 and/or win11 miniwin, without any prejudice to ordinary functionality (unless otherwise proven or informed):

 

\programdata\Dbz33C09

\programdata\Dbz717CC

\programdata\ProductData.BackupByPortableAppC

\windows\BrowserCore

\windows\CbsTemp

\windows\CSC

\windows\IdentityCRL

\windows\L2Schemas

\windows\LastGood.Tmp

\windows\Migration

\windows\Pbr

\windows\PLA

\windows\schemas

\windows\SecureBootUpdates

\windows\security

\windows\SKB

\windows\System

\windows\addins

\windows\bcastdvr

\windows\System32\Hydrogen

\windows\System32\ias

\windows\System32\icsxml

\windows\System32\inetsrv

\windows\System32\Ipmi

\windows\System32\Licenses

\windows\System32\MSDRM

\windows\System32\MUI

\windows\System32\NDF

\windows\System32\networklist

\windows\System32\PerceptionSimulation

\windows\System32\ProximityToast

\windows\System32\ras

\windows\System32\RasToast

\windows\System32\Sgrm

\windows\System32\SystemResetPlatform

\windows\System32\wbem

\windows\System32\WCN

\windows\System32\0409

\windows\System32\AdvancedInstallers

\windows\System32\AppLocker

\windows\System32\appraiser

\windows\System32\AppV

\windows\System32\Bthprops

\windows\System32\ContainerSettingsProviders

\windows\System32\DAX2

\windows\System32\DAX3

\windows\System32\DDFs

\windows\System32\downlevel

\windows\System32\DriverState

\windows\System32\dsc

\windows\System32\FxsTmp

\windows\System32\GroupPolicy

\windows\System32\GroupPolicyUsers

 

and all \windows\syswow64 subfolders except downlevel and the language folder ??-?? (en-US or the like).

 

I have been running my miniwin for a couple of days and I have not seen any different behavior from when the above was there.

In any case, I recommend finishing off the customization of your OS before deleting the above subfolders. 

 

Edited by Antonino
Posted

Please use code tags.

Your list is a bit radical. Most of them are empty folder or space gain is minimal.
Deleting wbem folder saves some space but will break all applications that uses WMI.

Downlevel folder should be save, if recall correctly it's only be used while servicing from older WinOS.
(like Win7/8 uses dism to add drivers to offline Win10/11 system)

Posted (edited)

Sorry Jfx, what I took for granted was keeping a copy of the newly/recently configured/customized windows install to one's own needs before miniwinning and deleting all the stuff I listed. Supposing u have a new nvidia or ati driver to install, u can resort to your latest wim or esd that u will have saved soon after the customization and install the new driver from there before reminiwinning  and redeleting all. it takes about 15 minutes for newbies if u keep it all together. That is exactly why I recommended keeping an "original" wim or esd to restart from. it is about a couple of clicks if u have it all there. If I were to try and install a new nvidia driver on the miniwinned version online, I would have trouble even without having deleted downlevel (but this is probably not applicable to my scenario, as the driver transfer would be from win10 to win10/11, not from win7/8). that is why at every nvidia update i go wim/esd --> vhd --> nvidia install --> miniwinning --> final retrimming with the above, and so on and so forth. and to tell u the truth one does not even need to keep all nvidia content (all it takes is try deleting the whole nv_blablabla driverstore filerepository subfolder while a game or something is on and leave the undeleted files alone, which are the crucial ones) - the procedure spares/clears a good 1.7gb.

as for wbem, what are the applications that use wmi?

what are code tags?

 

 

Edited by Antonino
Posted

I mean format these lines you posted with the forums code button.
As for WMI applications there no easy telling, many using it, but seems to work without it.

Posted (edited)

do u mean I should name the topic? I thought it could be considered a follow-up from the miniwinning process, as further and wider deletions to make the vhd smaller. to this end, I did discover a glitch, apparently due to taking out so much stuff in the end. At least one subfolder (do not yet know which one) should not be deleted, inasmuch as it is responsible for letting, say, directx install. Now, until I find out which subfolder it is, I cannot install directx if need be, the error being "the log on user does not enjoy the necessary privileges to run this executable, or things like that. it is not much of a problem, as one should have installed directx and the like before, but just in case one has forgotten to do it, why not let him do it now. I will see u in a bit to tell u which directory I should not have taken out.

Well, I have to admit that, no subfolder of the above list is the culprit of the above problem, which must entirely rest upon mysoftware.txt. I have just tried deleting each of the subfolders one by one on a freshly-made vhd and ... no issues whatsoever. All this means that I have always had a final miniwinned vhd that has never worked on certain exe files. I didn't realize it any earlier than these days because I had never gotten around to trying to install anything after miniwinning. However, for clarity's sake, I will take good care to check mysoftware.txt for any line that could have caused the issue. for the time being, I am happy to learn that all my suggested deletions have caused no issues so far. My point was only that a great many subfolders (of course not all of them) are without basis for want when it comes to normal miniwin "unmixedreality" win7-like operations. the system seems to be fundamentally based on system32 dll's (and a tiny bit on syswow64 dll's as well). But of course I welcome anybody who begs to differ not to hesitate to do so.  

 

 

 

Edited by Antonino
Posted (edited)

It's seems to run a diskpart script and assign S: and W:, then calls WinNTSetup like this:

WinNTSetup_x64 NT6 -source:"D:\sources\install.wim" -wimindex:1 -syspart:S: -tempdrive:W: -unattend:"path_unattend.xml" -compact:xpress4k

PS: See, F1 -Help for command line options

Edited by JFX
  • JFX changed the title to WinNTSetup v5.2.6 / 5.3 Beta 7
Posted

WinNTSetup 5.3 Beta 7

- workaround windows 7 Dism /add-driver bug 30 (AMD, NVIDIA drivers with LZSS compression)
- workaround EFI NTFS driver bug
- fixed capture problem with OneDrive On-Demand files
- added combobox script selection to diskpart window
- added -diskpart command line switch to bring up diskpart window
- added WIM_MSG_ERROR and WIMLIB_PROGRESS_MSG_HANDLE_ERROR Messagebox choice
 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...