188 replies to this topic

[antonino61]

so, by taking wimb's advice. I shall have

1) my d:\ drive where I am supposed to leave everything as it is;

2) a 5gb? vhdx file on my d:\ drive, if I am not mistaken;

3) what else and where (wimboot or wimlib or winntsetup?)?

 

nino

[wimb]

so, by taking wimb's advice. I shall have

1) my d:\ drive where I am supposed to leave everything as it is;

2) a 5gb? vhdx file on my d:\ drive, if I am not mistaken;

3) what else and where (wimboot or wimlib or winntsetup?)?

 

nino

 

1) OK

2) NOT OK

- You need to boot with Win10XPE and use WinNTSetup to make a 25 GB VHDX for Install of fresh Win10 x64

- Then you will have at least a properly fresh installed win10 x64 OS, in which you later can use WinNTSetup for WIMBOOT install as proposed in 5 GB VHD

3) Nothing else yet

 

Remember your present Win10 OS is not suitable to run WinNTSetup.

So it will be wise to have a properly fresh installed Win10 x64 OS in VHDX

[antonino61]

So, let us make point 2 clear:

I need to boot what with Win10XPE? maybe this is what is still cloudy to me: is win10xpe a version of windows? if so, do I make it or is it already made? 

WinNTSetup to make a 25 GB VHDX - I might as well have computer management make a 25gb vhdx, or do I have to use winntsetup perforce?

either way, what is the source of win10 x64? can it be any or must it be just a recommended one?

in whatever way, I will hopefully get a properly fresh installed win10 x64 OS, fine; what media will hold it? the 25gb vhdx or anything else?

once within this install, if I have understood correctly, I can later use WinNTSetup for WIMBOOT install as proposed in 5 GB VHD, which will reside in the d:\ drive, or anyplace else? if  it is on the d:\ drive, so much the better for me, even better still if everything (vhd, vhdx and what else I have lost track of) is on the D:\ drive. I hope I am on my way to getting my head together, in spite of your patience, consideration and dedication.

nino 

[wimb]

All needed Info is given already here

[antonino61]

Yes, correct, too much info, so much that I run the risk of doing the wrong things and take the right ones amiss. so many solutions differ for what could be taken for little trifle when we all know it is not. For example, what is not clear is whether these operations are all to be made from gui or from a pre-windows-interface environment. I have downloaded so much software for the purpose that I really cannot tell what I need from what I need not. I feel I am only left with my willingness to try, but it is still too little. with all the knowledge I have acquired from the file(s) you guys indicated, I honestly do not know where to start from. I have tried to check tutorials on youtube, which would make it much easier for me to mime or replicate all the actions. but to no avail - i haven't found anything that is described in the files u recommended - they are showing other things altogether.

For the sake of comparison, the preramloading process with grub4dos was sort of easy to follow because of the presence of a host of youtube tutorials together with written tutorials. If only I could have the same scenario for wimboot, winntsetup etc. instead of just pictures and text, I would already have tried. 

Edited by antonino61, 22 February 2019 - 05:19 PM.

[alacran]

When I use wimboot option in wimlib-clc then I get a WARNING for Unrecognized Section in file WimBootCompress.ini

[PinningFolderList]
\Windows\System32\config
\Windows\System32\DriverStore
\Windows\WinSxS

Is it possible to modify an existing instw3.wim ? The program winlib-clc always wants to overwrite everything.

I tried to use APPEND but that fails with ERROR Message

 

wimlib-wimboot-2019-02-22_070121.png == wimlib-WARNING-2019-02-22_070750.png == wimlib-APPEND-Error-2019-02-22_072804.png

 

Anyway I am quite happy with the normal CAPTURE and with my 8 threads it is quite fast to create new wim file.

 

Instead of using WiNTSetup I have used also APPLY option where Selected Target Image Path is the mounted VHD after using Format button.

 

Just made a post on wimlib-clc thread asking ReTokener to take a look to this issue, he has made all progam code since the begining, I'm only Beta Tester and Spanish translator (and a big fan of the clc).

 

Remember wimlib-cllc is a GUI and all it can do is what wimlib-imagex can do, no more, no less.

 

APPEND is for adding a new image to a wim file not to modify actual image. To modify an image use UPDATE, all you add will overwrite previous info without asking, to delete something use INFO/DELETE.

 

By mens of lists you can extract and add (inject) files/folders as MistyPE and ChrisPE do, using wimlib-imagex on command line (and recently coded into PEBakery codes) during PE creation.

 

When trying to add a little .dll or other kind of small dependencies to a boot.wim,  I have used a dirty trick, open the .wim with 7z, select the image number go to desired location and just drag and drop the file(s), They will be added to the image contained on the .wim (but uncompressed), then it is possible to run a quick test and if all is fine latter OPTIMIZE the .wim to recompress all files not compressed. This is a very fast operation.

 

Yes APPLY tab is very usefull too, wimlib-clc is my back-up favorite program, first Capture takes some time but following updates or deltas are very fast.

 

In CAPTURE tab using CAPTURE you create a new .wim file, using APPEND you may create a new image (with a new name) into the same .wim file, and you may also use "Delta from..." or "Update of..." or both options togeter (the faster mode), but there are some little files that are not updated this way, see my post about this here:  https://wimlib.net/f...c.php?f=1&t=365

 

alacran

[Tokener]

@wimb #124

 

dear wimb

thank you for testing Wimlib-clc, this is a great honor for me.

 

Wimlib-clc should only compile the command line.

To exclude that Wimlib-clc causes the error, you can read out the command line from the log file (if activated) and execute it in the console.

If the error appears again something else causes it.

 

Regards T.

[antonino61]

Dear Alacran,

I spent yesterday evening trying to play with the following:

 

md d:\mount\Windows

 

Dism /Mount-Image /ImageFile:"d:\Images\install.wim" /Index:1 /MountDir:d:\mount\Windows

 

attrib –s -h d:\mount\windows\Windows\System32\Recovery\winre.wim

 

move d:\mount\Windows\Windows\System32\Recovery\winre.wim d:\images\winre.wim

 

Dism /Optimize-Image /Image:d:\mount\Windows /WIMBoot

 

Dism /Unmount-Image /MountDir:d:\mount\Windows /Commit

 

Dism /export-image /wimboot /sourceimagefile:d:\images\install.wim /sourceindex:1 /destinationimagefile:d:\images\install_wimboot.wim

 

As a result, in d:\images I obtained 

winre.wim (359mb)

install.wim (3004mb)

install_wimboot.wim (3193mb)

 

I could not get to install winpe, though. I tried with windows adk and the software u recommended - no dice.

 

then I spent this morning trying to capture program files, program files (x86), programdata, users and windows into an image, which added bigwim.wim (47something gb) to d:\images (gimagex said there were some extended attributes that it could not include in the image).

 

Am I getting any closer to the aim?

 

nino

Edited by antonino61, 23 February 2019 - 01:53 PM.

[wimb]

 

Wimlib-clc should only compile the command line.

To exclude that Wimlib-clc causes the error, you can read out the command line from the log file (if activated) and execute it in the console.

If the error appears again something else causes it.

 

 

Thank you for your very nice program wimlib-clc 

 

When using wimlib-clc then I get the WARNING

When the command is executed then there is no warning.

 

The Screenshots shows what I did and what I observed.

 

Thanks for your help in solving the (minor) issue.

 

==  == 

[Tokener]

dear wimb

thanks for excluding this.

In the moment I can not replicate this kind of capturing because I have no "wimboot-system".

But there must be a fix ...

 

T.

[Tokener]

dear wimb

Just tried the following:

copied wimbootcomress.ini [Edit: (containing the mentioned "[PinningFolderList]"-section)] to:

C:\programData\Windows\system32\wimbootcompress.ini

then

captured C:\programdata with wimboot-option by wimlib-clc: (NO config-file specified!)

 

B:\WIMLIB~1.EXE append C:\ProgramData B:\ProgramData.wim "ProgramData_190223_184911" "C:/ProgramData"  --include-integrity  --wimboot 

Popup appeared as seen on the screenshots above, giving a WARNING.

Running the same command in the console returned this:

 

C:\Windows\system32>B:\WIMLIB~1.EXE append C:\ProgramData B:\ProgramData.wim "Pr
ogramData_190223_184911" "C:/ProgramData"  --include-integrity  --wimboot
[WARNING] C:\ProgramData\Windows\System32\WimBootCompress.ini:5: Unrecognized se
ction "[PinningFolderList]"
Scanning "C:\ProgramData"
272 MiB scanned (712 files, 245 directories)
Setting the DESCRIPTION property of image 10 to "C:/ProgramData".
Using XPRESS compression with 8 threads
Archiving file data: 0 bytes of 0 bytes (0%) done
Calculating integrity table for WIM: 114 MiB of 114 MiB (100%) done

The third picture you posted shows console window with wimlib-imagex has finished capturing.

Is the WARNING given in the returned lines above?

The Popup does not appear in console-window execution - it is a feature of wimlib-clc.

BTW "PinningFolderList" has no match on Google.

 

Regards   T.

[Tokener]

Ooops

I was not quite right:

Google found this:

https://wimlib.net/f...c.php?f=1&t=368

[wimb]

The WARNING appears indeed also in the command window.

 

Sorry that I missed it. So the issue is not caused by your program.

 

[alacran]

@ antonino61

 

See this posts, you don't need to run a test to satisfy your curiosity, I have just done it, so far this are the smallest Win10x64 1809 wimboot installs I can make, only thing (from Windows) not installed are unnecesary Apps, and all is running great:

 

http://reboot.pro/to...e-6#entry209462

 

& http://reboot.pro/to...e-6#entry209463

 

In order to have some space for installing future programs, I do not recommend 512 MB unless it is for portable use.

 

Remember the starting standard install (not wimboot and not compressed is 10 GB and has 2.49 GB free), this may be good for daily use.

 

alacran

[antonino61]

Oh My Dear,

I guess you have definitely changed my pc experience! If I am not mistaken, I have finally booted from just 888mb. Too good to be true? Let us see. I prepared my vhd from scratch, as alacran often suggested I do. then I  captured a copy of it with gimagex64.exe and called the resulting wim Mywim.wim. then I used winntsetup3 to create and attach what still seems to be a huge vhd for the little stuff it put on it (just 888mb), and then I used the wimboot command. Everything seems to work fine. I have just made some modifications (no pagefile.sys, for instance) that seem to persist across reboots. everything seems to work perfectly. thank you all. still if I am not mistaken (correct me if i am wrong, pls) it finally proved much simpler than it had seemed to be. 

[antonino61]

Well, still if I am not mistaken, it apparently guarantees persistence across reboots. One caveat, though. with dism++ I ventured to revoke compact, which skied the vhd from 888mb used space to 20gb used space, which means wimboot has compressed it. now I installed a couple of applications and it grew a few 100mb bigger. I wonder what the scenario would have been If I had installed them ahead of the capturing into mywim.wim and the wimbooting. what do u suggest I do when installing new software?

[antonino61]

ramloading does not work, but that might depend on wrong menu.lst instructions. if they should not be the same as with my past config, i really do not know what to do.

[alacran]

@ antonino61

 

Hello my friend, It is nice to hear you finally ran your own test.

 

For deeper info see this thread: Making the smallest Win10 install (wimboot mode) on 512 MB VHD

 

There I recomend in order to keep VHD size to minimum it is a good practice to install all you may need before making a new wimboot image (compression: Express 4k or just  = Express on Dism and similar). This is the standard compression used for Windows for wimboot, you may use LZX compression or = maximum on dism, but it may have a more noticiable efect in low power CPU units and the efect on reduction size of the captured wim is not too much, and in my opinion this size is not so important as the VHD size (the one we pretend to load in Ram). Also I recommend use wimlib-clc (GUI for wimlib-imagex) to capture the image because it is faster than any other MS tool to do it and also give you a smaller final size for the captured *.wim.

 

I strongly suggest to follow instructions and use the recommended tools to get the best results, my friend you have a big tendency to do not follow instructions and modify procedures, this makes dificult to help you if need arrise, since the people who make the instructions haven't done someting the way you did, then to help you, you force this people to do things your way to find the cause of the problem and sometimes/manytimes people is busy doing other thigs and you may not get help.

By the way this remembers me I need to make some little changes on the procedure to avoid a problem I found latter (when finally Rambooting), easy fixable but it is better to avoid it since the begining.

 

After reading that link, if you have any questions it will be a pleasure to try to answer to you (and amplify you doubts, HA, HA, HA)

 

alacran

[antonino61]

Thank you Alacran for your prompt reply. my previous failure was due to something really trivial - I did not know I had to mount the empty vhd for winntsetup3 to feed it; I just thought the software would do it automatically.

I admit I tend to do things my way, but this time I have tried your way too, with wimlib-gimagex - no dice - there must be something I'm missing here and there that prevents me from succeeding. I was able to do it with ordinary gimagex64.exe. 

My 2 main perplexities concern size and ramloading:

1) with this ad-infinitum capturing and wimbooting, the size of my vhd and wim seem smaller, which in this case was probably do to a post-debloating of the system on my part? let us see with the next ones in a few days.

2) whenever I try to pre-load my vhd into ram, the same old way

map --mem --top /vhd.vhd (hd0)

map --hook

root (hd0,0)

chainloader /bootmgr

a bosd appears after g4d ramloading with the following error: 0xc0000225

What am I doing wrong?

Thanx in advance for your precious answers.

nino

[alacran]

When you make a wimboot VHD you need to first install SVBus_V1.1_20181109  before you can try to RAMBOOT, (i will assume you allready did that) and use an entry in your menu.lst as on this posts:

 

http://reboot.pro/to...e-6#entry209501

 

http://reboot.pro/to...e-6#entry209512

 

Also you need to edit your BCD located on your VHD, use attached picture as guide, change VHD name as required

Attached Thumbnails

• 

[alacran]

1) with this ad-infinitum capturing and wimbooting, the size of my vhd and wim seem smaller, which in this case was probably do to a post-debloating of the system on my part? let us see with the next ones in a few days.

nino

 

I don't understand what you mean with ad-infinitum, you only have to do a deploy to prepare the OS with all your favorite programs, drivers, etc, then you capture it only once as wimboot and you deploy it one again (second deploy) but this time as wimboot, so you only capture it once an deploy it twice.  If you are doing different, it is a wrong procedure.

 

EDIT: a link to SVBus driver was added to previous post, just in case it is required.

 

Install x86 and x64 .exe are located on bin folder, just install the driver, do not read instructions as they are outdated.

[antonino61]

ad-infinitum because I later realized that I had forgotten to debloat the system of all the microsoft publicity and advertising, which I did later so I made another wim based on the new vhd and wimbooted it later. but it might as well have been a new application or a new version of an application, for that matter, that one might wanna try out. this is what I meant by ad-infinitum, a never-ending story. anyone's windows today is hardly the same as that windows 5 weeks ago.

 

As regards, svbus, I have not tried it yet, as firadisk was already installed in the first place. I do not have this gui version of bcd edit, though, I have always used easybcd, which had always worked for me until this wimboot deployment. but it might be due to something I must be taking amiss.

 

nino

[antonino61]

I have tried svbus as well - same behavior as with firadisk - bsod with 0xc0000225 error

what am I doing thati is wrong or what have I not done that would have been right?

[Wonko the Sane]

0xc0000225 is linked to a "wrong" BCD configuration.

 

Check - using BootICE - I believe 1.3.4.0 is the latest:

https://www.softpedi...k/Bootice.shtml

that your BCD is like the one alacran posted a screenshot of.

 

BUT more generally if there is a step in a tutorial that you are having issues with, THAT step must be resolved BEFORE going ahead, using a woirkaround/another app/whatever may introduce a (even if minor) fork or difference that a few or many steps later may cause a bigger problem.

 

I admit I tend to do things my way, but this time I have tried your way too, with wimlib-gimagex - no dice - there must be something I'm missing here and there that prevents me from succeeding. I was able to do it with ordinary gimagex64.exe. 

at face value, the above reads as "since I wasn't able to do it EXACTLY as you stated, I did *something else* " usually, not always but often enough, that is a good preamble to troubles.

 

Whenever (and it doesn't happen that often) there is a step by step "tutorial" (and people able to assist in following it) it must be followed EXACTLY, to the letter.

Once you will have succeeded (i.e. replicated the steps EXACTLY) there will be time to introduce variations, changes, betterings, etc.

 

More generally alacran has a quirk for giving as "common knowledge" details that the new user might well be unaware of, but if your report are of the kind "I couldn't use wimlib-gimagex so I used gimagex64.exe" - besides creating a nice, symmetrical situation - you aren't gong to get any meaningful assistance/help.

 

The Devil (but also success or failure) is often in the details.

 

Wonko

[antonino61]

Thank you wonko and alacran for your patience,

I have finally succeeded in wimbooting into ram

alacran directed me to some page where I found the following

(the name of the vhd I obviously edited)

 

map --mem --top (hd0,0)/vhd.vhd (hd-1)

map --hook

root (hd-1,0)

chainloader /bootmgr

 

which I changed into

 

map --mem --top (hd0,0)/vhd.vhd (hd1)

map --hook

root (hd1,0)

chainloader /bootmgr

 

and it booted like a charm, which makes me understand (rightly or wrongly I do not know yet) that, unlike my past config (the ex-post-facto hilariously hybrid deployment),

 

map --mem --top /vhd.vhd (hd0)

map --hook

root (hd0,0)

chainloader /bootmgr

 

the vhd is not the first thing to load into memory. this new config is no doubt much better, "magical" I would say in saving space and time, but I still do not know where which (vhd, *.wim) is where (ram / stays on disk).  I did solve this problem by trial and error. by the same criterion, I capture with gimagex, until I discover by mere chance how to succeed with wimlib or somebody patient tells me what to do that is right.

 

nino