Support extraction of El Torito HD image content #63

Open
pbatard opened this Issue Mar 1, 2012 · 2 comments

Comments

Projects
None yet
2 participants
@pbatard
Owner

pbatard commented Mar 1, 2012

Such as the one from DOSUSB ISO, as well a regular DOS ISO data.
Basically, this would copy what are expected to be DOS files to a DOS bootable USB.
We may also want to handle pure image executables such as the ones used on Memtest86+ ISOs, through Syslinux's image load or something...

@ghost ghost assigned pbatard Mar 1, 2012

@pbatard pbatard changed the title from ER: support extraction of El Torito HD image content to ER: Support extraction of El Torito HD image content Apr 25, 2014

@pbatard pbatard changed the title from ER: Support extraction of El Torito HD image content to Support extraction of El Torito HD image content May 8, 2015

@saivert

This comment has been minimized.

Show comment
Hide comment
@saivert

saivert Oct 7, 2017

Rufus also presently does not extract all contents from EFI.img (El-Torito) to the resulting USB flash drive which means bootloaders like Systemd-boot (formerly gummiboot) wont work as the loader entries are missing. When UEFI booting in HDD mode the EFI.img isn't used at all and there is no way the bootloader would be aware of it. Essentially these .ISO images have to be written in DD mode (ISOHybrid) as that is the only way they are going to work.

saivert commented Oct 7, 2017

Rufus also presently does not extract all contents from EFI.img (El-Torito) to the resulting USB flash drive which means bootloaders like Systemd-boot (formerly gummiboot) wont work as the loader entries are missing. When UEFI booting in HDD mode the EFI.img isn't used at all and there is no way the bootloader would be aware of it. Essentially these .ISO images have to be written in DD mode (ISOHybrid) as that is the only way they are going to work.

@pbatard

This comment has been minimized.

Show comment
Hide comment
@pbatard

pbatard Oct 7, 2017

Owner

The current handling of efi.img is a workaround for Debian Live, so it only applies to these specific ISOs (which only need the UEFI bootloader extracted to work). I strongly suggest that other distros should try to follow the Debian example and avoid shoving more than the bootloader into the .img, because it creates problems downstream for users who prefer writing their USB media in a manner in which the content will be fully accessible from Windows.

Still, if you can provide the URL of an ISO that highlights the issue you are describing, I'll see what I can do...

Owner

pbatard commented Oct 7, 2017

The current handling of efi.img is a workaround for Debian Live, so it only applies to these specific ISOs (which only need the UEFI bootloader extracted to work). I strongly suggest that other distros should try to follow the Debian example and avoid shoving more than the bootloader into the .img, because it creates problems downstream for users who prefer writing their USB media in a manner in which the content will be fully accessible from Windows.

Still, if you can provide the URL of an ISO that highlights the issue you are describing, I'll see what I can do...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment