Jump to content











Photo
- - - - -

Install VirtualBox into Winpe "in live" and get it after the reboot of Winpe


  • Please log in to reply
15 replies to this topic

#1 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 12 December 2020 - 09:50 PM

Hi,

First, sorry for my poor english.

 

I am the man who does a lot of useless things. The one I am describing here is certainly useless. But I have to spend my free time.

 

I built a winpe. i put it in a VHD. i copy the VHD in a Usb disk. I plug this usb disk to a physical computer. i boot into Winpe. I download virtualbox ( with Edge because it is present in winpe). I launch the installer program of virtualbox : No error. I launch virtualBox program. I create a VM. I attach an old VHD to this vm. I boot this VM : OK. I stop this VM.

Now, if a shutdown winpe and i reboot : i lost virtualbox.

 

To keep VirtualBox, 2 possibilities :

1- identify drivers and add them in boot.wim : i don't try this and don't if it works really

2 - save the 2 hives, system and software, change SetupInProgress ans SetupType. And copy the saved files in ...\config

 

Yes, one big limit : i can't boot on a very different physical computer.

So, useless.

And Yes, I know, it's better to use Linux.

 

Nevermain, i 'm happy to verify that i'm not too old and i can get a positive result in this day, not a BSOD.

 



#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 13 December 2020 - 01:41 AM

Hi Noel, it's good to know you are in good health.

 

One of those you call useless things, was a topic from you about a VHD that can't boot with new bootmgr because of lack of some files, there you mentioned you like to make PE flat installations on VHD, well that motivated me to open a topic about that subject to talk about experimenting with that.

 

I allready know you have a lot of experience doing it and it is very possible you don't find anything new for you, but just in case you don't have anything better to do, maybe your curiosity make you go to take a look to this topic: http://reboot.pro/to...ct-mode-on-vhd/

 

It is nice to see you visiting the forum again.

 

alacran



#3 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 13 December 2020 - 01:43 PM

Hi alacran

I use bing/traductor because my English ....
 

I am very honored by your kindness. Thank you for remembering that my state of health is that of a little old man.
It's true that I can't sit in a chair in front of my PC for very long, my back quickly becomes sore.
 

I have not forgotten your perseverance to identify the origin of my error regarding the absence of the bootvhd.dll file.
And I really liked you for that.  :)  It also showed me that I was living on my gains without updating them.  :huh: 
 

I had already seen and read your study on "winpe flat or compact mode". But because of my inability to fully understand the method because of the translation, I did not intervene. I was also afraid to sound ridiculous. And I didn't want to confuse/disrupt the thread of exchanges with more competent people.
I will reread it because I am far from having managed to understand everything.
The first brake is due to the translation into French which creates misunderstandings, even nonsense.

The second obstacle to my understanding is the use of "third" programs.
I only use MS software or my PS scripts. It is a safety reflex that I take from my years of professional activity.
Definitely useless now. But a suspicious old man remains a suspicious old man for a long time.

The third brake comes from WimBoot technology. Again, I'm not sure I've understood everything I've read in the MS documents.
https://docs.microso...-and-8/dn594399(v-win.10)
https://docs.microso...-and-8/dn621983(v-win.10)?redirectedfrom-MSDN

note: I think I have read that this technology is or will be discontinued by MS. Hard drives are getting bigger and bigger and the OS's compression is "complicating" its update.
 

The Winpe flat/Compressed comparison is a very good thing.
Thank you for opening my mind and reminding me of the existence of this technology that I had forgotten.
 

You also address the case of "WindowsToGO". I had used it a bit in the past and enjoyed it when I was still working.
 

I do not understand everything when you address the difficult subject:"Make a Wimboot VHD coupled to a WinPE.wim"

Too complex for my old head.
"Only for learning, testing and the challenge purposes" :  :clap: I like this way of working and advancing knowledge. This drive creates a healthy emulation, far from any sterile competition. I don't have enough control over the subject but I'll try to understand.
 

Regarding printers (pdf and xps), I showed how to implement them in winpe (but on the site of "others").
Same goes for Blutooth. As well as for KMF/UMF drivers useful for WPD/MTP and now for termservice (mstsc).
Slore, who is also a friend, can explain how to activate them since he offers them in his tool WIMBUILER2.

Regarding "The command writes to Registry, and as Registry is volatile, it has to be run every boot...":

This is a subject that has been of interest to me for a long time since it is the theme of this topic.
And for now I use "save the 2 hives, system and software". Going further would be fraudulent, but ...
For now, I'm doing an intermediate restart to exchange the 2 files (and edit 2 or 3 keys, see in topic "winpe in FullFlat in an annexed file")

note:
I had already submitted this point on this forum: http://reboot.pro/to...ramdiskoptions/
My goal was to implement a second winpe in the vhd in order to make this change without using another media or another vhd.
I had introduced an error during my tests by renaming a boot file. It became difficult because of the language barrier to explain that this error was not to be taken into account in answering the topic question.
But I gave up because it took too much effort to explain and I might not be understood.
Also, after a few tests and a little analysis, this proves impossible, in my opinion. It's too long to explain but if you're interested...
 

Perhaps too long post. Sorry
Well cordially
Noel



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 December 2020 - 02:14 PM

@Noel

 

Just for your interest, the traditional way to have a PE (which - by definition - is "volatile") "remember" the settings (in the Registry) for an installed application was to snapshot the Registry, find the differences, export them as .reg file and (at next boot) import the .reg file.

 

This applied to a "flat" PE on read/write media, where all files (executables, drivers, etc.) coming from the installer remained on the media.

 

Most probably in a .wim based setup this won't happen, so you also need to copy back these files at next boot.

 

Or - and this is what the builders and their scripts actually do - create the PE with the app already installed, but I don't think a Virtualbox script ha already been made by anyone.

 

Now - another possible approach - have you tried the portable version:

https://www.vbox.me/

 

:duff:

Wonko



#5 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 13 December 2020 - 02:33 PM

Hi Wonko

I try to remain humble but sometimes translation.. also, be sure that I have the most respect for you

 

 

Just for your interest, the traditional way to have a PE (which - by definition - is "volatile") "remember" the settings

Yes, you describe the traditional way... but it's not the best... in my humble opinion.

 

it is difficult to show you that, in the context of a winpe Flat in a VHD, the simple backup of the 2 hives and the modification of 2 or 3 system keys is enough to make it non-volatile.

I can show you a picture of a VM in virtualbox installed into a winpe, but i can't show you, after the reboot, virtualbox is still here. I use virtualbox but it may be possible to use other program.

And yes, it's only for the fun.
 

Best regards



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 December 2020 - 03:37 PM

it is difficult to show you that, in the context of a winpe Flat in a VHD, the simple backup of the 2 hives and the modification of 2 or 3 system keys is enough to make it non-volatile.

 

No need to show that to me, I know that.

 

:duff:
Wonko



#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 13 December 2020 - 04:01 PM

The portable programs are always my preferred option, I think using Wonko suggestion is the best option. But just got an idea.

 

I never have tried this approach, but it came to my mind right now:

 

We already know the virtual X: drive is the supossed content of the PE (or flat installed on the VHD) we are running at the moment, then assuming we can capture it in a WIM image and re-deploy it on the same VHD (or a copy of it, but not on a new one) flat or compact mode installed VHD theoretically this should work.

 

Also thanks for your kind words my friend you are really a gentleman, just to let you know I'm also not very young too, I'll be 68 next February 2021, I'm a little dented on the outside, but afortunatelly my mind is still in good shape.

 

alacran



#8 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 13 December 2020 - 04:33 PM

@alacran

my mind doesn't work as well as yours even though I'm a tiny bit younger

 

 

then assuming we can capture it in a WIM image and re-deploy it on the same VHD

 

it's a little longer than backing up 2 files when winpe is active and later copying them into the vhd Flat. 3 minutes max.
It is true that I do not use Winpe to do anything other than play with windbg.

I've often had to put hyperV in Winpe just to play.
But the challenge is to be able to capture the system update before the reboot.

Have a nice day



#9 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 13 December 2020 - 07:33 PM

Hi Noel,

 

Your english is very fine :)

And what you call "useless", I actually call it research and developpment for fun which is basically the essence of this forum (IMHO).

 

I believe you are talking about persistence here.

Something which linux live distros are managing rather well.

 

Back to winpe, the file part i would say should be easy : a vhd file for instance (or any other persistent format) which winpe would mount on startup.

Now the registry part indeed is trickier.

 

I have read here and there about registry redirection but I have not yet explored this part.

Another path could be registry hooking : any read/write would be hooked and if the key does not exist in the default hives, then the hook would redirect it to an alternative registry : a path i may explore in the future, for fun (again).

Or as Wonko mentionned, capture changes before/after (like when you logon/logoff) and reload changes everytime.

Or preferably, whenever possible, use portable apps (also mentionned by Wonko).

 

Did I understood you right?

 

Stay safe,

Erwan



#10 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 13 December 2020 - 07:40 PM

@erwan happy to read your good words. I write this below before you send your post. So my reply is at the end.
 

Some ideas on the subject: how to introduce an application in Winpe
 

The classic approach to adding an app (not "portable") in Winpe:

        capture changes in files and hives generated by installing this app
 

Why this approach?
the main reason comes from the use of a "builder" for winpe. It is a construction that follows the same logic of that of the ADK.
A package (whatever the name of this data set) contains all the necessary elements (files, keys, computer processing (like some OC in ADK)) to add to a boot.wim
The "builder" integrates this package into boot.wim according to its specific logic.
 

Logic can be described as follows:
     In active winpe, capture changes.
     Create the package from the modified and collected items
     create the "builder"-specific treatment
Benefits:
     The package is built only once and made available to all users of the "builder"
     The package becomes one option among others that the end user of the "builder" can select
One drawback:
     you have to redo the package for each new version of the app

 

My opinion : it's the only one good solution for who use a "builder" like "winbuilder, WiMbuilder2, Pebacker...

 

But i don't use any builder and i play with Winpe. I think i'm not the only one. And i want to stay "agile".
 

Question to get out of habits:
In the case of an application that will be used very very rarely and that does not interest many users, it seems to me uneconomical to create such a package that requires a pretty big job sometimes.
     What other solutions are being considered?

I see at least 3 possibilities depending on the needs and desires to discover new approaches
 

1- "writers filters" as in small PC wyse or competitors (a technology I encountered when I was working on PC virtualization projects)
https://docs.microso...ed-write-filter
https://docs.microso...stering-filters
http://woshub.com/us...uwf-windows-10/
I don't know if all the developments are available or if they could be adapted for Winpe

I'll try it if my mind stay agile.
 

2- a capture (global or targeted) and then an injection into the envelope of an inactive system: certainly possible
capturing all or part of the system is done on the active winpe system
injection will be done later but with the inactive system
it seems to me that it is a long process, but in the case of multiple installations at the same time ...
 

3- Take advantage of the context "Winpe in Flat mode in a VHD":
it leads to bypass the winpe limitation without becoming outlawed
Note: MS limitation is normal. It's commercial protection. Linux is free and often a good solution. But i play this MSDOS 2.0 since 1984

The method is simple:
     save 2 files when the system is active
     inject these 2 files into the inactive system

an advantage: 3 minutes for a technician

disadvantage: it applies in the unique context following "Winpe Flat mode in a VHD"
          (Flat - NON-RAM according to the new terminology of MS that speaks almost in French!)

the big drawback:
     this manipulation is impossible for a non-technical end user
 

As i said in an other place, i use this method for injecting a full graphic drivers ( update from devmgr.msc in a winpe and take needed files on a disk), for installing virtualbox 1.6
 

That's it, I don't have anything to sell, But I don't often see that solution covered.
 

And I thank alacran again for bringing the concept of winpe Flat to the fore and for enriching it with the notion of winpe in a WIMBOOT

 

@erwan : i get this third solution and it works for me, i use it ad i wanted to share. I explain details in an added files in FullFlat topic.

"redirector" "write filter".... same logic same phylosophy but different words. 

"Unified Write Filter on Windows 10" seems to be a way.



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 December 2020 - 09:33 AM

The whole concept of "builder" is of course only another name for a (specialized) script/batch processor, but for all it matters the whole stuff is only about remaking a number of steps/commands, i.e. the builder is just the means.

 

erwan.l has a "QuickPE" making script:

http://reboot.pro/topic/18744-quickpe/

 

The "original" tiny XP project could be made (basically) with my little batch:

http://reboot.pro/to...fs-below-10-mb/

before misty managed to create the miniXP project (Winbuilder based):
http://mistyprojects...niXP/index.html

 

 

:duff:

Wonko



#12 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 14 December 2020 - 10:04 AM

Yes, I agree with you.
Whatever it is, a "builder" for winpe is a must.
I would never say otherwise since I use my "builders" since XP (batch cmd then batch PS).
 

I wanted in this topic to evoke the various methods to add an application "non-portable" and "of little interest" for end users.
And I wanted to share a method that I already described in a file I had attached in the topic dealing with "full Flat".
 

So it is only to describe a method little used and therefore useless that I clutter this forum a little.

But I think sharing information can be a good thing.

And yes, it's a very useless method. I think I'm the only hermit to use it.
I'm not its creator. I discovered it ready to use on a Chinese site many years ago.

 

A clarification perhaps:

I can tell the difference between:
- on the one hand the construction stage of his Winpe with his favorite builder
- and on the other hand the one-time addition of an application

 

PS: I don't know if the translation correctly expresses my purpose or if my formulation is clumsy and creates ambiguities


Edited by noel, 14 December 2020 - 10:08 AM.


#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 December 2020 - 10:48 AM

Your English/translation is fine.

 

It is the actual "core" that is "vague", you are not sharing any method or information (or I cannot see them).

 

WHAT file?

Attached WHERE?

WHICH topic about "full flat"?

 

:duff:

Wonko



#14 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 14 December 2020 - 11:53 AM

I understand now that I am not clear.
 

In the topic http://reboot.pro/to...-a-description/
there is a .7z file that contains various elements that I think are useful.

The file "3-WinpeFlat-Vhd-use-case-en.txt" describes, among other things, the details of the "Chinese" method.
 

not to introduce ambiguities yet, I note here the correct sequence:
 

1- boot on a  VHD-WinpeFlat

   no matter the builder used to build this WINpe FLAT in a VHD
 

2- install VirtualBox 6.1.16

    in my winpe built with my builder : it's OK without error
 

3- create a vm if you want for the test
 

4- save this  two files

     x:\windows\system32\config\system

     x:\windows\system32\config\software
 

you can use :

Reg save hklm\system x:\windows\system32\config\system.saved

Reg save hklm\system x:\windows\system32\config\software.saved
 

5- modify x:\windows\system32\config\system.saved

The 3 basic mofications to do in ...\config\system.
   \system\setup\setuptype = 1
   \system\setup\systemSetupInProgress = 1
   delete or rename \system\mountedDevice (------> this if you change of computer !)
 

you can use ( if i don't write error because i write "in the fly" ):

reg load HKU\system-saved x:\windows\system32\config\system.saved
reg add HKU\system-saved\setup /v SetupType /d 1 /f
reg add HKU\system-saved\setup /v SystemSetupInProgress  /d 1 /f
reg delete HKU\system-saved\setup\mountedDevice
reg unload HKU\system-saved
 

6- Stop Winpe properly
 

You don't have to restart on the first winpe because you will lose the result of the installation
 

7- Restart using another image of a winpe.

 

8- step "copy new files" : warning

So, in this second winpe :

- mount the vhd of the first winpe

- go to the config directory in this first winpe : I don't know if I'm understandable

- replace system by system.saved and software by software.saved

- You can also save the original files before the copy

you can use :

copy <the letter for the VHD mounted>\windows\system32\config\system.saved <the letter for the VHD mounted>\windows\system32\config\system

copy <the letter for the VHD mounted>\windows\system32\config\software.saved <the letter for the VHD mounted>\windows\system32\config\software

 

9- unmount the VHD
 

10- boot on the first Winpe VHD (on the same computer for the first test)

 

If i don't make error in the sequence, and if you don't make error, you retrieve your virtualbox installed (and your VM in you create one)

I'm sure if i make error, you can correct.

 

because i was sure that all technicien know this method, i didn't write details here before.

 

I hope i don't make error.

If someone tests this, i beg his pardon if he is meeting some error. But before he beats me with a stick it would be possible to discuss.

 

ps : discussing the method was the goal I was pursuing



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 December 2020 - 12:52 PM

Suitable tools for 4-10:

 

http://reboot.pro/topic/20848-dumpreg/

http://reboot.pro/to...fline-registry/

 

:duff:

Wonko



#16 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 20 December 2020 - 08:33 PM

Can we install HyperV in Winpe using "optionalFeature.exe"?

 

A subject of study for this winter... and maybe for the next ones.

 

In the "Winpe FullFlat" environment, you can add a feature with "optionalFeature.exe".
Some features don't require reboot.
But those that require a reboot are a good subject of study for this winter.
Randomly, I'm going to opt for HyperV.

 

Yes, I know, there are Linux or Virtual Box, and many other solutions like Server-Core or nano-server
https://docs.microso...-is-server-core
https://docs.microso...ver-quick-start

https://hub.docker.c...dows-servercore
https://docs.microso...ntainers/about/

I have no need to use HyperV in winpe.
But I have to take care of it this winter.

 

1 - I've already done a first try to activate HyperV in "Winpe FullFlat".
This test is positive because "Winpe FullFlat" contains all the necessary elements.
The sequence unfolds like this:
   A first phase of updates is launched.
   A reboot is triggered.
   Then a second phase of update would finish the installation of this feature.

 

But System and Software hives are not backed up in Winpe. It is therefore impossible to get a proper installation.
The complexity is to be able to intercept the modifications of the hives after the first phase of the update and before the reboot
For now I have no leads for this capture.

During this first test, I was able to follow the activity of the "trustedInstaller" service, "tiWorker.exe", "poqexec.exe".
But I don't understand everything.
The first step in the study would be to identify the components involved in this addition.
A much more complex second step would be to understand how to launch a program to capture hives in the very particular context of system updates.
A third step will be to inject this capture into winpe.

 

2 - This week, I did another test in Winpe: make "optionalFeatures.exe" operational.
It is a long work to build the environment and identify all the useful elements.
But I now get the ability to install and uninstall "Telnet.client."

Yes, useless if you think "telnet" but useful to master logic.
This requires a large volume of files, of course. But in a VHD, this is not the major concern.

 

Conlusion
On the one hand, the playful aspect remains for me the most important.
On the other hand, I think this solution can give beginners greater freedom:
   install all apps without waiting for a third party to create a plugging/script
But its drawback is important:
   a longer time to create the VHD file when compared with creating a simple boot.wim

In a word, the beginner becomes a little more autonomous.
Certainly it needs a very special winpe.
But it is/will be possible to adapt Slore's wimBuilder2 for example for this.

 

Attached Files






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users