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: adrian15 <[email protected]>, [email protected]
Resent-From: adrian15 <[email protected]>
Resent-To: [email protected]
Resent-CC: Debian QA Group <[email protected]>
X-Loop: [email protected]
Resent-Date: Fri, 22 Jan 2016 23:27:02 +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.145350511614964
          (code B ref 731709); Fri, 22 Jan 2016 23:27:02 +0000
Received: (at 731709) by bugs.debian.org; 22 Jan 2016 23:25:16 +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=-6.3 required=4.0 tests=BAYES_00,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, 24; hammy, 150; neutral, 442; spammy,
	0. spammytokens: hammytokens:0.000-+--UD:iso, 0.000-+--H*u:31.8.0,
	0.000-+--H*UA:31.8.0, 0.000-+--netinst,
	0.000-+--HX-Google-DKIM-Signature:in-reply-to
Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233])
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84)
	(envelope-from <[email protected]>)
	id 1aMl4u-0003sz-4c
	for [email protected]; Fri, 22 Jan 2016 23:25:16 +0000
Received: by mail-wm0-x233.google.com with SMTP id b14so3455102wmb.1
        for <[email protected]>; Fri, 22 Jan 2016 15:25:15 -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=YVF8rX0DL2QPZ9BwHyN7wxwdxCZTOE7LS1QrAMLb7dM=;
        b=tBW5WZPKB6y1GQuFl4YRdBUHCGqCZaNBcH6xss2pWASEHbZizpb6wrBrnLJvlIeygk
         M2tj2dKJMmvsN+8gM3a9gTkeM2ZQJRcWm357f/MQpAmjJosAALanWtRkcSN1sMLquKKm
         Qe5rz6XOEaeath8pmucBItQldQJod225hJ1qGGmuy9Adphh0LUoSW3y+oYWwgH+m29xI
         XOOJY4+KBHl/AFaLirieuqPAWkCd3aYAJM8MImS+LVvXqpn1y/QIuZSBcJqdLdqLENZ0
         qgPMa44CFOwfvwjiH9Hd6dT0YPl2CgRgfM1/eD4zsMfceBmddGOXOMqKskr3kIh35fA0
         DCuA==
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=YVF8rX0DL2QPZ9BwHyN7wxwdxCZTOE7LS1QrAMLb7dM=;
        b=DEGjwhM/ewrcWry2G5y/o/3fwGJs2Pn2dJpqtLzI3ZVasPgVGLzz8xQYG1vM8DnSYJ
         dVDPUYFamqAviChEdiszcVavkCR2BP2SzHfCj+XVQypRj4NkstJWCMgT0JoJTiy3aBlK
         yhRvC/SLDlhDvJajeQNR2dP3SVW53aimiBVDUqSi4ycjYD1Exze97gS7ckQq2/R8XVMj
         zCV7DfLCHRtrx7Z3pqg7bS+SmmjQwhAq1S5EOcJgt8+v98IubkPg55vT0XANRkbd7DkC
         /hOp2tmLfWBKc6yFw9mI0rosdzG9lRQPbCdA346LGUZM876ypo4/s8L8Hp84UUI06j0f
         0hSg==
X-Gm-Message-State: AG10YOR1wGrfyxpFhOVLyhncij3Hst9dyRmtSTgyWqUyaamg9gfXxgUK3lAGk0aRvkOwxg==
X-Received: by 10.28.230.74 with SMTP id d71mr5761706wmh.97.1453505108746;
        Fri, 22 Jan 2016 15:25:08 -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 s8sm7835850wje.35.2016.01.22.15.25.07
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 22 Jan 2016 15:25:08 -0800 (PST)
Message-ID: <[email protected]>
Date: Sat, 23 Jan 2016 00:25:05 +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]
References: <[email protected]> <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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/

Send a report that this bug log contains spam.