#832687 - support uefi - Debian Bug report logs

Debian Bug report logs - #832687
support uefi

Reported by: Raphaël Hertzog <[email protected]>

Date: Mon, 18 Nov 2013 09:33:02 UTC

Severity: wishlist

Subject: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Reply-To: "Thomas Schmitt" <[email protected]>, [email protected]
Resent-From: "Thomas Schmitt" <[email protected]>
Resent-To: [email protected]
Resent-CC: Debian QA Group <[email protected]>
Resent-Date: Thu, 21 Jan 2016 12:00:01 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
Date: Thu, 21 Jan 2016 12:57:23 +0100
From: "Thomas Schmitt" <[email protected]>
To: [email protected]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
References: <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>

Hi, i wrote: > http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt adrian15 wrote: > I want to document the different ways of how BIOS boot, UEFI boot and > Secure Boot work and that might be helpful. Secure Boot is not covered. (I am not sure whether it belongs there. Actually i don't know enough about it.) 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 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 ? Raphaël ? Can you shed light on this ? Does the 0x01 partition stem from the "Firmware Partition" of mini.iso ? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317 reports about quite unintentional boot success via that partition.) > > (Does "syslinux-efi" mean that you can boot from ISO via EFI > > and SYSLINUX stuff to an operating system ? That would be new.) > I don't know what you mean by 'SYLINUX stuff to an operating system. Afaik, SYSLINUX begins to boot from an EFI System Partition inside or after the ISO filesystem. It does not get to booting the operating system files in the ISO filesystem, though. > The EFI image needs to include the configuration file Given the reports on [email protected] i'd expect that enough of operating system has to reside in the FAT filesystem so it is able to boot to the capability to find and read the ISO filesystem. But in practice, all EFI bootable ISOs known to me use GRUB for the job. (One may boot a kernel directly from EFI, without intermediate boot loader. Examples are rare but seem to work.) > 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.) > > 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. The xorriso run could be easily adapted to include a HFS+ image. But i do not know how Matthew Garrett produced this image. One would have to investigate its content and find some Mac filesystem tool to produce such content. > 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.) > 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. > > (Options picked out of proposal of > > xorriso -hfsplus on \ > > -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \ > > -report_el_torito as_mkisofs > Interesting. I did not know that you could request what an ISO > 'layout/configuration' was. This is a xorriso feature which is present in the Sid package xorriso-1.4.2 but not in xorriso-1.3.2 as of Debian 8. You can request a listing of the boot equipment xorriso -hfsplus on -indev ...iso \ -report_el_torito plain -report_system_area plain and you can request option proposals by above -report_el_torito as_mkisofs > 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. > B) You are saying good things about -isohybrid-apm-hfsplus because it avoids normal EFI firmware to read it? So that only Mac systems can read it? This option makes sense mainly/only if a HFS+ boot image is present. > > 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). > https://lists.debian.org/debian-efi/2016/01/msg00013.html > 4.1. Debian packages do not provide a way of building an hybrid > (both valid in i386-pc and efi machines) iso. This should work with the Sid packages of GRUB2. > 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. It is more UEFI compliant than debian-cd, because it avoids overlapping of partitions. > Do you know if that Serbinenko contribution needs a minimal xorriso version? It is in xorriso since version 1.2.4. I.e. Debian 8 Jessie should suffice. Else get a GNU xorriso tarball. Current release is http://ftpmirror.gnu.org/xorriso/xorriso-1.4.2.tar.gz Have a nice day :) Thomas

Debian bug tracking system administrator <[email protected]>. Last modified: Tue May 13 08:51:55 2025; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #832687 support uefi

Debian Bug report logs - #832687
support uefi