Jump to content











Photo
- - - - -

Boot VHD or WinPE with grub2

grub2 vhd bootmgr lua

  • Please log in to reply
49 replies to this topic

#1 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 June 2016 - 07:19 PM

I am trying to create a dual boot system for my public library computers using Steadier State as my starting point to boot Windows 7 Ultimate from a VHD file. The other OS is Linux Mint 17.

 

I have figured out how to do this, but I'm trying to perfect the approach.

 

Steadier State (SS) is a set of scripts designed by Mark Minasi to convert a system to run from a VHD file. It uses WinPE as a sort of "supervisor" that decides if bootmgr should boot the VHD file or WinPE. It does NOT provide the ability to always reboot to a standard "template" version of the OS, thereby ALWAYS discarding the snapshot.VHD file. However, I got around that by creating a one line shutdown script in Windows that uses bcdedit to switch the default bootmgr entry, so on shutdown that script sets the default to boot WinPE, which will perform the "rollback" and reboot to the snapshot.VHD file.

 

As I said it all works OK, except every system restart requires 2 boot cycles: 1) Boot WinPE; if no maintenance flag is set delete the snapshot.VHD file and use diskpart to recreate a new one against the parent image.VHD file. It then changes the boot\BCD file so the next boot will be the new snapshot.VHD boot entry in bootmgr. 2) Reboot to the freshly created snapshot.VHD file. This effectively "rolls back" all changes done in the last session of running Windows from the snapshot.VHD file.

 

Unlike wioski, which avoids this "double reboot" scenario using clever tricks with /unattend.xml and MDT in the setup / deployment, SS is not as sophisticated.

 

Now grub2 is a very capable bootloader that includes some limited scripting capabilities. If I could put the SS logic of what to boot into a grub2 script I might be able to eliminate the need for WinPE and therefore reduce the process to a single boot cycle.

 

I recompiled grub2 to include support for lua, a small scripting language used by many applications. I was hoping to copy into place the appropriate BCD and snapshot.VHD files before chainloading to bootmgr, which would put grub2 in the drivers seat completely in controlling whether to reboot to a pristine, new snapshot.VHD file or to boot WinPE if the maintenance flag (a file of a specific name is present or not) is set.

 

Unfortunately I discovered grub2 has zero filesystem write functionality, and therefore neither does the lua module as it relies on grub.run (there is no os. or io. object) to access the filesystem. So lua under grub2 won't help me it seems.

 

Could bootmgr be made to look in different places or in different files for its BCD info? If so can different grub2 menuitems be defiined to invoke bootmgr so it uses BCD.a for one menuitem but BCD.b for a different menuitem?



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 June 2016 - 07:54 PM

Is that/those PC(s) stuff BIOS or UEFI?

(on BIOS grub4dos would do)

If having a (smallish) FAT12/16 partition is possible it also has filesystem write access.

 

Strictly technically, however you don't really-really need write access to the filesystem, you can dd a (copy of) \boot\BCD to the exact blocklist of the "current" \boot\BCD (BCD are more or less "static" in size, being essentially a database), grub4dos has the dd and the blocklist commands built in, cannot say grub2.

 

You mean Wioski:
http://www.wioski.com/

 

Isn't it possibe to make a "mix" between SS and wioski?

 

 

:duff:

Wonko



#3 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 13 June 2016 - 10:15 PM

Yes, wioski, that's it. Concerning a hybrid, the reason I can't use wioski is due to problems with Windows setup.exe, which is a crucial component Wioski relies upon. Setup refuses to accept my customized wim file, which is almost 10GB in size. Setup runs for quite awhile and finally pops up an error like: "Setup cannot install Windows on your hardware", which is total bull, the wim image works just fine when installed manually with imagex or using SS. I also know very little about /unattend.xml files, which Sami Laiho relies on for Wioski.

 

Even sysprep has issues with my Windows and produces an "unknown error", 0x80070026 for example. I found a way around that by stopping the Windows Media Player Network Sharing Service" before running sysprep.

 

As for using dd to copy, that's an interesting thought. However, you must remember it needs to run in a grub2 bootloader context, which I believe rules out dd, since there is no operating system or filesystem device drivers. And strickly speaking, any copy or move of files in the filesystem requires write access to the filesystem.

 

I probably could use use grub4dos, but I don't want to. I may as a very last resort (nothing against it, it's a versatile bootloader), but I have less experience with it, especially when it comes to creating nice, pretty GUI boot screens. The fact that grub2 is also the bootloader of choice for most Linux distros is another reason I prefer to stick with grub2.

 

If I could resolve the setup problem I actually prefer the Wioski approach over SS, SS being more of a proof of concept and learning tool for running Windows from a VHD. Aside from the role /unattend.xml plays in Wioski, it too is just a few cmd scripts which can be changed fairly easily. Typical of Microsoft to only offer cryptic error messages rather than useful info that would provide information to understand the context of the error.

 

The 160GB disk uses a MFT partition scheme, and all 4 entries are currently used. Could use an extended partition, but I'd prefer not to.

1)     1GB   System Reserved - boot disk for WinPE and SS files. Becomes drive X under WinPE.

2)     4GB   Linux swap partition (I could free this up by using a dedicated swap file in the OS partition)

3)   13GB   Linux Mint OS partition (everything, /boot, /usr, /home ...)

4) 130GB   Physical Drive (remainder of disk to store VHD files)

 

You did spur my thinking tho Wonko. If another partition could be made available I could have an alternate bootmgr and BCD installed there, and grub2 could hide one of them and boot the other. The difference between them: one boots WinPE (for maintenance) the other snapshot.VHD. However, each boot of Windows from the snapshot.VHD requires a "reset" snapshot.VHD so any changes from the last Windows session would be discarded. That requires diskpart. I can create a fresh snapshot.VHD in maintenance mode and just save a copy of it, and copy that into place to boot from it. So I'm right back to the same problem of needing grub2 to copy at least 1 file into place.

 

 



#4 cdob

cdob

    Gold Member

  • Expert
  • 1343 posts

Posted 14 June 2016 - 04:34 AM

However, I got around that by creating a one line shutdown script in Windows that uses bcdedit to switch the default bootmgr entry, so on shutdown that script sets the default to boot WinPE, which will perform the "rollback" and reboot to the snapshot.VHD file.

What about (not tested):
at shutdown
-create a new differencing VHD file
-bcdedit: make this the default boot next time
-bcdedit: remove the current OS
-create a cleanup.cmd to delete the currently used VHD file

at startup
call the cleanup.cmd, this deletes the previous used VHD file

#5 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 June 2016 - 05:48 AM

What about (not tested):
at shutdown
-create a new differencing VHD file
-bcdedit: make this the default boot next time
-bcdedit: remove the current OS
-create a cleanup.cmd to delete the currently used VHD file

at startup
call the cleanup.cmd, this deletes the previous used VHD file

 

Nice try cdob but no prize :loleverybody:

 

Windows 7 is always running on a VHD file, and that file is locked, as is the "parent" VHD file (In M$ parlance the parent is the main VHD file for the operating system, and the child VHD file is the differencing or snapshot VHD file, which bootmgr loads), so it cannot be removed while the OS is running on it! That would be like HAL 9000 pulling the plug that provides all its electrical power.

 

A lock on the VHD files is essential for stability of any operating system that would use the VHD as its only filesystem.



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2016 - 08:06 AM

Well, nothing prevents you to use grub2 as "main" bootmanager" and use grub4dos "silently" as if it was merely a mini-OS to dd the BCD file (or whatrver) and boot. (BTW AFAIK recent grub4dos have nice graphical capabilities, including animated splashscreens and - though I am not at all in the "graphic" part - I can see nothing that it misses when compared with grub2). 

 

Or you could still use the "Vista boot floppy" approach (as an image), you have two of such images and you use grub2 (I believe that with grub2 you need memdisk, whilst grub4dos has builtin support for this scenario) to choose which one you boot each time.

 

More generally, you can't be serious about grub4dos and unattend.xml, if you can manage the complexities of grub2, you wont' have really any problem with either.

 

Yours is not the first (nor will be the last I believe) report about issues between Windows Media Player Network Sharing Service and Sysprep, it is a known issue that the good MS guys NEVER solved:

https://social.techn...=w7itproinstall

stopping the Service is obviously only a workaround, the "root cause" has yet to be found, I believe.

 

 

:duff:

Wonko



#7 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2016 - 02:42 PM

On second thought, if the switch is between the "real" OS ("flat" or in a vhd, but with an "external" BOOTMGR and \boot\BCD) and a WinPE, you could use wimboot:

http://ipxe.org/wimboot

through grub2.

Example (UNtested):





menuentry "WinPE as .iso on 1st disk, 1st part" {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
 loopback loop /WinPE.iso
 linux16 /wimboot
 initrd16 \
 newc:bcd:(loop)/Boot/BCD \
 newc:boot.sdi:(loop)/Boot/boot.sdi \
 newc:boot.wim:(loop)/sources/boot.wim
 }

menuentry "WinPE as .wim on 1st disk, 1st part" {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
 linux16 ($root)/wimboot
 initrd16 \
 newc:bcd:($root)/WinPE/BCD \
 newc:boot.sdi:($root)/WinPE/boot.sdi \
 newc:boot.wim:($root)/WinPE/boot.wim
 }

menuentry "Windows 7 on 1st disk, 1st part" {
     insmod part_msdos
     insmod ntldr
     insmod ntfs
     set root='(hd0,msdos1)'
     ntldr /bootmgr
}

menuentry "Windows 7 on 1st disk, 1st part PBR" {
     insmod part_msdos
     insmod ntfs
     set root='(hd0,msdos1)'
     chainloader +1
}

I would still use grub4dos, but then I am partial to it because it just works, has more features - including as said the inbuilt blocklist and dd commands - and an actual (batch like) scripting language - and it has IMHO a much more intuitive syntax than the overly complex (artificially complicated) GRUB2 one.

 

And now (OT :w00t: :ph34r: but JFYI) a (completely unlike popular :() idea, COSMIAS:
http://reboot.pro/to...-to-g4d-images/

 

:duff:

Wonko



#8 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 June 2016 - 02:56 PM

 

Well, nothing prevents you to use grub2 as "main" bootmanager" and use grub4dos "silently" as if it was merely a mini-OS to dd the BCD file (or whatrver) and boot.

True, and g4d is certainly much more lightweight than WinPE. However, using 2 bootloaders this way doesn't eliminate the double boot.

 

 

More generally, you can't be serious about grub4dos and unattend.xml, if you can manage the complexities of grub2, you wont' have really any problem with either.

The reason I prefer not to use g4d as my main boot loader isn't b/c I can't, or it's beyond my capabilities, but rather it's about trying to extend my existing investment of knowledge of grub2. Also I mentioned grub2 is used by almost every Linux distro out there, and I'd rather not have to create a duplicate boot loader in g4d for them should I wish to do something similar. Not sure what the extent of g4d's graphical / theme functionality is. I do know it allows for background images, albeit using the large BMP format. Not sure about progress bars, fonts, colors etc.

 

You also assume that I can learn how to use g4d as well as I know how to use grub2 as easily as Carrie Ann Moss learned how to fly a helicopter in Matrix 1. I'm not "jacked in", so it takes time for me, and I hope I don't need to spend that time learning how to do things I already know how to do with grub2. grub2 just needs "a little bit more" for this situation. Although it makes sense, I never knew until 2 days ago that grub2 has no filesystem write functionality built in. It does provide for expansion through modules, if I can find some examples as a dev guide I might be able to create a simple file copy module.

 

One thing tho, when it comes to pushing the envelope of bootloader development and ability to find info, there is much more of a community of those experimenting with g4d than with grub2. It really took some hard digging to find how to compile grub2 with lua, and extremely little about how to write your own grub2 module.

 

It's interesting that apparently very few others have needed to have filesystem write functionality or feel the need to extend grub2 by writing their own module. Those that may have gone down that path either are not very vocal about it or there just aren't many problems where that is seen as the best solution.


Edited by thomnet, 14 June 2016 - 03:33 PM.


#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2016 - 03:26 PM

However, using 2 bootloaders this way doesn't eliminate the double boot.

Yes and no (as often happens).
 
"Your" approach is:
BIOS->GRUB2->WinPE->*actions*->reboot->BIOS->GRUB2->BOOTMGR <- you go through BIOS and thus is a reboot
The suggested one is:
BIOS->GRUB2->grub4dos->*actions*->BOOTMGR <- you DO NOT go through BIOS and thus it is NOT a reboot, strictly speaking
The "right" approach ;) being:
BIOS->grub4dos->*actions*->BOOTMGR <- (simpler)
 
If there was a working Kexec for WinPE , i.e. Winkexec:
http://reboot.pro/to...-based-systems/
http://reboot.pro/to...oader-possible/
you could do the same with the WinPE
 
Though of course booting to grub4dos, quickly blocklist and dd a 256 kb file and pass on to chainload BOOTMGR will be if not instantaneous, very, very quick, if you want it is the same "concept" used for PassPass:
http://reboot.pro/to...s-the-password/
http://reboot.pro/to...-11#entry187362

But the whole point (if you want the only "elegant" part in the approach) is that by having this internal to grub4dos you:

  • boot to grub4dos
  • patch the file
  • continue booting to the "resident" patched Windows install
as opposed to:
  • boot *some other* OS
  • patch the file
  • reboot, booting this time to the "resident" patched Windows install

The system boots to grub4dos, a grub4dos batch *does something* and then the system continues booting to windows, in this case more than a bootmanager, grub4dos behaves as a mini-os and os loader.
 
 
:duff:
Wonko



#10 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 June 2016 - 03:32 PM

 

menuentry "WinPE as .wim on 1st disk, 1st part" {
insmod part_msdos
insmod ntfs

set root='(hd0,msdos1)'
linux16 ($root)/wimboot
initrd16 \
newc
:bcd:($root)/WinPE/BCD \
newc
:boot.sdi:($root)/WinPE/boot.sdi \
newc
:boot.wim:($root)/WinPE/boot.wim
}

 

Ah, wimboot. I've seen it mentioned here in many topics, but I always assumed from the context wimboot is native Windows 8 / tablet functionality, and not available for use with Windows 7 and earlier OSs.

 

Is the wimboot discussed at the URL you provided something else, or have I misunderstood what wimboot is?

 

If it works it would allow me to boot WinPE from grub2, albeit using this wimboot rather than chainloader / bootmgr. Nice! Thanks for that!

 

I'm just left with finding a solution to put a fresh snapshot.VHD file in place (a copy of one created by diskpart) and then booting it.



#11 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 June 2016 - 03:52 PM

 

"Your" approach is:
BIOS->GRUB2->WinPE->*actions*->reboot->BIOS->GRUB2->BOOTMGR <- you go through BIOS and thus is a reboot
The suggested one is:
BIOS->GRUB2->grub4dos->*actions*->BOOTMGR <- you DO NOT go through BIOS and thus it is NOT a reboot, strictly speaking
The "right" approach ;) being:
BIOS->grub4dos->*actions*->BOOTMGR <- (simpler)

 

Now I see what you mean by a hybrid approach. Although less elegant than the last line, it appeals to me in that I don't need to scrap my investment in grub2 knowledge and encapsulates the special processing in the g4d code. That might just be the way to go unless I find a way to create a file copy module for grub2.

 

When you said you're biased toward g4d and referred to gurb2 systax as less readable, I am similarly biased towards grub2. Our biases come more from familiarity and personal preference than technical capabilities. However I will grant you that g4d provides a rich(er?) set of functionality than grub2 and has a more vibrant support community. I am not sure about the way g4d is built, but IMO grub2's modular approach using ELF32 mod files to extend grub2 without the need to rebuild grub2 entirely is architecturally a very sound approach.

 

I will have to test the hybrid idea of grub2--> g4d--> [dd snapshot & BCD into place]--> bootmgr--> Windows.VHD to measure boot cycle time AND for vulnerability to interrupt / intercede in the boot process (can g4d be made to lockout user's inputs & attempts to abot the boot process?)


Edited by thomnet, 14 June 2016 - 03:55 PM.


#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2016 - 04:42 PM

(can g4d be made to lockout user's inputs & attempts to abot the boot process?)

Sure (actually again yes and no).

There are a number of tricks, most of them you can find here:

http://www.rmprepusb...orials/grub4dos
http://www.rmprepusb...c-grub4dos-menu

 

Besides (say) showing a nice image, you might want to additionally edit the "embedded" menu.lst in grub.exe so that you remove the need for an "external" menu.lst and add a password protection, and possibly use hotkey to disable the "c" for command line.

 

:duff:

Wonko



#13 cdob

cdob

    Gold Member

  • Expert
  • 1343 posts

Posted 14 June 2016 - 04:50 PM

It does NOT provide the ability to always reboot to a standard "template" version of the OS, thereby ALWAYS discarding the snapshot.VHD file

Do I misunderstand the whole request?
Do you like to ALWAYS reboot to a new diff VHD file?
Do you need a maintenance mode, to keep the changes and create a new snapshot?
  

Windows 7 is always running on a VHD file, and that file is locked

Adjust the idea to a working condition: use a file copy
Create the diff base VHD at maintenance mode.
At reboot use a copy from this diff base VHD

Create the base "c:\vhd\base.vhd" file.
Install Windows 7 and configure it.
This is the standard "template" version of the OS.

Prepare once at a PE:
Create a original diff vhd file. And use a addional file copy.

DISKPART> CREATE VDISK FILE="c:\vhd\diff#orig.vhd" PARENT="c:\vhd\base.vhd"
copy /b c:\vhd\diff#orig.vhd c:\vhd\diff_01.vhd
bcdedit /store \boot\bcd /set {default} device vhd=[C:]\vhd\diff_01.vhd
bcdedit /store \boot\bcd /set {default} osdevice vhd=[C:]\vhd\diff_01.vhd

At running windows diff_01.vhd, copy original file to a new file
copy /b D:\vhd\diff#orig.vhd D:\vhd\diff_02.vhd
bcdedit /set {current} device vhd=[D:]\vhd\diff_02.vhd
bcdedit /set {current} osdevice vhd=[D:]\vhd\diff_02.vhd

The next boot uses \vhd\diff_02.vhd.
Both files are at hard disk \vhd\diff_01.vhd and \vhd\diff_02.vhd.
Obviously you need storage space for all the files.

At startup delete diff_*.vhd files.
The current active diff_*.vhd file is locked. Delete will fail, this is good.
Other old files are deleted.


Added:
Create some logic to diff_*.vhd file names.
Can be run at startup or shutdown:
if exist c:\vhd\maintenace.flag (echo maintenance mode, do nothing & goto :eof)
del c:\vhd\diff_*.vhd
set diff_new=\vhd\diff_01.vhd
if exist d:%diff_new% set diff_new=\vhd\diff_02.vhd
if exist d:%diff_new% (echo error: exist d:%diff_new% &pause)
copy /b D:\vhd\diff#orig.vhd D:%diff_new%
bcdedit /set {current} device vhd=[D:]%diff_new%
bcdedit /set {current} osdevice vhd=[D:]%diff_new%

The file c:\vhd\maintenace.flag is a flag file to enable a maintenance mode: keep current setting on reboot

#14 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 14 June 2016 - 05:04 PM

 

Do I misunderstand the whole request?
Do you like to ALWAYS reboot to a new diff VHD file?
Do you need a maintenance mode, to keep the changes and create a new snapshot?

Perhaps you did.

Always, UNLESS the maintenance flag file is present in which as just boot WinPE.

Yes.

 

As for the remainder of your reply, MOST EXCELLENT CDOB, I think you found the perfect solution! I don't see any issues with that approach, I think it will work fine. It also eliminates any type of secondary boot element like g4d.

 

I can use the info Wonko posted to boot WinPE directly for maintenance mode. There's even no need for a menu entry for maintenance mode, just insert a USB key with the correct file name on it and grub2 can detect it and boot WinPE without even showing a menu. This is also the most secure approach.


Edited by thomnet, 14 June 2016 - 05:41 PM.


#15 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2016 - 05:16 PM

Re: Wimboot

The good developers have not that much amount of fantasy, there is the iPXE wimboot (that besides the network capabilities can chainload a PE wim "locally"):
http://ipxe.org/wimboot

http://reboot.pro/to...imboot-support/

 

And the wimboot that was one of the (few) nice features of Windows 8.1 (for the "whole" system, not for a PE):

https://technet.micr...y/dn621983.aspx
http://reboot.pro/to...e-boot-wimboot/

otherwise referred as "WOF driver":

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

that (since it was actually intelligent and working) has been abandoned or deprecated in Windows 10:
http://reboot.pro/to...oot-deprecated/

 

:duff:

Wonko



#16 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 18 June 2016 - 03:26 PM

Perhaps you did.

Always, UNLESS the maintenance flag file is present in which as just boot WinPE.

Yes.

 

As for the remainder of your reply, MOST EXCELLENT CDOB, I think you found the perfect solution! I don't see any issues with that approach, I think it will work fine. It also eliminates any type of secondary boot element like g4d.

 

I can use the info Wonko posted to boot WinPE directly for maintenance mode. There's even no need for a menu entry for maintenance mode, just insert a USB key with the correct file name on it and grub2 can detect it and boot WinPE without even showing a menu. This is also the most secure approach.

 

UPDATE: I have not been feeling well the last several days so I haven't yet completed all of the script rewriting I need to do. However, I have proven several concepts discussed here:

 

1) Wonko's grub2 syntax to load WinPE from a .wim file using iPXE's wimboot - works perfectly as posted above. However, and I didn't take the time to investigate this, WinPE booted that way did NOT see the local hard drive and so will not work (diskpart listed only 1 drive which was the WinPE drive) for me here. Since WinPE is mostly useless with the ability to access local drives, I suspect there is a workaround for this or something I did wrong. More investigation is required.

 

2) CDOB's idea of doing the copying and switching the default boot entry between different snapshot.vhd files (one in use currently and the other for the next boot) all at Windows shutdown time (I don't bother cleaning up the old snapshot.vhd file at startup; it will be overwritten with a fresh version on the next shutdown). Although accomplished differently, I believe the Wioski approach also avoids the 2 boot cycles that SS requires for rollback by using 2 difference.vhd (snapshot) files. This is a tradeoff of disk spaced used vs. reboot cycle time. Wioski's documentation states that the size of the physical HDD must be at least 2.5 times the Windows image size (size of filesystem reported by Windows). A 40GB Windows filesystem will require a minimum of 100GB. Thus a 160GB drive is more than enough, even with 20GB of disk reserved for Linux.

 

This is a vast reduction of the reboot cycle time required to restore the "template" operating system.

I need to investigate how grub2 can test if a file exists on a USB device. I quick perusal of the manual leads me to this that's quite possible but I haven't tried that yet.

 

:worship: Thanks to all who contributed to this solution. Once I get all the scripts updated and packaged I will post them online.

 

 

Sysprep, it is a known issue that the good MS guys NEVER solved

...Wonko

With a statement like that I have to question just what you mean when you say "good" ! I myself never use the words good and Micro$oft in the same sentence :logik:



#17 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 June 2016 - 04:56 PM

With a statement like that I have to question just what you mean when you say "good" ! I myself never use the words good and Micro$oft in the same sentence :logik:

I believe that the actual guys at MS are largely good (in the sense of friendly and good willing) and good (in the sense of good - generally - at writing programs) but are misguided by their management, or by their corporation policies (or lack of suitable policies).

It is just like the good Linux (or more generally Open Source) guys, the are largely good (in the sense of friendly and good willing) and good (in the sense of good - generally - at writing programs), but are misguided by their ideology, or by the lack of management (or both), or by the the desire to be "better" or write "better" software than the other guys.

Both groups however generally - for one reason or the other - completely fail to communicate to their user base, to document *anything* properly or at least in an understandable way, or - again for one reason or the other - to produce something in the end that "just works" without the need of complex, tricky or convoluted workarounds.

Still they are both "good" guys. :)

About iPxe Wimboot, what you report is "strange", from what I can understand of the thingy it is just a loader, if the PE boots successfully it should detect the disk it resides on (an exception would be if a driver is missing, just as an example if the boot disk is a USB one connected to a USB 3.0 port). :unsure:

:duff:
Wonko

#18 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 June 2016 - 05:43 PM

Such general statements may sound "nice" and courteous, maybe even "politically correct", but (IMO) they do the public a disservice through their vagueness. They offer an impression that doesn't reflect the reality of the "bad" things such groups do.

 

I suppose it all arises from the generalization that "people are good" and have "good intentions". This BTW, is contrary to the Christian belief system (the "fall" of mankind in the Garden of Eden), not that I'm endorsing that belief. However, sticking to the concept of generalizations I find a measure of hypocrisy in everybody, myself and Christians are no exception.

 

I acknowledge your efforts at being kind and speaking with diplomacy, I just don't believe that is better than being accurate. I am the type to speak specifically and with "precision of language" far more often than I don't.

 

Conveying a concept concisely is also a good and virtuous way to communicate, but many concepts are just too complex to convey concisely. I love it when it can be done -- it's truly a thing of beauty and elegance when it happens. That's what I call quality rhetoric!

 

I hope this reply doesn't offend you Wonko, it's not intended to. I just notice you use the phrase fairly often and it struck me I don't speak of artificial entities like corporations or companies that way, or conflate individual and collective actions together under a common umbrella.

 

Most of the time individuals paid by such artificial entities have delegated their individualism to the entity through the concept of hierarchical authority, which is responsible for the worst atrocities and human death and suffering this planet has ever seen. It makes those who defer their judgement to "authorities" robots, and throughout history that has caused more death and destruction than could be accomplished without it. It is the tool of despots and tyrants, and people are beginning to catch on. But there will likely be those who prefer to defer rather than develop or use critical thinking skills that would prevent such evil, collectivist actions to occur.

 

I'm not saying hierarchical authority is bad, it's just a tool which can also be use to accomplish good things. The point is that our words are tools that operate in the same fashion, for either good or evil. They are powerful and can only be created from the thoughts of natural individuals, not groups or artificial entities.


Edited by thomnet, 20 June 2016 - 05:44 PM.


#19 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 June 2016 - 06:02 PM

Back to the OP topic. I'm still working through testing and script changes. After CDOB posted his idea of using 2 different VHD files I could see it was going to require non-trivial changes. At that point I considered rewriting the scripts with WSH instead of the CMD batch language, but decided not to take the time to do that.

 

That probably wasn't the wisest decision in retrospect. I forgot just how nuanced and difficult the CMD parser is. I have spent more time working through that which could have been avoided had I used JScript under WSH. And that raises the question of why Micro$oft came up with "powershell" in the first place instead of using and extend their WSH offerings as their mainstream choice for scripting on the Windows platform.

 

The process is taking far longer than I would have ever anticipated. I should have recognized I have far more experience with WSH and Javascript than I do in CMD batch, but was hoping the changes wouldn't be as extensive as they're turning out to be.



#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 20 June 2016 - 06:10 PM

You may want to read my "good" more as "innocent until proven guilty", if you prefer :):

https://en.wikipedia...on_of_innocence

and more generally I like razors :w00t: :ph34r:, namely, besides Occam's one, Hanlon's:
https://en.wikipedia.../Hanlon's_razor

 

Is not at all about being "politically correct", as an example I believe that the people that wrote the EFI specifications and that pushed it's adoption (including the GPT) and most of the people that implemented them in firmwares should be severely punished (and a trial in this case wouldn't even be really needed ;)):
http://www.imdb.com/...?item=qt0471984

and I tend to also mention that fairly often.

 

And now just to prove how little politically correct I am, I will underline how you were given a simple, linear solution requiring possibly 5 or 6 lines in a grub4dos batch and another one using a simple floppy image, and for either "ideology" or "pursuit of elegance" (or whatever other reason) you chose to go through a more complicated path, and you are still struggling with it. :jaclaz:

 

 

:duff:

Wonko



#21 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 June 2016 - 10:09 PM

 

And now just to prove how little politically correct I am, I will underline how you were given a simple, linear solution requiring possibly 5 or 6 lines in a grub4dos batch and another one using a simple floppy image, and for either "ideology" or "pursuit of elegance" (or whatever other reason) you chose to go through a more complicated path, and you are still struggling with it.

I won't argue that the alternative approach of using g4d (if you already know it's syntax and various idiosyncrasies) would be quicker and perhaps cleaner to implement, but as I stated (tho you haven't quite grasped yet, apparently) I did not want to use g4d and have to go through a learning curve to discover what I already knew how to do in grub2 (speaking primarily of themes and UI presentation). It also didn't seem to register with you about why learning more about grub2 vs g4d was a higher priority for me.

 

"It's all good" as they say however. Our difference of perspective concerning the value g4d or grub2 provides is not of concern to me at all. As I also said above, g4d is a fine and very feature rich bootloader that clearly has advantages over grub2. If the Linux world had adopted g4d instead of grub2 I might never have learned grub2.

 

As for my continued struggle, that has far more to do with CMD than grub2. As to how elegant and linear your alternative g4d solution was is debatable, but no worse than others I considered. IMO CDOB's approach is even more elegant than your use of g4d, in that it takes the bootloader out of the equation, meaning it doesn't require the bootloader to copy files or manipulate the booting process, that is done in the Windows shutdown and Steadier State setup scripts.

 

BTW, I verified that I can access the local disk with the wimbooted WinPE, so I may refine my solution again and simplify the scripts even more by using that to run PE for maintenance (i.e. to merge and update the master template) and save an extra disk partition. 

 

Part of the elegance equation has to do with minimizing the number of external elements required to get the job done, and g4d and the iPXE wimboot are 2 that I had limited to no experience with. Another part of elegance is how much code is required to accomplish a task. WinPE booted directly from grub2 eliminates a lot of CMD code and the need for a dedicated disk partition as Steadier State used. I see using iPXE to load WinPE as an elegant solution, but Windows purists may disagree, if they like the typical Micro$oft method of booting WinPE (bcdedit, registry (i.e. bcd) and bootmgr) and see grub2 + iPXE as external and unnecessary additions.

 

Anyway, I appreciate your thoughtful response and the valuable expertise you share here.



#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 June 2016 - 12:48 PM

Yep :) though , to be fair, cdob's suggestions are usually not only elegant, but also simple enough (at least to me) when compared to - say - recompiling GRUB2 with Lua support.

BTW, and just for the record, the Wimboot suggestion was made because you didn't want grub4dos, while using the good ol' "Vista boot floppy" (ies) approach would require only GRUB2 (+ maybe memdisk, I am not sure if the loopback device in GRUB2 may work with such a floppy image) and it is still - at least in my perverted mind - simpler.

:duff:
Wonko

#23 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 04 July 2016 - 08:31 PM

I wrapped up all but perhaps 0.5% of the coding on this project and deployed it on the systems at the library yesterday, and it is working well.

Many thanks to all those who contributed to the conversation like Wonko and cdob :worship: Without whose help the results wouldn't have been nearly as good.

I believe it was Wonko who may have mentioned the idea of hiding the VHD drive by not assigning a letter to it, so it wouldn't even be possible for a non-privileged user to be aware of its existence. However, I decided not to investigate that in the midst of my efforts to deploy, thinking that if I remove the drive letter and just mount the drive in a folder of the virtualized file system (to provide access for the shutdown script) it would create problems for the OS accessing the pagefile.sys on the physical drive.

The changes to the code to accommodate a folder mounted drive would be trivial however, and only the shutdown script would be affected. It's only a matter of curiosity that I'll try this on a VM or test system here at home. I like the idea of not providing any clues to users that they are running Windows from a virtualized file system, but it's very easy to deny access to the physical drive with the security tab of Windows Explorer, which is what I've done.

If it is possible to remove the drive letter and use a mount point without causing any problems I will probably change it. Given the 10 minute shutdown time I experienced at one point unrelated to the shutdown script (which I never found the cause of, but resolved by starting over from the original sysprepped base image), I didn't want to risk that occurring again when I really needed to deploy the working solution to all of the systems. UPDATE: According to Windows, "Assigning or removing drive letters on the current pagefile or boot volume is not allowed".

I didn't make that decision lightly tho, b/c if it turns out to work OK now, I'll have to redeploy to all of the systems again to put this change into use, plus regenerate the Macrium backup image, which is how I replicate the setup on the other machines.

The process I'm using is to get one system working and setup perfectly, then use Macrium to take a full system backup and I use that image to deploy on the other systems. After the image is restored, I change the computer name and activate the copy with the correct product ID for that system. For linux all I need to do is change the /etc/hostname file. Do any of you see a problem with this process?


Edited by thomnet, 04 July 2016 - 09:09 PM.


#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 July 2016 - 07:31 AM

I don' t know if it is possible to remove the drive letter, of course you can have a "boot" (what MS would call "system") volume without a drive letter and a separated volume for the pagefile, the point is rather about the possibility of having a volume holding the VHD "system" (what MS would call "boot") without a drive letter.

If it is possible :unsure: you can automate the assigning and unassigning of a drive letter to run the script(s) in the scripts themselves.

 

:duff:

Wonko



#25 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 06 July 2016 - 04:56 AM

Reminder:

 

The changes to the code to accommodate a folder mounted drive would be trivial however, and only the shutdown script would be affected.

 

It essentially has nothing to do with the script, which could care less whether the files are accessed from a folder or through a drive letter. The drive letter is just an element in the path to the files, and changes involve only a few variable definitions.

 

The entire issue is how Windows handles the pagefile when running from a VHD volume. It has to do with the Windows internals, the same way it's the Windows internals that allow Ultimate / Enterprise but disallow Professional and inferior releases from running on a VHD volume. They're not technical limitations, only policies that prohibit such things. Of course those policies are implemented in code, so often ways are found to circumvent the policies.

 

Even though I see lots of issues arise here on reboot.pro to find creative ways around such restrictive policies enacted by the "good" guys at M$, I am not willing to spend the time necessary to reverse engineer the boot process just for the sake of hiding the drive letter from users, when adequate protection is easily implemented through to deny access to the VHD volume.

 

It's an intriguing concept to hide the volume, but after seeing the error message when trying to remove the drive letter and recalling the registry values I found controlling the location of the pagefile.sys, and the complication of altering that on a system booted from the VHD file and merging those changes back into the baseline, it was not a difficult decision to just say, stop! Not going down that path for the limited results it would provide if a way to do it is even possible.

 

Can it be done? I don't know. What I do know is the cost to find out is way higher than I want to pay.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users