48 replies to this topic

[sebus]

Let me try again, I never previously used UEFI, hence the previous setup was not anything I tested.

Up to now I only used legacy BIOS PXE in following way (which still works perfectly)

 

PXE->iPXE.kpxe (via MS DHCP options 60/66/67) -> pxelinux.0 for menu -> lkrnl.pxe -> wimboot (bootmgr.exe -> BCD (pointing to winload.exe) -> Boot.wim (x64))

 

All I am trying NOW to do is: (with menu from iPXE itself)

 

Server 1 = SCCM/WDS

Server 2 = DHCP

Server 3 = TPS (and separate TFTP service provided by Bootix TFTP server)

 

To run TSP on Server 3 I disable WDS (block UDP 4011 on Server 1 firewall)

 

Testing on

 

Client 1 = Hyper-V VM Gen 2

Client 2 = Physical Optiplex 3040

 

UEFI PXE -> IPXE.efi (build from source) -> menu.ipxe -> wimboot -> (bootmgr.efi -> BCD (pointing to winload.efi) ->Boot.wim (x64))

 

ALL downloads fine, and on boot it just errors out 0xc000000f

#!ipxe
kernel http://10.0.0.55/wim/BOOT/wimboot252 gui
initrd http://10.0.0.55/wim/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd http://10.0.0.55/wim/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd http://10.0.0.55/wim/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd http://10.0.0.55/wim/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd http://10.0.0.55/wim/BOOT/bootmgr.efi bootmgr.efi
initrd -n BCD http://10.0.0.55/wim/EFI/Microsoft/Boot/BCD BCD
initrd http://10.0.0.55/wim/BOOT/BOOT.SDI BOOT.SDI
initrd http://10.0.0.55/wim/wim/Win10PESE_x64.WIM BOOT.WIM
boot

 

BCD is being read, as I can chose the correct Windows Boot Manager by Enter at error screen (which then fails again)

 

 

There really is nothing to my setup

[erwan.l]

Remove the wim folder.

You should have from the root pxe folder:
Boot
Efi/Microsoft/boot
Sources

And use my ipxe script as is.
Only update the ip, nothing else.

Use my bcd as well.

[misty]

@sebus
In uefi mode, wimboot does not appear to tolerate files with different than expected being mapped. It is expecting boot.wim and the original file being mapped as boot.wim must also be named boot.wim.

E.g.

initrd http://10.0.0.55/wim/wim/Win10PESE_x64.WIM BOOT.WIM

.
Will not work. However...

initrd http://10.0.0.55/wim/wim/Win10PESE_x64/BOOT.WIM BOOT.WIM

.
....should work fine.

Give it a go and feedback.

Regards,

Misty

EDIT - this needs further experimentation. My own UEFI system appears to have poorly implemented UEFI - e.g. no firmware support for network boot unless CSM is enabled.

I can't remember whether a wim file not using the default/standard boot.wim naming convention worked at all - even when the BCD store specified the different name. Hope this makes sense.

[sebus]

Remove the wim folder.

You should have from the root pxe folder:
Boot
Efi/Microsoft/boot
Sources

And use my ipxe script as is.
Only update the ip, nothing else.

Use my bcd as well.

 

No, the layout makes no difference, that is not the issue!

[sebus]

@sebus
In uefi mode, wimboot does not appear to tolerate files with different than expected being mapped.

 

Absolutely SPOT on, thanks. I could not find this info anywhere else!

Of course I can have only a single file with a name in folder, but there can be many subfolders & it does indeed work fine

 

 

EDIT - this needs further experimentation. My own UEFI system appears to have poorly implemented UEFI - e.g. no firmware support for network boot unless CSM is enabled.

I can't remember whether a wim file not using the default/standard boot.wim naming convention worked at all - even when the BCD store specified the different name. Hope this makes sense.

 

 

It works fine with no CSM enabled

 

I will test with different names in BCD & report back

 

Many thanks again (it was so simple after all!)

[erwan.l]

Can you summarize what was your issue and detail your corrective actions ?

 

If your ipxe script was the issue, following my advice in post #27, should have done the trick.

And use my ipxe script as is.
Only update the ip, nothing else.

[sebus]

In uefi mode, wimboot does not appear to tolerate files with different than expected being mapped.

 

All that is, the .wim filename must be boot.wim (if that what is referenced in BCD)

It does NOT matter where it gets downloaded from (it does NOT have to be from sources folder)

[ndog37]

Could you please trying using create_bcd_reg.cmd by NiKiZe to generate your bcd files? I can't believe cdob didn't come up with this.

 

https://github.com/N...ate_bcd_reg.cmd

 

Also if you want to move boot.wim you can just nest it under a different folder name, eg wim/wds/boot.wim or wim/fixwinpe/boot.wim

 

Thanks

Edited by ndog37, 19 February 2017 - 11:56 AM.

[erwan.l]

Could you please trying using create_bcd_reg.cmd by NiKiZe to generate your bcd files? I can't believe cdob didn't come up with this.

 

https://github.com/N...ate_bcd_reg.cmd

 

Also if you want to move boot.wim you can just nest it under a different folder name, eg wim/wds/boot.wim or wim/fixwinpe/boot.wim

 

Thanks

 

What does this batch which you cannot do with bcdedit?

Also, I miss the nointegritychecks option in the bcd you point to. 

 

Why not simply use the bcd which comes with winpe or window dvd/iso ?

[misty]

See here and a basic BCD store here and script used to create the BCD store here

Misty

P.s. erwan is correct - using the BCD store from WinPE or Windows DVD/ISO sources will also work fine.

P.p.s. My store is also missing the nointegritychecks option - it was still working fine in the VMs I used for testing.

[erwan.l]

nointegritychecks=yes is for UEFI booting

[misty]

nointegritychecks=yes is for UEFI booting[/size]

Will retest later (I'm currently on a tea break from decorating!), however I'm sure I tested the BCD without nointegritychecks in VMWare Player using a VM in UEFI mode.

Misty

[erwan.l]

Will retest later (I'm currently on a tea break from decorating!), however I'm sure I tested the BCD without nointegritychecks in VMWare Player using a VM in UEFI mode.

Misty

 

Enjoy your tea break : UK tea is best !

 

About nointegritychecks, see original discussion here.

 

My experience in UEFI world :

-with secureboot enabled, no way to boot any other bootloader than a signed one (and we dont have a signed IPXE)

-without secureboot enabled, you can boot an unsigned bootloader (IPXE) only if nointegritychecks=yes or else you get "error code 0xc0000428 (The digital signature for this file couldn’t be verified).".

 

Note from here, that parameter only applies to win10 and up:

nointegritychecks [ on | off ]

Disables integrity checks. Cannot be set when secure boot is enabled. This value is ignored by Windows 7 and Windows 8.

[StanislavKogan]

The solution in my case was to add the --name option to the initrd command - boot.wim definitely requires this set when using UEFI boot.

[Wonko the Sane]

The solution in my case was to add the --name option to the initrd command - boot.wim definitely requires this set when using UEFI boot.

Can you post the COMPLETE entry that is working?

 

Wonko

[erwan.l]

About winboot and UEFI, a must have reading : http://mistyprojects...npe_wimboot.htm .

 

And specially the virtual names part.

A typical example for loading a file on Clients with BIOS Firmware uses the following syntax -

initrd [path]   [virtual_name]
The syntax for Clients with UEFI Firmware is slightly different, either one of the examples below can be used -

initrd --name [virtual_name]   [path]
initrd -n [virtual_name]   [path]

Although the solution provided by Misty in post 28 (and confirmed by Sebus) does not use --name.

The original issue (see post 26) was about using a renamed boot.wim files.

[Wonko the Sane]

Yep , but as often happens. the given explanation is a non-explanation, you need to go through all the given page:
http://mistyprojects...npe_wimboot.htm
to understand the matter.
 
And - with all due respect for Misty and his nice work - using the "virtual_name" of bootx64.efi for a "real_name" hxxp://*whatever*/bootx64.efi or hxxp://*whatever*/BOOTX64-EFI makes of course NO SENSE WHATSOEVER, AFAICT, using:
initrd --name bootx64.efi hxxp://192.168.1.1/bootx64.efi
vs.
initrd  hxxp://192.168.1.1/bootx64.efi
 
makes no difference whatsoever.
 
It is only when the name of the served file differs from the "expected" name that the -n or --name option is useful.
 
If I may , suggested additions (FAQs/FGAs):
 
 
What does "virtual_name" mean?
It means the filename used in the virtual filesystem that wimboot creates.
 
Then what is the "real_name"?
It means the actual filename (and path, if not the same of where the ipxe script is)  of the actual file on the server.
 
Where are the "virtual_names" files available (in the served "virtual" filesystem)?
In several places (ALL files will be available in ALL the following "virtual" paths):
 
\
\Boot
\Boot\Fonts
\Boot\Resources
\Sources
\EFI
\EFI\Boot
\EFI\Microsoft
\EFI\Microsoft\Boot
 
What are allowed (and accepted) "virtual_names"?
The "standard" boot files, namely:
 
bootmgr.exe
bootx64.efi
bcd
boot.sdi
boot.wim
 
plus the sometimes needed font files, such as (example):
wgl4_boot.ttf
 
This is an actual meaningful example (for UEFI):
#!ipxe
kernel hxxp://192.168.1.1/wimboot
pause
initrd --name bootx64.efi hxxp://192.168.1.1/my_differently_named_bootx64.efi
initrd --name bcd hxxp://192.168.1.1/somewhere_else/BCD_by_another_name
initrd --name boot.sdi hxxp://192.168.1.1/BOOT/a_suffusion_of_yellow
initrd --name boot.wim hxxp://192.168.1.1/BOOT/a_stupidly_renamed_boot_wim

 

Wonko

[erwan.l]

Too bad the forum formatting halfly killed your demonstration (hence the "code" markup    ) but indeed you are right : the --name should only be used if you intend to use a real (file) name which is different from what is actually expected by the loader.

 

So to extend Misty's answer (and correct me if wrong)

initrd http://10.0.0.55/wim/wim/Win10PESE_x64.WIM BOOT.WIM.

will not work ... but

initrd http://10.0.0.55/wim/wim/Win10PESE_x64/BOOT.WIM BOOT.WIM

will work ... and 

initrd --name boot.wim http://10.0.0.55/wim/wim/Win10PESE_x64/Win10PESE_X64.WIM

will also work.

 

The latter solution being convenient as you dont have you actually rename your files thanks to "virtual names".

 

Also worth mentionning some wimboot documenation : here.

[Wonko the Sane]

Too bad the forum formatting halfly killed your demonstration (hence the "code" markup    ) but indeed you are right : the --name should only be used if you intend to use a real (file) name which is different from what is actually expected by the loader.
 
So to extend Misty's answer (and correct me if wrong)

 
Hopefully "fixed" using hxxp .
 
Your "extended" answer is more limited than Misty's explanation (on the given page).
Unless something has changed (hopefully) recently, the -n or --name option only works for UEFI, so you need to repeat the "right" "vitual_name" after, i.e.:

initrd --name boot.wim http://10.0.0.55/wim/wim/Win10PESE_x64/Win10PESE_X64.WIM boot.wim

is the only way to have it working BOTH for UEFI and BIOS (in case of a "changed name"), this:

initrd http://10.0.0.55/wim/wim/Win10PESE_x64/BOOT.WIM BOOT.WIM

will work fine in both UEFI and BIOS because "virtual_name" and "real_name" are the same.
 

Wonko

[StanislavKogan]

The following works for me

#!ipxe

kernel --timeout 60000 wimboot-2.6.0
imgfetch --name BCD --timeout 60000 bcd				BCD
imgfetch --name boot.sdi --timeout 60000 boot.sdi		boot.sdi
imgfetch --name boot.wim --timeout 60000 winre-20180614.wim	boot.wim

The following doesn't

#!ipxe

kernel --timeout 60000 wimboot-2.6.0
imgfetch --name BCD --timeout 60000 bcd			BCD
imgfetch --name boot.sdi --timeout 60000 boot.sdi	boot.sdi
imgfetch --timeout 60000 winre-20180614.wim	boot.wim

The problem happens only in UEFI mode - somehow the boot.wim absolutely requires the --name setting.

[Wonko the Sane]

 

The problem happens only in UEFI mode - somehow the boot.wim absolutely requires the --name setting.

 

This is right back to the possible misunderstanding (what I was trying to disambiguate), the -n or --name setting is NOT needed for the "boot.wim", it is needed for the "winre-20180614.wim" which is a RENAMED "boot.wim" (and this happens only on UEFI).

 

If your "boot.wim" is renamed to anything else BUT "boot.wim", then the --name boot.wim or -n boot.wim is needed, otherwise it is not.

 

Since both the BCD and the boot.sdi are still called BCD and boot.sdi (respectively) the -n or --name option should not be needed for those two files (having them won't do any harm, however ).

 

Wonko

[misty]

This is right back to the possible misunderstanding (what I was trying to disambiguate), the -n or --name setting is NOT needed for the "boot.wim", it is needed for the "winre-20180614.wim" which is a RENAMED "boot.wim" (and this happens only on UEFI).
 
If your "boot.wim" is renamed to anything else BUT "boot.wim", then the --name boot.wim or -n boot.wim is needed, otherwise it is not.
 
Since both the BCD and the boot.sdi are still called BCD and boot.sdi (respectively) the -n or --name option should not be needed for those two files (having them won't do any harm, however ).
 

Wonko

I would need to retest to confirm, however I vaguely recall that the --n (or --name) option was required even when boot.wim was not renamed.

I'm not in a position to retest at the moment.

And there may have been a number of variables at play including my access to a very limited range of hardware with UEFI firmware. And an older version of wimboot (circa early 2017).

Misty

[Wonko the Sane]

I would need to retest to confirm, however I vaguely recall that the --n (or --name) option was required even when boot.wim was not renamed.

I'm not in a position to retest at the moment.

And there may have been a number of variables at play including my access to a very limited range of hardware with UEFI firmware. And an older version of wimboot (circa early 2017).

Misty

Well, , using the "original" as "real_name" is the actual solution you suggested and that Sebus confirmed to be working, (post #28, #30 and #32).

 

In other words BOTH these apporaches:

initrd --name boot.wim http://10.0.0.55/wim/wim/Win10PESE_x64/Win10PESE_X64.WIM boot.wim

initrd http://10.0.0.55/wim/wim/Win10PESE_x64/BOOT.WIM BOOT.WIM

should work BOTH in BIOS and UEFI, the first one tested and confirmed by StanislavKogan, the second tested and confirmed by Sebus.

 

BTW in the meantime it is also possible that wimboot itself has been changed, at face value it is "queer" that there are two different sintaxes/parsing methods for BIOS and UEFI booting.

 

Or maybe they didn't care/notice. 

 

Wonko

[steve6375]

Just to add...

 

When UEFI booting, it seems to need a BCD file passed to it using initrd (unlike Legacy booting).

Also the BCD MUST be configured with the 'standard' path to the wim file of \sources\boot.wim  regardless of where the  wim file actually is. Beware as some dual-boot (32+64-bit) ISOs will not use these paths in the BCD, so check the BCD that you use! Some other paths also seem to work too such as \boot.wim.

 

The same is true for boot.sdi - it must be in the grub menu and the path in the BCD must be \sources\boot.sdi

 

Otherwise BSOD error 0xc000000f !

 

This works...

#!ipxe
#use --name for UEFI when file has different name from default
#add second virtual name for MBR booting
#ensure BCD has standard \sources\boot.wim and \boot\boot.sdi paths

ifopen
kernel file:/wimboot
initrd --name bcd file:/win/bcd2 bcd
initrd --name boot.sdi file:/win/boot.sdi boot.sdi
initrd --name boot.wim file:/win/boot64.wim boot.wim
echo Platform=${platform} BuildArch=${buildarch}
imgstat
prompt --timeout 5000 Press a key... ||
boot

Attached Thumbnails

• 

Edited by steve6375, 28 June 2019 - 12:43 PM.