Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/01/16 a las 12:57, Thomas Schmitt escribió:
adrian15 wrote:
Do you mean if you have:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
you could just re-arrange them as:
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
and it would be fine?
From the view of xorriso and El Torito specs this is ok.
You have to keep the modifier options (e.g. -boot-info-table) in
the same -eltorito-alt-boot department as their main options (e.g. -b).
The program isohybrid of SYSLINUX expects BIOS in El Torito catalog
entry 1, EFI in entry 2, and HFS+ in entry 3.
So with genisoimage + isohybrid, you'd have to keep the sequence.
One never knows what firmware does with such changes. Normally
it should accept any sequence. But tradition is: BIOS first, EFI second.
I see. So when using syslinux it's better for it to be the primary
bootloader. Ok.
And, if I'm not mistaken doing a:
--bootloaders="grub-efi" should be quite easy.
That way people that want EFI only images would be able to make them. In
order to do that I would just need to implement the primary bootloader
behaviour of grub-efi and, well, remove the current grub-efi as a
secondary bootloader role enforcement.
I might finally do that.
I wonder what EFI firmware would hop on an MBR partition of type 0x01.
An EFI System Partition in MBR should have type 0xef to be recognized.
That needs to be asked to Hertzog. I just tried to use his original work.
Did you try whether it boots via EFI if no BIOS boot equipment
is in the ISO ?
Well, I tried: kvm -bios /usr/share/ovmf/OVMF.fd -boot d -cdrom file.iso .
I probably need to do more tests later.
If I'm not mistaken Hertzog removed that option because you suggested to
remove it on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66
Are you requesting to put this option back ?
Only if you augment the boot equipment by a third boot image that
contains a small HFS+ filesystem. (See Fedora Live CD.)
As long as there is no HFS+, the option -isohybrid-apm-hfsplus
is inappropriate but seems to do no harm. (See Debian amd64 netinst.)
I see. So the Fedora Live CD would seem even better. I wonder why the
debian-cd team did not consider adding this third boot image with a
small HFS+ filesystem. I'll probably ask them in the irc.
There are two ways known to me how to get a boot path via HFS+:
The debian-cd method is one of them? Or is it not?
debian-cd has no HFS+ boot image. This makes it different from
Fedora Live CD.
Understood.
The xorriso run could be easily adapted to include a HFS+ image.
But i do not know how Matthew Garrett produced this image.
I was doing some research on SElinux support and I found these set of
tools for creating the Fedora Live CDs:
https://github.com/rhinstaller/livecd-tools
It's quite nice learning how other build their own live cd systems.
Anyways, back to the main subject, I have no idea if Matthew Garrett
used this tool or not.
One would have to investigate its content and find some Mac
filesystem tool to produce such content.
Probably.
The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso
options are: [well known from file /.disk/mkisofs in the ISO]
where you can see they use:
-isohybrid-apm-hfsplus
So... this is not useful for creating an HFS+ image file?
No. It just announces the EFI boot image in an Apple Partition Map.
This might be of use for GRUB2 if no other partition table points
to that image. But debian-cd has an MBR partition 0xef and a GPT
partition which point to that EFI boot image. (The GPT is to be
ignored by all sane EFI implementations.)
Ok. Did you mean "NOT to be ignored"?
What does this option do instead then?
It is surplus, currently.
Maybe I'm just repeating
what you are going to saying later in this email about how Grub2 handles
boot in Mac systems.
Regreattably i can only forward the rumor that Some (TM) Macs
do not boot without HFS+ and its blessed files.
They are in the time window between Apple Inc. giving up PowerPC
and Apple Inc. adopting EFI.
I have one of them in that window. I'm not sure about the blessing being
needed though. Maybe I have disabled it. Not sure.
A) Are you complaining about syslinux-efi on:
-append_partition 2 0x01
that should be:
-append_partition 2 0xef
instead?
Yes. UEFI 2.4 5.2.2 says about booting from MBR partitions:
"* 0xEF (i.e., UEFI System Partition) defines a UEFI system partition."
The presence of GPT would have to be announced by a "protective MBR"
partition of type 0xee with start at LBA 1. Any MBR partition type other
than 0x00 and 0xee prevents the recognition of GPT.
Maybe that's why the syslinux-efi does not boot. I could give it a try
changing the partition type and see what happens.
grub-mkrescue -o output.iso minimal_dir
Last time I checked it did not work ok in Debian because the commit
the grub package was based was too old.
I recently tested on my Sid VM with various combinations of grub-pc,
grub-efi-ia32-bin, and grub-efi-amd64-bin. All together, pair-wise, alone.
They all booted with qemu via its default BIOS and via OVMF (as EFI).
Did you try to boot them either as a cdrom or as a hard disk? I think
that EFI + hard disk was the one failed for me. Anyways it's high
probable that the Sid package has been updated and, if I tried right
know, it would work for me.
4.2. Debian GNU/GRUB Version 2 package version commit was behind
what Super Grub2 Disk needed for it to work on a Mac-Intel system
(The three partition types in a single iso hack if you know what I mean).
grub-mkrescue produces a different layout than debian-cd or
Fedora Live CD.
It is less convenient for mounting the ISO because none of
the partitions points to its start.
Yeah, I received some complaints about people not being able to reuse
their usb sticks after dd'ing Super Grub2 Disk (based on grub-mkrescue
you describe) into their usb sticks.
It is more UEFI compliant than debian-cd, because it avoids
overlapping of partitions.
That's interesting. So we have Fedora, debian-cd, grub-mkimage ways of
dealing with UEFI. Probably Ubuntu has also its own way of handling it too.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Reply to: