Debian Bug report logs - #832687
support uefi

Full log

🔗 View this message in rfc822 format

X-Loop: [email protected]
Subject: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Reply-To: Michal Suchanek <[email protected]>, [email protected]
Resent-From: Michal Suchanek <[email protected]>
Resent-To: [email protected]
Resent-CC: Debian QA Group <[email protected]>
X-Loop: [email protected]
Resent-Date: Sun, 24 Jan 2016 15:54:11 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
X-Debian-PR-Message: followup 731709
X-Debian-PR-Package: live-build
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: live-build
Received: via spool by [email protected] id=B731709.145365075323848
          (code B ref 731709); Sun, 24 Jan 2016 15:54:11 +0000
Received: (at 731709) by bugs.debian.org; 24 Jan 2016 15:52:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02
	(2014-02-07) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 required=4.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FOURLA,FREEMAIL_FROM,HAS_BUG_NUMBER,
	MONOTONE_WORDS_2_15,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham
	autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 28; hammy, 150; neutral, 339; spammy,
	0. spammytokens: hammytokens:0.000-+--HX-Google-DKIM-Signature:in-reply-to,
	0.000-+--HX-Google-DKIM-Signature:references, 0.000-+--livebuild,
	0.000-+--live-build, 0.000-+--amd64
Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231])
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84)
	(envelope-from <[email protected]>)
	id 1aNMxs-0006CK-Ow
	for [email protected]; Sun, 24 Jan 2016 15:52:32 +0000
Received: by mail-wm0-x231.google.com with SMTP id 123so38319442wmz.0
        for <[email protected]>; Sun, 24 Jan 2016 07:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        bh=R5jyJZeFzRFM9KBwYlcMGWkFFhNtDt6J3ZX/wpibUZE=;
        b=YK8Ozko3Txuzy+APCU8RSszeWJXCxXLd3gjoZ46waj6MzUURHJtRJyB/GgeBdgtwjm
         X200TTHd5tIKUbGVoGsXxclrTeNBtzayE+qa9SJfEldtPozMfFU3PEXsluf0EXosP1/I
         ZRxrYn3LF2SorgpWMPJfmJxHRCX1j/XG1pO1xQyocJHyrErHcYMwPCQNOzfbH3JLE6cN
         /SOmHHS78BWPYOk0IeQjYJW4chL/FeQAGJr6ieFP4MJv+2C3HYDL1a1fswCSEkZkE1tF
         7yxuF7fTATkwYnL/v5ntObqhOZHB/ac3CAO0DvRA39qNtL0jJDrYTg+wEX3QkZd1we9H
         zHVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc:content-type:content-transfer-encoding;
        bh=R5jyJZeFzRFM9KBwYlcMGWkFFhNtDt6J3ZX/wpibUZE=;
        b=a9XZbGyg33BaWba0ppRPkDbHNqpfdcVUEy03VnODq79be2UE6UWyKFcetT+rZGfR8e
         bg1gW2z36QQGnNZrFByuiueGmpkck7fL2K57JsaCOsB4tIh0lODWqMJWU8IkE926jhOw
         KYNX70wQAhFadPD0SDmVmINU8zl4OOMhDWrQ70K2BurM/bijhl5nc00gkJACNTgDHilh
         tznSx98vIwh07U27H1fHQajDXthjuYFfYuXlPFW2uuhyYkUh7d9nBA5mxcabr+0dn1QR
         e/fGCIYY+HeRLBFNBtcEpKXqI5NQJ1u8xKbgkUR9YZ5Zee3apPAR/zhrAHtpfA2FWRWW
         xuOA==
X-Gm-Message-State: AG10YOSsO99i8uUQ5MMkuka2vmc/uA74cts5G6oqUqh95IZhrax0FgBa2QB4zns3k210kXCKWFmipwBzILGiQg==
X-Received: by 10.194.105.99 with SMTP id gl3mr12518327wjb.90.1453650746012;
 Sun, 24 Jan 2016 07:52:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.20.36 with HTTP; Sun, 24 Jan 2016 07:51:46 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
 <[email protected]>
From: Michal Suchanek <[email protected]>
Date: Sun, 24 Jan 2016 16:51:46 +0100
Message-ID: <CAOMqctSbV_3SKbQ--cvAoFxwhHQckhhELmGpMW5_xkxAEY2W+Q@mail.gmail.com>
To: adrian15 <[email protected]>
Cc: Thomas Schmitt <[email protected]>, [email protected], 
	Raphaël Hertzog <[email protected]>, 
	jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 January 2016 at 00:41, adrian15 <[email protected]> wrote:
> El 23/01/16 a las 09:21, Thomas Schmitt escribió:
>>
>> There is a fourth dimension to be expressed: Bootloader.
>> Then there is the dimension of ISO filesystem objects.
>> A user wish would contain at least
>>    ISO-Object, Bootloader, Medium, Firmware, Architecture
>>
>> E.g.
>>
>>    Appended Partition, with GRUB2 content, for CDROM and HDD, via EFI, on
>> i386
>>
>>    ISO Data File, with SYSLINUX content, for HDD, via BIOS, on i386 and
>> amd64
>>
>> I am not sure whether this list of more or less combinable
>> dimensions is complete yet.
>>
>> Further one will want to express whether the gaps between partitions
>> should be filled, which kinds of partition tables shall emerge, ...
>> These properties are global to the ISO, not specific to a single
>> boot image. Some are combinable, some are mutally exclusive.
>>
>> (Maybe it is time to break out an UML editor.)
>
>
> I propose you to send these concerns to live-wrapper project which has just
> begun and it's advertised as highly modular by Iain. It would be quite nice
> if all these concerns were properly addressed by Iain's tool.
>
>   I am not saying that they are not welcomed to live-build but, right now, I
> think we should focus on making UEFI to boot and not re-thinking all the
> bootloader handling.
>
>> grub-mkrescue layout is rarely used for distro ISOs.
>> I blame this on the existing SYSLINUX based production software
>> for distro ISOs. In principle, a pure GRUB2 or a pure SYSLINUX
>> equipment appears to be the more reasonable choice.
>
>
> I once asked in a Debconf why the people were so stubborn to use syslinux
> instead of using grub2 (which seems technically superior to me). It would
> seem that the same people that maintain syslinux happen to maintain the
> kernel boot stack (or whatever it is called, I mean what happens just after
> the bootloader handling the execution to the kernel). So, that means, it's
> far easier to them to debug why the kernel is refusing to boot.
>

I was wondering that also. The GRUB is so cool and can do everything, right?

It also means it can crumble and fall apart in so many interesting ways.

I mean if you install grub on a LVM soft-RAID array and it then does
not boot you are wondering why it happened when it has all those RAID
modules. And you find that it has RAID modules only for the *previous*
revision of the LVM format.

So you do what you would plan for from the start with Syslinux - plug
in an USB stick and put a boot partition on it, yay.

Could have saved hours of debugging by going with the stupid limited
Syslinux from the start, right?

>>> Maybe we can just name them as:
>>> "Main bootloader"
>>> and
>>> "Alternate bootloader".
>>
>>
>> The model does not imply any ranking. "First", "Second", "Third"
>> could be justified, because there are lists in El Torito and
>> partition tables where the boot entries have to line up in sequence.
>>
>> For my taste, "Main" or "Primary" too much implies a rank.
>
>
> So... what about using:
>
> FIRST_BOOTLOADER
> and
> SECOND_BOOTLOADER
>
> instead of my current:
>
> PRIMARY_BOOTLOADER
> and
> SECONDARY_BOOTLOADER
>


why not BOOTLOADERS?

The concept of being primary or secondary is just broken.

You can store 64 el-torito catalog entries on a CD. The different
entries are separated by -eltorito-alt-boot option. When you put the
CD with a BIOS and EFI entry in a machine that prefers UEFI the efi
entry is primary even when there is a CSM. When you put the CD into a
machine with legacy BIOS the BIOS entry is primary in the EFI one
useless.

There are some technical details like it is desirable to put the BIOS
entry before the EFI entry. This may be either enforced by reordering
the bootloader list automagically or just by setting the default to
syslinux,grub-efi and explaining in the docs that this is the usual
order and changing the order may potentially cause issues.

There are more technical details like the bootloader for i386 and
amd64 BIOS is the same one and on EFI it's two different binaries. Or
that when there is an EFI bootloader it's desirable to create another
e-torito entry for it as APM to boot on Macs. The technical details of
creating multiple partitions, boot entries, and whatnot are
implementation details. It's nice to document these details somewhere
for people who want to further butcher the created medium, add support
for more bootloaders, etc.

So basically what we have is support for two PC firmware types:

BIOS
EFI

and two bootloader alternatives for each firmware type

syslinux
grub

and for simlicity only one bootloader for one firmware type is
supported on single medium. Since booting on BIOS platform is well
supported with syslinux and booting on EFI platform is well-supported
with grub it is desirable to have the option to specify different
bootloader type for each supported platform and make it the default.
So rather than

BOOTLOADER=syslinux
BOOT_FIRMWARE=bios,efi

we have

BOOTLOADERS=syslinux,grub-efi

That is the bootloader name encodes the whole bootloader-firmware
pair. There is no need to specify more. It is well possible to specify
to not include 32bit efi binaries when building a 64bit CD build but
that's *-efi installation option and not a separate bootloader type.

This means the user can have 1-2 bootloaders on a single medium. And
if coreboot or whatnot support is added in the future there is
potential to have more.


Thanks

Michal

Send a report that this bug log contains spam.