Post Reply 
 
Thread Rating:
  • 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
manually wrap wimboot cpio
2016-12-17, 07:56 (This post was last modified: 2016-12-17 08:14 by ndog.)
Post: #1
manually wrap wimboot cpio
Hi from this forum http://forum.ipxe.org/showthread.php?tid...56#pid9656

It seemed it was possible to create cpio archive for testing with wimboot

echo bootmgr BCD boot.sdi boot.wim | fmt -1 | cpio -H newc -v -o > ../wimfiles.cpio

#!ipxe
kernel wimboot
initrd wimfiles.cpio
boot

I have created cpio archive like this and added ipxe entry, however I am getting FATAL: no BOOTX64.EFI or bootmgfw.efi found etc, in ipxe.efi with menu.ipxe

:cpiotest
kernel ${boot-url}winpe/wimboot
initrd ${boot-url}winpe/cpiotest/wimfiles.cpio
boot || goto failed
goto start


I am booting normally from ipxe with the following, however for testing I would like to be able to prewrap the cpio for testing with other various EFI boot loaders which don't parse command lines so well.

:efiprep
kernel ${boot-url}winpe/wimboot
initrd ${boot-url}winpe/bootmgr bootmgr
initrd ${boot-url}winpe/BCD BCD
initrd ${boot-url}winpe/boot.sdi boot.sdi
initrd ${boot-url}winpe/EFI-diskprep/boot.wim boot.wim
boot || goto failed
goto start
Find all posts by this user
Quote this message in a reply
2016-12-17, 10:40
Post: #2
RE: manually wrap wimboot cpio
In legacy mode the way wimboot loads filename and file data is via cpio headers in in memory (there is no specification for how to transfer file information in legacy pcbios mode)

However in efi mode, the EFIFS (which is specified in the EFI spec) is used instead and not cpio.
you will not be able to use the "cpio hack" when booting in efi mode.

The reason cpio works with wimboot in legacy is just a side effect of the implementation rather then a intended feature.

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-12-18, 02:12 (This post was last modified: 2016-12-18 02:16 by ndog.)
Post: #3
RE: manually wrap wimboot cpio
(2016-12-17 10:40)NiKiZe Wrote:  you will not be able to use the "cpio hack" when booting in efi mode.

The reason cpio works with wimboot in legacy is just a side effect of the implementation rather then a intended feature.

Thanks for the explanation!
I guess the next question is, is there is any other hack or way of wrapping the files into one initrdfile for testing from ipxe.efi + wimboot?
Initially I want to test with rEFInd and grub2 from hdd boot (would be great to see wim file booting on a mac or EFI pc), which are both capable of loading wimboot as a kernel from efi, but cant parse the command line well, and various other boot loaders including network EFI+PXE support
Find all posts by this user
Quote this message in a reply
2016-12-18, 09:58
Post: #4
RE: manually wrap wimboot cpio
no there is no "wrappiing" in efi mode for wimboot

What exactly is the issue with loading wimboot as it is intended to be used? what is wrong with using ipxe? and what is the exact issue you get when using something else?

having wimboot with multiple initrds in efi mode should be supported

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-12-18, 12:02
Post: #5
RE: manually wrap wimboot cpio
(2016-12-18 09:58)NiKiZe Wrote:  What exactly is the issue with loading wimboot as it is intended to be used? what is wrong with using ipxe? and what is the exact issue you get when using something else?

Just experimenting. On a laptop I own I can boot many things from grub4dos but what i like are
- graphical interface
- option to remember last boot option
- hide/unhide partitions (so other OS can't r/w)
- chainload other bootloader (eg clover + osx)
- boot vmlinuz + initrd + options (eg clonezilla live)
- boot flatfile 'vhd' for windows xp/7 etc
- boot windows PE using wimboot

On a pure UEFI laptop eg HP EFI only laptop (and later testing with a macbook) I could install ipxe.efi as the main bootloader, however I am uncertain as if ipxe.efi from a hard disk EFI partition would be able to
-remember last booted entry
-chainload another efi such as clover etc
So far ipxe does everything i want from pxe booting, but this is just for a local boot loader for dual booting windows, osx, linux and recovery tools like clonezilla, gparted and diagnostics eg wimboot some winPE with preloaded tools, a technicians laptop if you like.

Nowdays I am looking at using rEFInd as a bootloader. It has cool themes and icons too. But I can't get clonezilla or wimboot to work from it, because of the way the options eg this
loader /wimboot/wimboot
options "initrdfile=/wimboot/bootmgr,/wimboot/BCD,/wimboot/boot.sdi,/wimboot/boot.wim"

would pass as
Starting wimboot
Using load options 'initrdfile=/wimboot/bootmgr,/wimboot/BCD,/wimboot/boot.sdi,/wimboot/boot.wim'

wimboot v.2.5.2 -- Windows Imaging Format bootloader -- http://ipxe.org/wimboot

Command line: "\wimboot\wimboot initrdfile=/wimboot/bootmgr,/wimboot/BCD,/wimboot/boot.sdi,/wimboot/boot.wim"
Using EFI via 0xb6251d20 len 0x1000
Using wimboot via 0xb3d37020 len 0x1000
FATAL: no BOOTX64.EFI or bootmgfw.efi found
Error: Load Error returned from wimboot

If it were just the kernel and just a initrd file it would eliminate the argument passing. I have tried many different options to make wimboot try to read, however lack of documentation and/or anyone else daring to boot a windows PE file from refind boot loader has prevented this stage Big Grin

https://sourceforge.net/p/refind/discuss.../962d4dbe/

Maybe i will chainload ipxe from refind and go that way, further testing required! Eventually I will get something that works I'm sure!

My dream scenario as a technician would be like this
legacy pxe boot, using pxelinux.0
efi pxe boot, using ipxe.efi
legacy boot from HDD, using grub4dos mbr hd0
EFI boot from HDD (PC), using grub2.efi
EFI boot from Mac, using rEFInd.efi

And all these loaders would support wimboot and have documented ways of doing this. So far (in my testing) only pxelinux.0, ipxe (legacy and efi) and grub4dos support wimboot.
Find all posts by this user
Quote this message in a reply
2016-12-18, 12:21
Post: #6
RE: manually wrap wimboot cpio
rEFInd is simply broken if you can't send load files into efifs without putting the files on executables cmdline.

just specify multiple initrds instead.

but since you are loading from disk then use the traditional bootmgr instead - no need at all to use wimboot.

ipxe is not a bootloader for hdd, it is a loader for pxe or network boot.

why would you use pxelinux for legacy and ipxe.efi for efi? why not use ipxe for both?

and for hdd boot use grub, why complicate with grub4dos?

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-12-19, 12:20
Post: #7
RE: manually wrap wimboot cpio
Thats too bad. I would prefer to use wimboot, as then I don't need to boot into a windows environment to modify BCD entries, which might be a bit more complicated to do on a mac for instance, and I like the idea of being able to simply add a boot entry in the boot loader, being able to boot multiple wimfiles independent of an ugly BCD menu. That being said refind probably does work with wimboot, I just don't know the correct syntax and proper formatting of the argument to pass. Lack of documentation about this doesn't help but will test further.
As for grubd4dos/pxelinux.0, it is more a personal preference, the embedded password and graphics modes more than anything. Apparently syslinux supports http transfers now, but yet to test.
Find all posts by this user
Quote this message in a reply
2016-12-19, 18:37
Post: #8
RE: manually wrap wimboot cpio
there is several reg editors available that can run on *nix so creating BCD files isn't that hard.
For a example of how to create a BCD file without using bcdedit on windows see this (basic) example: https://github.com/NiKiZe/wimboot-bcd/bl...cd_reg.cmd

ipxe has graphics as well (if we are talking background image) there is also password entry and lots more. and it has a scripting language which makes it possible to do almost anything in regards of dynamic menues etc.

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
2017-01-07, 11:49
Post: #9
RE: manually wrap wimboot cpio
Thanks for your BCD script, and I am amazed that a BCD appears to be nothing more than a registry hive! Microsoft certainly like to store settings in various ways such as boot.ini to sysprep.xml to BCD being a registry hive.
I am currently testing still with grub2/rEFInd efi and wimboot, I have found chainloading wimboot loads it under grub2, but then passing a command line is the next step to determine (same problem with rEFInd), but if the BCD entry works then I will go down that path.
Find all posts by this user
Quote this message in a reply
2018-06-04, 07:52
Post: #10
RE: manually wrap wimboot cpio
Hello,
any progress?
Find all posts by this user
Quote this message in a reply
2018-06-04, 18:55
Post: #11
RE: manually wrap wimboot cpio
(2018-06-04 07:52)jamefane Wrote:  any progress?

CPIO is unlikely to be added as a valid container for wimboot in EFI mode.

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)