Debian Bug report logs - #832687
support uefi

Full log

Message #253 received at [email protected] (full text, mbox, reply):

Received: (at 731709) by bugs.debian.org; 23 Jan 2016 23:41:56 +0000
From [email protected] Sat Jan 23 23:41:56 2016
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.3 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FOURLA,FREEMAIL_FROM,HAS_BUG_NUMBER,
	RCVD_IN_DNSWL_LOW,SPF_PASS,STATIC_RIMA_TDE,URIBL_CNKR autolearn=ham
	autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 33; hammy, 150; neutral, 329; spammy,
	0. spammytokens: hammytokens:0.000-+--H*UA:31.8.0, 0.000-+--H*u:31.8.0,
	0.000-+--HX-Google-DKIM-Signature:in-reply-to,
	0.000-+--HX-Google-DKIM-Signature:references, 0.000-+--H*UA:31.0
Return-path: <[email protected]>
Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230])
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84)
	(envelope-from <[email protected]>)
	id 1aN7oa-0008Kt-48
	for [email protected]; Sat, 23 Jan 2016 23:41:56 +0000
Received: by mail-wm0-x230.google.com with SMTP id 123so25454067wmz.0
        for <[email protected]>; Sat, 23 Jan 2016 15:41:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=zAxojxQE0+gJRVD/yPJkxCFRsDcXQ3e4cGvj95iezwk=;
        b=AdvpEGDoz3FEMJfMOogSZNgq0PJqaKX+1f0Cupc9s8F0UZu8lQy2wzFg6J7iFKhS1l
         Ir88Pcwr8BDUrO0iWo5tC4JBnH6o6GzdybssRKyCI9QaltIApFm1rciLEkG0ezznYnvr
         5NNKzF/oPj9G4+dER7KUB/dHpHC/1H0UtFZ/l1/rKrENv/Zj+Ka8Ir9ykps2xKd3aTX8
         Y5KbgZ55uVJfzdQiI8d88RUu2DITn6GSiS4Oe9GomEftsdRCMc4S4oQg3Wfyuv9tYTND
         7S+waqOB1IJrbWDwQZIu9fxKTwSP4ZU3G1CCxBFGh1mpecFlNecIVNPRiuxLPlpIaq6C
         mGPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
         :cc:subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        bh=zAxojxQE0+gJRVD/yPJkxCFRsDcXQ3e4cGvj95iezwk=;
        b=iII86F0SfGc/Jm1sB4PeY0wgbkSpClVf5uMn+x7GeAo/CsYxMiOyRcPK+ipnJhaLXC
         dCqMTsWHpKuaYWyKxE2QAGoKn1UAmIVLVQbMgVFqi/yyGx+b7/FSsPBurHPMEsxpPZX5
         HP/abH5lYWevLPwqvBnMZGuwQrSGm5DJcggFnJMVjLEW7LF8gr/HjpP9lsXxiN2Ekli1
         LORRDyD5cBa4MviHQLFqCGFDhIa7tfQF/YdEGE8jo+StI/2tsXukEJFAXo5x+6rFBMqL
         WZLyBhpFxAc4TGupGLh1hv9jwHjgKu9zrtsCppQDAJBHiY+di0CfftLJD8JtBg3egARi
         PV5w==
X-Gm-Message-State: AG10YOQbY0ikZ8964EG35Zja+aJwczQSGqP7v3QQ206oHpAiNF0iTtd1sdTJh5MOqcYqqA==
X-Received: by 10.28.194.197 with SMTP id s188mr10010073wmf.44.1453592509145;
        Sat, 23 Jan 2016 15:41:49 -0800 (PST)
Received: from [192.168.10.45] (240.Red-88-21-45.staticIP.rima-tde.net. [88.21.45.240])
        by smtp.gmail.com with ESMTPSA id l2sm12242045wjf.15.2016.01.23.15.41.47
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 23 Jan 2016 15:41:48 -0800 (PST)
Message-ID: <[email protected]>
Date: Sun, 24 Jan 2016 00:41:46 +0100
From: adrian15 <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Thomas Schmitt <[email protected]>, [email protected]
CC: [email protected], [email protected], [email protected], 
 [email protected], [email protected]
Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete
 (repos)
References: <[email protected]> <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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 am personally in a favour of GRUB2-only Live CDs so that it's much 
easier to have native Super Grub2 Disk in them :) .

>> 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

?

I could even add a third bootloader if needed. And, well, I have some 
ideas on how to add some special functions to binary_bootloader files so 
that we have some sort of Object-Oriented / Hook programming when 
defining what goes into the mkisofs options.

If you check current: binary_iso file it just relies on existing 
binary_bootloaders without having an agnostic bootloader approach.

Here it's what I'm talking about:

https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145

case "${LB_PRIMARY_BOOTLOADER}" in
	grub)
(...)
        grub-pc)
(...)

esac


We could just invent the:

grub-pc-xorriso-options()
or
syslinux-xorriso-options()

functions which would be defined in:

binary_grub-pc
or
binary_syslinux
files

and handle all of these with only 3 or 4 lines of code.

E.g. binary_iso would add '-eltorito-alt-boot' just before a second 
bootloader so that the bootloader only needs to take care of their own 
boot options.


Is there anyone opposed to such a big change on live-build handling of 
bootloaders?


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Send a report that this bug log contains spam.