Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition

[Michael Schierl]

[Please cc: me since I am not subscribed to that list]


Hello,


I know this is getting off-topic, but since I am surprised how many
people here (have to) base their knowledge of booting Windows install
media from rumors and "advertising", I decided to bring in my knowledge
and personal experience about the Windows installer boot process.


>> > This is not an install ISO but a USB install medium.  The USB drive
>> > was written by the Windows Media Creation Tool.  Copying instead a
>> > Windows ISO created by the Windows Media Creation Tool to a USB drive
>> > does *not* yield a bootable USB drive; it does not even boot on other
>> > computers.
>>
>> This would bring the MS-World back in sync with my understanding of UEFI
>> specs and other info sources.
>>
>> But there are substantial rumors that the ISO boots from USB stick.
>> Microsoft is said to advertise it for DVD+R DL and USB stick.
>> (I could not get my hands on ISO or advertising yet ...)

Yes, any Windows install ISO starting from Windows Vista supports
installation from a USB stick. However, that does *not* mean that you
can use a tool like Unix's "dd" to write it to the drive and expect it
to boot (of course you can try, but it won't boot; valid for all Windows
up to latest Windows 10 Insider version). Instead, assuming that you
already have some Windows machine, you can either use the Media Creation
Tool to write the ISO to your USB, or you can use the command line
utilities included in the ISO itself.

On the other hand, in the Windows world this rarely causes any confusion
since no Windows version I've encountered so far contains native tools
to write an ISO (or any other image file) to a USB stick as Unix' "dd"
command would. Starting from Vista you can natively write ISO files to
optical media and since Windows 8 you can mount ISOs as a drive without
burning them, but that "just dd it to a USB key" feature of isohybrid is
mainly useful to people who already have some kind of Unix running.

In case you ever run into the situation to create a USB key from an
Windows install ISO file from another OS than Windows (and you want that
media to boot both on UEFI and CSM), you'd have to resort to third-party
tools like ms-sys that can replicate this installation process, or
chainload the Windows boot loader from another bootloader that supports
it (e.g. from Grub - to get this discussion back on-topic). Or if you
already have such a USB stick of any other Windows version (since
Vista), just mount it, delete all the files and copy all the files from
inside the ISO to it.

Another thing to keep in mind is that until (at least) Windows 7, the
Disk Management GUI refused to change partitioning of external
"removable" mass storage devices, so in case you ever "dd" a smaller ISO
to a larger stick, you would have to resort to third-party software or
the command-line "diskpart" command to regain your USB key's capacity
back. That may be another reason that dd-able ISOhybrid files are mostly
used for Linux installs (since Linux does not have that restriction) and
not used for Windows install media.

> I wonder how other people can get to the impression that their attempts
> succeeded. (Will have to wait for somebody who is willing to go on with
> experiments after perceived success.)

They probably did not use "dd" in the first place to get their ISO to
the USB stick.

>> I will continue testing the Windows 10 USB install medium:
>> /dev/sdb1  *     2048 15728639 15726592  7.5G  c W95 FAT32 (LBA)
>
> That's not an EFI System Partition.
> So i assume the USB stick boots by BIOS and x86 machine code in the MBR.
> Unless we believe in EFI firmware that hops on arbitrary partitions ...

I do not believe that EFI firmware hops on arbitrary partitions either.

On the other hand, all 64-bit EFI firmware versions I encountered so far
(to be honest, I believe all of them were "designed to run Windows"), do
EFI boot from the *first* MBR-style partition of an *external* drive
(e.g. USB), if the partition type is either 0x0B or 0x0C, the partition
is marked bootable, and it contains a FAT32 filesystem with an
/EFI/BOOT/BOOTX64.EFI file on it. I have encountered machines who do not
boot it if only one of these conditions is unmet (different partition
type, not marked bootable, not the first partition slot, or drive was
attached internally via SATA).

I do not know if this is specified anywhere, but if it did not work,
people would complain quickly. My own multiboot USB key (which uses GRUB
for chainloading multiple Linux ISOs via loopback.cfg) also uses that
exact disk layout, and I never had any machine where it could not boot.
(As it has a USB-OTG port, I can even load new ISOs to it from my
smartphone). On the other hand, if I partitioned the USB stick in GPT
mode and used an EFI System Partition as primary partition, Windows
would not assign a drive letter to it when I attach it, and older OSes
would not be able to read the stick at all. (I never heard that the
Windows installer "broke an USB stick", but I heard it multiple times
about Linux installers that used isohybrid. Getting rid of all
partitions always "cured" the USB stick again, but many Windows users
are unable to fix this themselves).


And that is exactly what happens when you "write" a Windows Installer
ISO to a USB key:

It will create a MBR-style partition table with one "bootable" 0x0C
entry spanning the entire device, formats it at FAT32 and copies all the
files in the ISO to it. (In case install.wim is larger than 4GB and the
media creation tool is recent enough, it will run SplitWim to create
install.swm, install2.swm etc. from it and put those on the device
instead). Afterwards bootsect.exe is executed, which writes a MBR and a
partition boot record so that booting in legacy mode works (this is not
required for booting in UEFI mode, but does not hurt either).

So, while the ISO used a UDF filesystem, the USB stick will use a FAT32
filesystem, and since bootmgr can read both, installation will succeed
in either case.

> I do not know how to verify on Windows if the boot used UEFI.  Shall I 
> continue testing?

On a booted (installed) Windows, the easiest way is running msinfo32.exe
(which shows "BIOS Mode: UEFI" in case booted from UEFI, and won't show
it in case it is booted in legacy mode).


When you are in the installer (or any other Preinstallation Environment
or Recovery Environment), you'd have to go to the registry editor (in
case of a standard install media, press next to get to the second
install screen, press Shift+F10 to open a command prompt, and run
"regedit" from there) and check the value of

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PEFirmwareType

It is 1 for Legacy mode and 2 for UEFI mode.


Another option would be to either damage the bootx64.efi file or the
MBR/PBR of the drive.

Also there are two versions of the Boot Configuration Database; the
Legacy one as \BOOT\BCD and the EFI one as \EFI\MICROSOFT\BOOT\BCD (this
is used by dual-arch ISOs so that in BIOS mode you can choose if you
want 32- or 64-bit, but in UEFI mode it will pick 64-bit automatically).
If you delete/rename one of these, the boot manager will stop with an
error instead of booting.


Regards,


Michael