245 replies to this topic

[antonino61]

.
Some generic Windows 7, 8, 10 ideas:

Include early use drivers to the vhd only (text mode boot).
In addition: are these drivers ntfs compressed? Bootmgr can read ntfs compressed files.
Gui mode drivers can be linked to the wim file.

Open the registry HKLM\System\CurrentControlSet\Services
Early boot drivers are marked at different ways.
BootFlags has a very high priority.
And Start=0 drivers are loaded early.

But several hardware depending drivers are Start=0 at install.wim.
At installation, StartOverride is set to unused drivers, these drivers are disabled at current hardware.
If you like to boot at different hardware, then delete StartOverride and add the driver *.sys files to the vhd image.

Enable bootlog at bcd file. And read ntbtlog.txt after boot.
All files before mup.sys are used early at boot.
Create a new WimBootCompress.ini, include required system32\drivers only.

 

thank you so much for the tip; when i call regedit and reach hklm, etc, at services, all i see is folderlike, not filelike, stuff, never mind flags. all "folders" look the same.

nino

[Wonko the Sane]

thank you so much for the tip; when i call regedit and reach hklm, etc, at services, all i see is folderlike, not filelike, stuff, never mind flags. all "folders" look the same.

nino

Sure, that is the way regedit shows info in the Registry.

 

Try having a look with Serviwin:

https://www.nirsoft....s/serviwin.html

 

Wonko

[antonino61]

Ok,Wonko, thx, I definitely will.
Nino

[alacran]

Try having a look with Serviwin:

https://www.nirsoft....s/serviwin.html

 

Wonko

 

Fantastic tool, it lets you see all the picture on only two selectable screens, one for drivers and the other for services.

 

I would like to recomment this other tool, not for same use but very usefull too to deal with Registry: Reg Converter

 

alacran

[Wonko the Sane]

Fantastic tool, it lets you see all the picture on only two selectable screens, one for drivers and the other for services.

 

I would like to recomment this other tool, not for same use but very usefull too to deal with Registry: Reg Converter

 

alacran

We risk to go into making a list of useful tools (which may not be appropriate for this thread) however, this is another useful tool when you are making (crazy ) tests with the Registry contents:

https://www.nirsoft....anges_view.html

 

Wonko

[antonino61]

.
Some generic Windows 7, 8, 10 ideas:

Include early use drivers to the vhd only (text mode boot).
In addition: are these drivers ntfs compressed? Bootmgr can read ntfs compressed files.
Gui mode drivers can be linked to the wim file.

Open the registry HKLM\System\CurrentControlSet\Services
Early boot drivers are marked at different ways.
BootFlags has a very high priority.
And Start=0 drivers are loaded early.

But several hardware depending drivers are Start=0 at install.wim.
At installation, StartOverride is set to unused drivers, these drivers are disabled at current hardware.
If you like to boot at different hardware, then delete StartOverride and add the driver *.sys files to the vhd image.

Enable bootlog at bcd file. And read ntbtlog.txt after boot.
All files before mup.sys are used early at boot.
Create a new WimBootCompress.ini, include required system32\drivers only.

well, Wonko advised that I should use serviwin in order to get around to seeing files, rather than folders, which i did. the do look different in color to me blue, black and 2 red ones. what other differences should i look for? as for mup.sys shall I check them in time order or shall I use any other criterion? there is a whole lot of files loaded, so it is hard for me to see what before or after mup.sys means? do u mean in terms of loading time in the booting routine?

[antonino61]

In general, I would like to take the opportunity of enthusing at this community for all their knowledge, expertise, work and dedication. The scientific, probably a little unempirical, penchant characterizing the top brass of it would also lead me to think that such efforts should translate into an overall sensitization of most windows users to a new way of considering windows, its size, scope, setup and deployment. I am not exaggerating if I say that some of these previous days I even installed windows a dozen times without even being aware of it, as I have always done without conventional setup. There was no need for that. Everything worked as it was doing during the previous "edition". This is quite a long way from all our headaches with windows95 to 8.1. One thing I have realized myself, now that I have tried the same, or rather, the most similar things, on 3 machines, a workstation, a laptop and a hybrid tablet pc (asus transformer 101). No need to restore anything, one only has to save the previous wim+vhd set on a per-machine basis just in case anything goes wrong with the present one. Is there any of u going to set windows up the conventional way any longer? 

Another thing I found out is a little bit more technical: the less powerful and roomy the machine, the bigger the happy threshold size of the vhd and the wim, at least here (8gb to 18gb from most powerful to least powerful). I have even tried no compression at all on both, but the sizes grow insanely (especially the vhd one). 

Some windows file and folder behavior makes me think that everything would have been much finer with no file and folder permission hierarchy at all (e.g., who tells us that when something goes wrong the culprit is a missing file or a hidden file or a protected file, and so on and so forth?) just thinking out loud.

nino

[alacran]

If we want to make a backup of our wimboot source file and VHD we may follow the procedure from my old post: http://reboot.pro/to...e-6#entry191800

 

Make a copy of the file containing the source wim, and using 7 zip compression Maximum or Ultra make a compressed copy of the VHD, this will save a lot of space.

 

This will work only if you put again on same drive it was before the source folder/file and decompress there the VHD, if you do this on another drive, this DO NOT WORK.

 

alacran

 

EDIT: If we compress with 7-zip Utra my 1.5 GB 10x64-WB.vhd file it will be a 10x64-WB.7z  file having 102 MB size, and reduction is 93.359375 % from original size (1.5 GB).

[Wonko the Sane]

f we want to make a backup of our wimboot source file and VHD ...

...

 

This will work only if you put again on same drive it was before the source folder/file and decompress there the VHD, if you do this on another drive, this DO NOT WORK.

Very useful as a backup in case of drive failure or others cases where you would actually want/need a backup. 

 

Maybe we could call it "half-@§§ed temporary (compressed) copy" instead. 

 

@antonino61

BootFlags:

https://docs.microso...rvice-directive

 

 

Wonko

[alacran]

Very useful as a backup in case of drive failure or others cases where you would actually want/need a backup. 

 

Maybe we could call it "half-@§§ed temporary (compressed) copy" instead. 

 

@antonino61

BootFlags:

https://docs.microso...rvice-directive

 

 

Wonko

 

You can call it the way you want, after all we live in a free world.

 

But the wim is already compressed, only way to save space is compress the VHD, make a wim image of VHD do not work, since you have to redeploy it in a new VHD and keep the new wim,  capturing both VHD and source wim in a new wim and latter extract them do not work too, so I'm trying to suggest the best option I have found to save some space.

[alacran]

Only to make a few more clear my previous 2 posts:

 

When I said:

 

If we want to make a backup of our wimboot source file and VHD we may follow the procedure from my old post: http://reboot.pro/to...e-6#entry191800

 

Make a copy of the file containing the source wim, and using 7 zip compression Maximum or Ultra make a compressed copy of the VHD, this will save a lot of space.

 

This will work only if you put again on same drive it was before the source folder/file and decompress there the VHD, if you do this on another drive, this DO NOT WORK.

 

alacran

 

And if you were read the link you should know this was tested after formating and then puting back the source wim and the VHD (better in this order just in case, because there are pointers into the VHD and they are pointing to the wim).

 

When I said:

 

This will work only if you put again on same drive it was before the source folder/file and decompress there the VHD, if you do this on another drive, this DO NOT WORK.

 

This means if my VHD + wim are originaly on internal hd1,5 (as they are now) and latter I put them on hd0,1 it will not boot.

 

The wim file could be at the begining lets say on hd1,4 and the VHD on hd1,5 and as far as I put each one back on its previous location all will be fine.

 

You can use the same wim file and just copy it to any location you want, but the VHD needs to be created, and the OS installed (wimboot mode) into it, on each disk location, (and it will be pointing to the wim location), fortunately this is made very fast, and then we may make a 7-Zip of the VHD that can be kept anywhere and latter expanded again on previous location if required, since the VHD contains the OS it is more susceptible to potential failures than the source wim file.

 

So you can't make only one set of files on your internal HD and just copy them to your USB, this DO NOT work.

 

IMHO the reason of this is the VHD has into it only a few uncompressed file/folders and all the rest is only Pointers (junctions or soft links made by means of Reparse Points) and we destroy the pointers if we change the location, of course I don't know the details of this since it is propietary information, and there is not many info available about this subject (Wimboot). Only things I can tell you is the info gotten through experimentation and experience.

 

Only other backup option is make a backup image/copy using Ghost, Acronis or similar of the full HD or partition(s) as required (long/slow process). And when restoring do it to the previous locations.

 

Hope this time I expressed the idea more clearly.

 

alacran

[antonino61]

once u ultracompress the vhd, and leave it where it is, with the wim file where it has always been, can u deploy the vhd as it is, or do u have to unultracompress it before deploying it back again? and if u can, to what avail? saving space, time or both?

[Wonko the Sane]

@alacran

You see , "same location" or "same drive position" is different from "same drive".

 

What you have into the VHD (whatever they are) cannot be "hard links" (hard links can only be on same - NTFS - volume), maybe they are soft links or symlinks

 

Wonko

[antonino61]

one question concerning hd numbering: can the number assigned to each drive change between rebooting from a pc-on position and rebooting from a pc-off position? if it can, it might be an alternative to some bad ramsticks as the cause of the problem I am experiencing. but in order for me to answer this, I should test alacran's amendment to my menu.lst once more on a cold boot.

 

nino

[antonino61]

well, just coldbooted my wife's laptop as well, thus trying it with my menu.lst that was always there. stuck on the windows rotating circle at boot --> another instance of defective ram? all the machines here? boh, possible, but not probable.

I then copied alacran's amendment to my menu.lst and rebooted. everything worked spick&span. 

whether this machine too, with alacran's amendment, behaves the same as with my original version of menu.lst on a cold boot or not still remains to be seen, but I think and hope not.

now there are only two things on my part: a) if I am wrong, never mind; if I am right, then we can say that starting is one thing and re-starting is another, at least pc-wise.

nino

[antonino61]

hahahhah, wanna laugh? on rebooting my wife's laptop, my version of menu.lst works and alacran's does not anymore. I know that somebody here lost his will to live, I do not wanna lose my will to think. the only thing I can think of right now is that either we have not fully understood hd numbering (me much less so than u, for that matter) or bioses and their readers are somewhat erratic.

nino

[alacran]

once u ultracompress the vhd, and leave it where it is, with the wim file where it has always been, can u deploy the vhd as it is, or do u have to unultracompress it before deploying it back again? and if u can, to what avail? saving space, time or both?

 

If for some reason your VHD stop working, just delete it and only decompress the 7-zip file on same drive where the just deleted VHD was, and you are ready to boot again, Of course this needs to be done booting from another OS or a WimPE.

[alacran]

@alacran

You see , "same location" or "same drive position" is different from "same drive".

 

What you have into the VHD (whatever they are) cannot be "hard links" (hard links can only be on same - NTFS - volume), maybe they are soft links or symlinks

 

Wonko

 

First:

 

I never used this expressions "same location" or "same drive position", what I said is:

 

 

This will work only if you put again on same drive it was before .......

 

Second:

 

Yes, you are right, they are not Hard Links, the Pointers are Junctions created by means of Reparse Points, Post was edited with right names, and with a reference to MS documents to understand what they are. But this in any way solves the mystery why the VHD needs to be on same drive where it was created, and if we copy it to another drive it do not boot, we can only guess, because there is not many info about Wimboot, and it is almost deprecated now.

 

alacran

[antonino61]

@alacrán

how about rewimbooting the wim if anything goes wrong with the vhd?

[alacran]

hahahhah, wanna laugh? on rebooting my wife's laptop, my version of menu.lst works and alacran's does not anymore. I know that somebody here lost his will to live, I do not wanna lose my will to think. the only thing I can think of right now is that either we have not fully understood hd numbering (me much less so than u, for that matter) or bioses and their readers are somewhat erratic.

nino

 

Verify in (I assume) your UEFI Bios: Fast Boot is disabled, just to be sure. If there is an option for always use CSM and never use EFI/UEFI select it, make sure there are no more options (all Bios are different) that may interfere with booting only/first from MBR.

 

During Ramboot only 3 things are involved:

 

1 - Bios.

 

2 - Mass Storage device (HDD, SSD. USB stick. Memory Card, etc.)

 

3 - Ram

 

Since commands are right as they have been tested and they work fine.

 

If a single file required during boot can't be found loaded on the RAM or if it was loaded corrupted during the loading process, then your PC can't boot, maybe in mode aleatory the decompression of some driver files before load them in RAM is not done as fast as required.

 

If this is the case, we may need to deploy/apply again the wim file on same VHD after attach it and fast format it, we need to apply it especifically with WinNTSetup but using Wimlib, NOT Windows API, then it applies also its own internal WimbootCompress.ini and critical drivers and some other files/folders are additionaly uncompressed and installed on the VHD, not as pointers to the wim. It could also be done using wimlib-clc creating and using a custom WimbootCompress.ini, but better use WinNTSetup since it will be easier for you. See attached picture.

 

NOTE: You have to select this every time you run WinNTSepup, it do not remain selected.

 

Do not forget to verify/modify BCD(s).

 

alacran

Attached Files

•  Wimlib API.png   92.24KB   0 downloads

[alacran]

@alacrán

how about rewimbooting the wim if anything goes wrong with the vhd?

 

If you mean reinstall, redeploy or reapply, yes it works too, but just delete the old VHD and extract/decompress the 7-zip where the deleted VHD was is faster.  But you are free to do it the way you like better, I'm giving only an alternative, that works for me.

 

Please read my previous post, I was writting when you made your post, and maybe you can miss it, it has some info about your random Ramboot failures.

 

alacran

[antonino61]

Thanks Alacrán, I read both posts.

Sorry, I don't think I have ever modified the bcd when baking the vhd. I have always left the use existing bcd option.

Might this be the cause of random failure or erratic behavior?

[alacran]

NO, It should not be the reason because then you sould not be able to Ramboot never.

 

Since you started from capturing your HD as Wimboot wim not from a fresh start, I don't know how was your BCD to start with.

 

But SVBus driver requires to have at least Test Mode selected since driver is not signed, or system will not boot.

 

See pictures on this Post : http://reboot.pro/to...e-4#entry209809

 

Those with only 2 entrances are the BCDs located into the VHD on C:\Boot\BCD, the others with more than 2 options are on my boot partition on the USB and are used to boot several options and VHDs with bootmanager.  You can use them as a guide.

 

alacran

[Wonko the Sane]

First:

 

I never used this expressions "same location" or "same drive position", what I said is:

 

 

Second:

 

Yes, you are right, they are not Hard Links, the Pointers are Junctions created by means of Reparse Points, Post was edited with right names, and with a reference to MS documents to understand what they are. But this in any way solves the mystery why the VHD needs to be on same drive where it was created, and if we copy it to another drive it do not boot, we can only guess, because there is not many info about Wimboot, and it is almost deprecated now.

 

alacran

Well, the point is that you said "same drive", but you probably meant "same drive position" (or maybe something else ).

 

I am trying (if I can) to assist you in making things more clear/exact.

 

As an example (hd1,5) is more properly a "drive position".

 

Now, would *any volume* mapped to (hd1,5) work or do you need the specific volume (identified by - say - Disk Signature + Offset or by Volume Serial or by Volume GUID or - as I  suspect - more simply by the drive letter assigned to it)?

 

A junction point (or reparse point or mountpoint) is for directories only. a symbolic link is to files. (I know this is confusing, mainly because it is confusing)

 

Now if you could run this:

https://www.nirsoft....links_view.html

 

You could check that the "target" is a path (i.e. the symbolic link includes the drive letter).

In theory - it should be possible to:

1) force a given drive letter to another "drive position"
and/or

2) change the symlinks to point to another drive letter, something *like*:

https://www.sevenfor...ml#post3186785 

and/or:

3) create/change the symlinks to point to a \\?\Volume{GUID] instead of the drive letter:

https://www.data-med...dant-t1674.html

https://superuser.co...ume-guid-target

 

Only semi-random ideas, mind you.

 

Wonko

[alacran]

@ Wonko

 

 

I am trying (if I can) to assist you in making things more clear/exact.

 

So far now things are as clear as I can, still experimenting.

 

 

Now, would *any volume* mapped to (hd1,5) work or do you need the specific volume (identified by - say - Disk Signature + Offset or by Volume Serial or by Volume GUID or - as I  suspect - more simply by the drive letter assigned to it)?

 

If files are on internal HD:

No way you can map to same drive, only valid mapped hd for Ramboot are the hd numbrer where files are +1 if they are on drive 0 or +/- 1 if they are on a drive other than 0.

 

If files are on external HD:

No way you can map to same drive, we map to hd-1, if not we can't Ramboot.

 

About all the other possibilities, I think they apply as they do on a usuall system install + some additional requirement. But this needs to be proven.

 

EDIT: Forgot to mention something about:

 

or - as I  suspect - more simply by the drive letter assigned to it

 

I think this is not the case, since on USB the drive letter varies a lot depending of the PC where you plug it, or if there is a previous USB stick plugged before you plug the USB device containing the VHD.  And in all this cases it works fine, I thing it has to do more with the signature, serial, etc.

 

About junction points and symbolic links, I think both are used.

 

I'm familiar with Junction Links, I use them to send some Folders content (as Avast AV definitions, FireFox profile, pagefile, temp files, etc) to another HDD drive when using SSD.

 

I will read the info and comment back.

 

alacran