Jump to content











Photo
* * * * * 1 votes

Create a windows system from scratch using Linux


  • Please log in to reply
100 replies to this topic

#1 stangm

stangm
  • Members
  • 4 posts
  •  
    United States

Posted 21 April 2015 - 07:41 PM

I've been doing a lot of googling, and I feel like I am very close to an answer to the following:
 
I would like to do the following from Linux:
  • Partition a disk with NTFS, 2 partitions, a 300 MB system partition, and a 100 GB primary partition
  • Apply a wim image to the primary partition
  • do the equivalent of a BCDboot.exe command to make the system bootable.
Currently we do this in WinPE, but would like to do it in Linux because linux PXE boots a lot faster.
 
I assume I can use fdisk or gdisk in linux to do step 1, and wimlib-imagex to do step 2, but I am stuck on step 3....  Can anyone provide some insight?
 
 
Thanks!!

EDIT/NOTE - This topic has been split from the wimlib, with ImageX implementation thread.

#2 erwan.l

erwan.l

    Platinum Member

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

Posted 21 April 2015 - 07:47 PM

I've been doing a lot of googling, and I feel like I am very close to an answer to the following:

 

I would like to do the following from Linux:  

  1. Partition a disk with NTFS, 2 partitions, a 300 MB system partition, and a 100 GB primary partition
  2. Apply a wim image to the primary partition
  3. do the equivalent of a BCDboot.exe command to make the system bootable.

Currently we do this in WinPE, but would like to do it in Linux because linux PXE boots a lot faster.

 

I assume I can use fdisk or gdisk in linux to do step 1, and wimlib-imagex to do step 2, but I am stuck on step 3....  Can anyone provide some insight?

 

 

Thanks!!

 

for step 3, what about copying the files manualy (bcd folder and eventually bootmgr) and use a disk bootloader such as g4d, grub2, etc ?



#3 stangm

stangm
  • Members
  • 4 posts
  •  
    United States

Posted 21 April 2015 - 07:54 PM

Wow, thanks for the quick response!!!

 

I was hoping to stay with the native windows bootloader.  I am basically trying to replicate what we do today and eliminate a reboot.  Currently we PXE boot to Linux, do some preliminary configuration, then reboot, PXE boot to WinPE, where we do steps 1,2,3 above, copy a few files into the applied image, and then reboot again to allow windows to come up.

 

What we would like to do is eliminate that middle reboot to WinPE.  WinPE boots very slowly over tftp.  If we could accomplish those steps while still in Linux, we could cut a decent amount of time (and complexity) off of our build processes.

 

After reading a little more, it appears that one way may be to capture the system partition from an existing installation and apply that to the 300 MB partition.  Is that reasonable?  



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 April 2015 - 09:17 AM

Well, the issue here is what actually BCDBOOT does.

Basically it does three things:

  1. creates on the target (copying them) 2 (two) needed files, BOOTMGR (in root) and the BCD (in the directory \boot it creates, i.e. \boot\BCD
  2. copies to the \boot a whole set of not really needed files (fonts, etc.)
  3. adds to the \boot\BCD the relevant entry (aimed to basically chainload the WINLOAD.EXE on the specific "other" volume), this is "specific" data, that needs to be tailored on the specific machine/disk/volumes

There are of course NO issues whatsoever for #1 and #2 as all in all it is just a matter of copying a few files and creating a directory structure, but the #3 might be more complex.

 

In other words loosely you can see the BCDBOOT command as if it was a batch script using three commands:

  1. MD
  2. COPY
  3. BCDEDIT

I don't know if any Linux command/tool exists capable of dealing with the BCD directly/easily, there are Windows alternatives to BCDEDIT, but I have no idea if they can be ported to Linux (or if their source code is available).

 

SInce all in all the BCD is a Registry Hive, in theory any tool capable of editing the Registry should do, as an example CHNTPW or LIBREGF:

http://www.forensics...rg/wiki/Libregf

 

Most probably the changes needed to a "template" BCD prepared before and outside the Linux boot are very small so it may be possible, to even do these minor edits with a simpler tool.

 

If you have python available in your Linux you could try libbcd:

https://bitbucket.or...libbcd/overview

 

:duff:

Wonko



#5 erwan.l

erwan.l

    Platinum Member

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

Posted 22 April 2015 - 09:51 AM

Wow, thanks for the quick response!!!

 

I was hoping to stay with the native windows bootloader.  I am basically trying to replicate what we do today and eliminate a reboot.  Currently we PXE boot to Linux, do some preliminary configuration, then reboot, PXE boot to WinPE, where we do steps 1,2,3 above, copy a few files into the applied image, and then reboot again to allow windows to come up.

 

What we would like to do is eliminate that middle reboot to WinPE.  WinPE boots very slowly over tftp.  If we could accomplish those steps while still in Linux, we could cut a decent amount of time (and complexity) off of our build processes.

 

After reading a little more, it appears that one way may be to capture the system partition from an existing installation and apply that to the 300 MB partition.  Is that reasonable?  

 

note that this may be getting away from the topic, but there are other network protocols available to pxe boot : http, iscsi, etc ...

also, the tftp boot can be significantly speed up with bcd options 

ramdisktftpblocksize 32768
ramdisktftpwindowsize 8

  • stangm likes this

#6 stangm

stangm
  • Members
  • 4 posts
  •  
    United States

Posted 22 April 2015 - 12:37 PM

erwan.l 

 

Thanks for the great information.  Unfortunately, I am stuck with tftp for now.  I will look into those settings.  I assume I need to mount the winpe image and run bcdedit to add them?

 

Wonko, good info!  I do have python available, so I will look into that library!!



#7 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 24 April 2015 - 09:55 AM

@stangm
Some thoughts.

 

I would like to do the following from Linux:
1.Partition a disk with NTFS, 2 partitions, a 300 MB system partition, and a 100 GB primary partition
2.Apply a wim image to the primary partition
3.do the equivalent of a BCDboot.exe command to make the system bootable.
...


...I am basically trying to replicate what we do today and eliminate a reboot. Currently we PXE boot to Linux, do some preliminary configuration, then reboot, PXE boot to WinPE, where we do steps 1,2,3 above, copy a few files into the applied image, and then reboot again to allow windows to come up.

I have no idea whether you can use Linux to achieve your goal(s), however if you want to avoid a reboot how about using WinPE to do the preliminary configuration you currently use Linux for?
 

I assume I can use fdisk or gdisk in linux to do step 1, and wimlib-imagex to do step 2, but I am stuck on step 3.... Can anyone provide some insight?


...I was hoping to stay with the native windows bootloader....


I haven't actually used fdisk or gdisk for years, however if step 1 is not completed using WinPE then will you have the relevant BOOTMGR code in the volume boot record? If you plan on using the native windows bootloader then this code is required - that's assuming your are booting any version of Windows released since XP! Unless you use another bootloader and chainload BOOTMGR directly (e.g.Grub4dos).
 

...would like to do it in Linux because linux PXE boots a lot faster.


From what I recall about PXE booting WinPE, the majority of the time is spent copying the .wim file into RAM over the network. What size is your WinPE .wim file? Can you slim it down to speed up the PXE boot process?

 

...I will look into those settings. I assume I need to mount the winpe image and run bcdedit to add them?

There's no need to mount the winpe image - the settings erwan.l mentioned need adding to the BCD store you are using to PXE boot WinPE.

If you plan to use Linux then you will need to find a way to do the following -
  • Add BOOTMGR code to your active partition.
  • Copy BOOTMGR to the active partition.
  • Create (or copy) a BCD store
BCD stores have, IMO, become increasingly complex. From what I recall it used to be possible to create a generalised entry that could be used as a generic BCD store on any system as it wasn't linked to a volume's GUID. Not sure if this is still possible with recent versions of Windows.

Good luck!

Regards,

Misty

#8 erwan.l

erwan.l

    Platinum Member

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

Posted 24 April 2015 - 11:00 AM

 

... From what I recall it used to be possible to create a generalised entry that could be used as a generic BCD store on any system as it wasn't linked to a volume's GUID. Not sure if this is still possible with recent versions of Windows.

....

 

 

Hi Misty,

 

If you have some pointers for this (generic BCD) I'd be interested.

 

It was my understanding that the disk signature was reflected in the BCD, hence tighting a BCD to a disk and preventing to have a generic BCD that would work for all.

If am correct, elements 0x11000001 (Device_ApplicationDevice) and 0x21000001 (Device_OSDevice) contains the disk signature at offset 0x38.

 

So based on that, I would think that you either need to adapt your MBR or the BCD to have a matching disk signature?

Or else have a generic BCD with a generic disk signature (01020304 ?) and ensure that any new disk created gets this disk signature.

 

Regards,

Erwan



#9 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 24 April 2015 - 09:04 PM

@erwan.l
I did a quick test booting 32-bit Windows 7 (Ultimate) SP1 on two different systems using the same BCD store - it worked on my systems.

Application is limited - the BCD store must be on the same volume as the operating system as it uses boot as the path - hence not tying it to a particular device/partition - similar to a generic BCD store for booting WinPE.

It only contains entries for the OS - there are no entries for a recovery environment or {memdiag}.

In my quick test it worked when chainloading BOOTMGR from grub4dos (device (hd0,0) flagged as active and is a dedicated Grub4dos partition - device (hd0,1) contained BOOTMGR, the BCD store and the Windows OS). It also worked when setting device (hd0,1) as the active partition.

Batch file for creating the BCD store -
@echo off
:_start

::_____________________________________________________________

setlocal
set LABEL=Windows
set BCDEDIT=%~dp0bcdedit.exe
set BCDSTORE=%~dp0BCD



cls
Echo Creating store...
%BCDEDIT% /createstore %BCDSTORE%
echo.
echo.

Echo Creating bootmgr entry...
%BCDEDIT% /store %BCDSTORE% /create {bootmgr}
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} description "Boot Manager"
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} device boot
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} timeout 20
echo.
echo.

Echo Adding Windows entry...
for /f "tokens=2 delims={}" %%g in ('%BCDEDIT% /store %BCDSTORE% /create /d %LABEL% /application osloader') do set guid={%%g}
echo guid=%guid%
%BCDEDIT% /store %BCDSTORE% /set %guid% device boot
%BCDEDIT% /store %BCDSTORE% /set %guid% path \Windows\system32\winload.exe
%BCDEDIT% /store %BCDSTORE% /set %guid% osdevice boot
%BCDEDIT% /store %BCDSTORE% /set %guid% systemroot \Windows
%BCDEDIT% /store %BCDSTORE% /displayorder %guid% /addlast
%BCDEDIT% /store %BCDSTORE% /default %guid%
echo.
echo.
endlocal
pause
:_end

I've also attached the batch file I used to create the BCD store (thanks to you erwan.l for educating me on the use of for /f "tokens=2 delims={}" in the batch).

Please test and feedback.

Regards,

Misty

Attached File  Generic.BCD.Store.cmd   1.07KB   1569 downloads

#10 erwan.l

erwan.l

    Platinum Member

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

Posted 26 April 2015 - 08:07 PM

@erwan.l
I did a quick test booting 32-bit Windows 7 (Ultimate) SP1 on two different systems using the same BCD store - it worked on my systems.

Application is limited - the BCD store must be on the same volume as the operating system as it uses boot as the path - hence not tying it to a particular device/partition - similar to a generic BCD store for booting WinPE.

It only contains entries for the OS - there are no entries for a recovery environment or {memdiag}.

In my quick test it worked when chainloading BOOTMGR from grub4dos (device (hd0,0) flagged as active and is a dedicated Grub4dos partition - device (hd0,1) contained BOOTMGR, the BCD store and the Windows OS). It also worked when setting device (hd0,1) as the active partition.

Batch file for creating the BCD store -

@echo off
:_start

::_____________________________________________________________

setlocal
set LABEL=Windows
set BCDEDIT=%~dp0bcdedit.exe
set BCDSTORE=%~dp0BCD



cls
Echo Creating store...
%BCDEDIT% /createstore %BCDSTORE%
echo.
echo.

Echo Creating bootmgr entry...
%BCDEDIT% /store %BCDSTORE% /create {bootmgr}
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} description "Boot Manager"
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} device boot
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} timeout 20
echo.
echo.

Echo Adding Windows entry...
for /f "tokens=2 delims={}" %%g in ('%BCDEDIT% /store %BCDSTORE% /create /d %LABEL% /application osloader') do set guid={%%g}
echo guid=%guid%
%BCDEDIT% /store %BCDSTORE% /set %guid% device boot
%BCDEDIT% /store %BCDSTORE% /set %guid% path \Windows\system32\winload.exe
%BCDEDIT% /store %BCDSTORE% /set %guid% osdevice boot
%BCDEDIT% /store %BCDSTORE% /set %guid% systemroot \Windows
%BCDEDIT% /store %BCDSTORE% /displayorder %guid% /addlast
%BCDEDIT% /store %BCDSTORE% /default %guid%
echo.
echo.
endlocal
pause
:_end

I've also attached the batch file I used to create the BCD store (thanks to you erwan.l for educating me on the use of for /f "tokens=2 delims={}" in the batch).

Please test and feedback.

Regards,

Misty

attachicon.gifGeneric.BCD.Store.cmd

 

 

 

@Mysty : well done.

This is exactly it.

 

I have edited the bcd file generated with your batch and indeed where i was expecting to find my disk signature, there were only 00's :)

To be sure I have modified your batch and replaced boot with partition=c: and here we go : my disk signature was back.

 

So you have answered my question : in order to make a generic bcd (provided that your boot disk is the disk where you system is installed), one need to use the boot keyword.

 

Sidenote, I have replaced set BCDEDIT=%~dp0bcdedit.exe with set BCDEDIT=bcdedit.exe so that the batch would use my system bcdedit (as opposed to bcdedit standing in the batch folder).

 

Thanks !

 

Erwan



#11 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 26 April 2015 - 09:42 PM

@erwan.l
Whilst it was a please to help, credit goes to diddy - it's taken from his BCDEdit Notes (see here).

To be more specific, the Devices page states -
 

...To expand on this, specifying BOOT will force the boot device/partition to be used - this will be the device from which BOOTMGR is loaded. Unlike the other options (e.g. specifying a drive letter) specifying the device as boot will not lock the entry to a particular device by forcing the search for a disk signature and partition offset value...

Regards,

Misty

#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 April 2015 - 11:24 AM

Very good :).

I would say that problem is solved, no need for BCDBOOT nor for BCDEDIT everything leading to "first boot" is possible from the Linux by simply copying a bunch of files:

MBR and PBR code <- unless a third party bootmanager is used

\BOOTMGR

\Boot\BCD <- the "generic" BCD with the "boot" entry

\Boot\* <- the set of fonts and other optional files

 

I believe that the BCDBOOT can be later run from the already booted Windows :unsure: to automatically copy the "optional files" and (if needed) re-specify the \boot\BCD.

 

It will be needed to see if the same applies to EFI/UEFI.

 

:duff:

Wonko



#13 erwan.l

erwan.l

    Platinum Member

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

Posted 27 April 2015 - 12:04 PM

Very good :).

I would say that problem is solved, no need for BCDBOOT nor for BCDEDIT everything leading to "first boot" is possible from the Linux by simply copying a bunch of files:

MBR and PBR code <- unless a third party bootmanager is used

\BOOTMGR

\Boot\BCD <- the "generic" BCD with the "boot" entry

\Boot\* <- the set of fonts and other optional files

 

I believe that the BCDBOOT can be later run from the already booted Windows :unsure: to automatically copy the "optional files" and (if needed) re-specify the \boot\BCD.

 

It will be needed to see if the same applies to EFI/UEFI.

 

:duff:

Wonko

 

Only constraint is to have one unique boot partition (which is always my preference) as opposed to 2 partitions (boot+system) which is the windows setup default.

 

As for EFI, I believe the default windows partition setup is the same (boot+system) so it is very likely that it works the same (but needs to be verified thus).

 

EDIT : we have seriously hijacked synchronicity's topic :) Sorry...



#14 stangm

stangm
  • Members
  • 4 posts
  •  
    United States

Posted 27 April 2015 - 02:23 PM

Would ms-sys be usefui for the MBR?  http://ms-sys.sourceforge.net/

 

This is amazing stuff, and I am learning a ton.    

However, I am starting to feel that my particular use case may be even more difficult.  It looks like you guys have solved the single partition issue,

but I have two partitions, the system reserved partition, and the boot partition, and cannot change that....

 

 

So I need a generic BCDStore that i can place on the system reserved partition....



#15 erwan.l

erwan.l

    Platinum Member

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

Posted 27 April 2015 - 03:13 PM

I dont know about ms-sys but you need to ensure it takes care about the MBR and the PBR.

Although (and Wonko) is far better competent here, you might be able to manage your MBR and PBR with a simple DD command (or dsfo/dsfi it these exist on linux).

But surely, if you can find a command tool that does it for you, then even better.

 

Coming back to the BCD on a system with 2 partitions, one way to tackle this could be to 

-have a template bcd with a known disk signature

-push this disk signature to the MBR (still with dd).

 

As this is deviating from the original topic, what about moving this to a new thread (copy paste the last threads may be into a new one?).

Surely this is an interesting topic : create a windows system from scratch from linux using wimlib for the last imaging part.

 

Regards,

Erwan
 



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 April 2015 - 03:15 PM

Would ms-sys be usefui for the MBR?  http://ms-sys.sourceforge.net/

 

This is amazing stuff, and I am learning a ton.    

However, I am starting to feel that my particular use case may be even more difficult.  It looks like you guys have solved the single partition issue,

but I have two partitions, the system reserved partition, and the boot partition, and cannot change that....

 

 

So I need a generic BCDStore that i can place on the system reserved partition....

Well, that ms-sys thingy is nice but not really *needed* you can use dd alright for that.

 

You cannot have a "generic BCDstore" outside the "boot" partition, (just for the record it is fun how in this instance they seemingly "got it right" :dubbio:) as usually the good MS guys use the naming reversed from common sense:
http://www.multiboot....uk/system.html

 

Still nothing should prevent you from having (temporarily) the BOOTMGR and the \boot\BCD on a partition (made temporarily Active) where ALSO the OS (i.e. the \Windows\ ) resides, and then, after first boot, change the active partition and run the BCDBOOT from within the booted Windows OS, or copy and re-specialize the BCD:

http://www.multiboot...ml#respecialize

Or use a third party bootmanager (such as grub4dos) to boot the non-active partition first time.

 

Really, we are going WAY off-topic, please do start a NEW topic about your issues/problems doubts in order to stop this hijacking (and hopefully an Admin/Mod may be able to move your off-topic related posts to this new thread).

 

:duff:

Wonko



#17 erwan.l

erwan.l

    Platinum Member

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

Posted 27 April 2015 - 03:21 PM

I see Wonko and I share quite a few ideas in common : feels good :)



#18 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 29 April 2015 - 03:38 PM

@stangm

To sum up the requirements -

An Operating System(s) is PXE booted to prepare the PC. This is currently Linux for some preliminary configuration, followed by WinPE after a reboot.

You would like to eliminate the reboot and do everything via Linux.

The PC must be set up with two partitions (both formatted with NTFS) -
  • 300MB system partition (presumably the active partition containing windows boot files?)
  • 100GB primary partition (presumably the partition used for the Windows OS that is being installed/applied)
A Windows OS is installed/applied to the PC after the disk is partitioned.

The native Windows boot loader (BOOTMGR) must be used to boot Windows.



Notes\Questions

Unless you go with Suggestion 1 (see below) the first thing to test is whether the required BOOTMGR code can be added to the volume boot record using Linux. This code is automatically added when the partition is formatted in WinPE (versions 2.*/3.*/4.0/5.* anyway). Does formatting the partitions in Linux add this code? Can any third party application be used instead.

If you can't add this code via Linux then you can still try Suggestion 3.

You mention that Linux is used for Preliminary configuration - what does this actually mean (what are you doing)?



Suggestion 1

Forget about Linux and PXE boot WinPE - using it for the preliminary configuration instead of Linux.

What preliminary configuration are you actually doing? Is it possible to use WinPE instead of Linux for the preliminary configuration? If not, why not?

WinPE can be automated to partition and format the hard drive, apply the wim image and run bcdboot to create all of the required boot files - all without user intervention.

erwan.l has already provided some settings that might speed up network booting WinPE.

Why overcomplicate things?



Suggestion 2

Now lets assume that you can't do the preliminary configuration in WinPE and are tied to Linux.

Or maybe you just want to see if it's possible to do everything in Linux anyway. I have no problem with that - we like experiments here at reboot - in fact they're encouraged. After all, as erwan.l mentioned earlier -

...Surely this is an interesting topic : create a windows system from scratch from linux using wimlib for the last imaging part.


You now have a hell of a lot of work ahead of you deciding which suggestion(s) to experiment with and then testing - you're going to be the one doing the heavy lifting after all.

I'm going to use the grub4dos device syntax in the notes/suggestions below.
  • (hd0,0) - 300MB system partition
  • (hd0,1) - 100GB primary partition (Windows OS)
  • PXE boot Linux.
  • Complete your Preliminary configuration
  • Partition the HDD
  • Format the partitions (NTFS)
  • Mark (hd0,1), the Windows partition, as the Active (boot) partition
  • Add BOOTMGR code to the (hd0,1) and (hd0,0) volume boot records - that's assuming it wasn't added when the partitions were formatted
  • Apply your wim file to (hd0,1)
  • Copy BOOTMGR to (hd0,1)
  • Copy the generic BCD store (the one that uses boot as path) to (hd0,1)\boot
  • Reboot the PC - Windows should boot from (hd0,1)
Once you have finished booting into Windows on (hd0,1) you can run a batch script (as Admin) to automate the following -
  • Run diskpart to mark (hd0,0) as active
  • Run bcdboot.exe to add the required boot files to (hd0,0)
I'm not sure how to add the BOOTMGR code to the volume boot records using Linux. Also not sure if the very basic generic BCD store will work with newer versions of Windows - you'll need to test this yourself. You will need to generate a different BCD store if the system uses UEFI firmware (hopefully by just making some simple changes to the bcdedit script I posted previously).

I'm not sure if running bcdboot will add BOOTMGR code to (hd0,0)'s volume boot record - hence doing this at the same time as adding the code to (hd0,1).

If you can't add the BOOTMGR code from Linux then you'll have to try suggestion 3.



Suggestion 3
  • PXE boot Linux.
  • Complete your Preliminary configuration
  • Partition the HDD
  • Format (hd0,1) as NTFS
  • Apply your wim file to (hd0,1)
  • Copy BOOTMGR to (hd0,1)
  • Copy the generic BCD store (the one that uses boot as path) to (hd0,1)\boot
  • Reboot - booting to Grub4dos (possibly by PXE booting a Grub4dos floppy disk image?)
  • Chainload (hd0,1)\BOOTMGR from Grub4dos (eliminating the need for BOOTMGR code in the VBR) - this should boot Windows
Once you have finished booting into Windows on (hd0,1) you can run a batch script (as Admin) to automate the following -
  • Run diskpart to format (hd0,0) - adding BOOTMGR code to the volume boot record
  • Run diskpart to mark (hd0,0) as active
  • Run bcdboot.exe to add the required boot files to (hd0,0)
The main advantage of this method is that you will not need to install BOOTMGR code to the volume boot record from Linux - remember I don't know if it's possible to do this. The disadvantage is the need to temporarily install (or PXE boot) a third party boot manager (Grub4dos will definitely do the job - not sure about other alternatives) via the PXE booted Linux.



Other Suggestions

I'm reluctant to mention anything in detail until you can confirm whether BOOTMGR code can be added to the volume boot record using Linux. erwan.l mentioned a BCD store with a known disk signature - the same disk signature can be written to the local HDD - and possibly changed afterwards to avoid all of your PC's having the same disk signature.


NOTE - The suggestions in this post are also based on posts from erwan.l and Wonko

Regards,

Misty

P.s. I've PM'd Nuno with a request to have this thread split - apologies for continueing with the Off-Topic discussion until then!
  • Brito likes this

#19 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 29 April 2015 - 05:37 PM

1. Creating an NTFS filesystem on Linux using 'mkntfs' (which is part of NTFS-3g) will automatically create the NTFS volume boot record.  This is x86 machine code that loads and executes \bootmgr from the NTFS volume.

 

2. You can indeed use wimlib-imagex to apply a WIM image to a NTFS volume from Linux.  This uses the NTFS-3g support and is almost as capable (and sometimes even *more* capable) than running natively on Windows.  One of the few limitations is that EFS-encrypted files will not be extracted, but such files are not usually present in Windows installation images anyway.
 
So the only difficult part may be dealing with the BCD store --- which *can* be edited from Linux if required since it is the same file format as the Windows registry.  But you'd need to know exactly which changes (if any) need to be made.
 
Edit: yes, if people want to discuss this in more detail another thread would be appropriate.


#20 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 30 April 2015 - 01:45 PM

Topic has been split from the wimlib, with ImageX implementation thread as it was becoming increasingly :offtopic:

I'd have done it sooner, only I didn't realise I had permission and didn't know how! Cheers Nuno :cheers:

Regards,

Misty

#21 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 01 May 2015 - 07:31 PM

Ok, I checked the info here:
https://bitbucket.or...libbcd/overview
against the "generic" boot switch and the (confusing) information provided in the BCD documentation:
https://msdn.microso...7(v=vs.85).aspx

The three BCDEDIT commands:
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} device boot
%BCDEDIT% /store %BCDSTORE% /set %guid% device boot
%BCDEDIT% /store %BCDSTORE% /set %guid% osdevice boot

Correspond to creating three elements (or "keys" in the BCD) of type REG_BINARY, respectively:
\objects\guid1\11000001\Element
\objects\guid2\11000001\Element
\objects\guid2\21000001\Element

where guid1 is the "bootmgr" standard guid {9dea862c-5cdd-4e70-acc1-f32b344d4795} and guid2 is the "item" guid, {7a62acfa-ef5f-11e4-b09c-001fc6bb76ce} in my case.

The 11000001 is defined here:
https://msdn.microso...2(v=vs.85).aspx
as "BcdLibraryDevice_ApplicationDevice"
The 21000001 is defined here:
https://msdn.microso...0(v=vs.85).aspx
as "BcdOSLoaderDevice_OSDevice"

The three REG_BINARY values are 88 bytes, the same for all three keys, consisting of all 00's, with two exceptions:
at offset 0x10 there is the value 0x05
at offset 0x18 there is the value 0x48

if on the same BCD you run the three commands:
%BCDEDIT% /store %BCDSTORE% /set {bootmgr} device partition=c:
%BCDEDIT% /store %BCDSTORE% /set %guid% device partition=c:
%BCDEDIT% /store %BCDSTORE% /set %guid% osdevice partition=c:

the same three keys are modified as follows (and all of them in the same manner):
at offset 0x10 the value 0x06 is written
at offset 0x18 the value 0x48 remains unchanged
at offset 0x20 a value is written which is the offset in bytes to the "partition C:", as an example 007E0000 means 32256 bytes[1]
at offset 0x34 a value of 0x01 is written
at offset 0x38 a value is written which is the disk signature (of the disk on which the "partition C:" resides) exactly as written in the MBR.

If you prefer, these are the same data that you would find in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\DosDevices\C: in the Registry.

Then I hexedited manually the 0x06 to 0x05 and sure enough (notwithstanding the fact that the rest of the data was still there) BCDEDIT returned:
Windows Boot Manager
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device boot
description Boot Manager
default {7a62acfa-ef5f-11e4-b09c-001fc6bb76ce}
displayorder {7a62acfa-ef5f-11e4-b09c-001fc6bb76ce}
timeout 20

Windows Boot Loader
-------------------
identifier {7a62acfa-ef5f-11e4-b09c-001fc6bb76ce}
device boot
path \Windows\system32\winload.exe
description Windows
osdevice boot
systemroot \Windows

So, loosely, at offset 0x10 the 0x05 means "boot" and the 0x06 means "look for disk/partition data following".

 

Resetting to "boot" device through BCDEDIT removes the disk data, besides changing the 0x06 to 0x05.

What remains to be seen/verified is the meaning of the 0x01 at offset 0x34, I tried to change the partition with bcdedit having it pointed to different disks and to various first and non-first, active and not active, primary and logical volumes, but the 0x01 remained always the same, most probably it is just a check/flag of some kind.

Anyway with these info there are no particular issues in hexediting directly a generic "boot" BCD to have it point to a specific (non boot) partition, the sequence:

 

A0 FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 05 00 00 00 00 00 00 00 48 00 00 00

 

is more than enough to find the right locations.

 

The disk signature can be read directly from the MBR and the offset value would be the LBA in the corresponding partition table entry multiplied by sector size (512 or 4096, depending on the specific disk device)

 

:duff:

Wonko

 

[1]Very likely this is a 64 bit value, i.e. actually 007E000000000000


  • florin91 and misty like this

#22 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 02 May 2015 - 07:25 AM

@Wonko
Wow! Great work :cheers: That's a lot of information to digest - thanks for the hard work and analysis.

So if I interpret this correctly then, assuming stangm uses the exact same partition structure on all of his systems (with the same partition offsets), all he needs to do is -
  • Copy an existing BCD store to the target system.
  • Check the target systems disk signature (or add a randomly generated one if a disk signature wasn't created when partitioning the disk in Linux).
  • Edit the relevant entries in the BCD store at offset 0x38 - changing the existing value to the disk signature found/added in the proceeding step.
I know how to do the above in Windows - no idea what tools to use in Linux though. Over to you stangm.

Regards,

Misty

#23 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 02 May 2015 - 07:43 AM

A approach based on chenall: edit bcd on the fly
A dummy bcd file created.
At boot the MBR signature and partition offset adjusted.

http://chenall.net/post/ntboot/
http://reboot.pro/to...e-2#entry145675

Given the same partition layout

a 300 MB system partition, and a 100 GB primary partition


@stangm
Are there one hard disks or more (USB) disks?
Can you set a fixed MBR signature? Unique at the machine hard disks?

Idea:
use a fixed MBR signature and the same disk layout.
One "generic" BCD file should work at 300 MB / 100 GB (offset importand, not partition size) disk layouts.

Edited by cdob, 02 May 2015 - 07:48 AM.


#24 erwan.l

erwan.l

    Platinum Member

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

Posted 02 May 2015 - 09:51 AM

 

Anyway with these info there are no particular issues in hexediting directly a generic "boot" BCD to have it point to a specific (non boot) partition, the sequence:

 

A0 FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 05 00 00 00 00 00 00 00 48 00 00 00

 

is more than enough to find the right locations.

 

 

Provided that you have one unique partition (boot+system) right ?

 

This is a different approach than going for a fixed diskid matching in the MBR and BCD.

This later approach being necessary when you have 2 partitions (boot+system).



#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 02 May 2015 - 10:23 AM

Provided that you have one unique partition (boot+system) right ?

 

This is a different approach than going for a fixed diskid matching in the MBR and BCD.

This later approach being necessary when you have 2 partitions (boot+system).

 

Please read the following:

What remains to be seen/verified is the meaning of the 0x01 at offset 0x34, I tried to change the partition with bcdedit having it pointed to different disks and to various first and non-first, active and not active, primary and logical volumes, but the 0x01 remained always the same, most probably it is just a check/flag of some kind.
 

as ;):

What remains to be seen/verified is the meaning of the 0x01 at offset 0x34, I tried to change the partition with bcdedit having it pointed to different disks and to various first and non-first, active and not active, primary and logical volumes, including obviously multi-partition devices, including a first primary partition and a second volume, either primary or logical inside extended, but the 0x01 remained always the same, most probably it is just a check/flag of some kind.

 

Or if you prefer as:

I tried all possible "normal" configurations involving a disk with two volumes (which is what the OP depicted/asked for) and I was not capable of finding one where the 0x01 at offset 0x34 wasn't present.

 

 

@cdob

Yep :), the added info is that - if needed - instead of using a pre-made "partition=" BCD and later change just the disk signature (and in case the volume offset) one can use a more generic "boot" BCD and write directly the "kind of BCD" (replacing the 0x05 with 0x06), add the 0x01 and write directly the disk signature and offset.

 

@all

 

The actual info is almost entirely on the given resource:

https://bitbucket.or...libbcd/overview

I simply checked that and hopefully made it more explicit, providing tentatively an explanation for the 0x06 (and for the 0x05).

 

I presume that under Linux there are more than one tool *like* gsar and hexedit/dumphex or more similar to the grub4dos cat command, possibly xxd (together with cat and dd that are *everywhere* already):

http://www.tutorials...ommands/xxd.htm

 

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users