[gentoo-dev] borked release media

[gentoo-dev] borked release media

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hey people, what are we going to do with bugs like:

<https://bugs.gentoo.org/show_bug.cgi?id=421839>
<https://bugs.gentoo.org/show_bug.cgi?id=445848>

I'd like to help with things. Is the process of building livecd .isos
and stages documented somewhere? I'd like to reproduce problems locally,
work on fixes, and join the release teams.

I also think points made at
<https://bugs.gentoo.org/show_bug.cgi?id=438234> are very reasonable,
and we should do more testing of published media/stages.

The serious problem here is that we need *new* users. A non-working
install CD is a really bad thing here, don't you think? ;-)

Again, I'm willing to do the work, just need some documentation/pointers.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] borked release media

[Matt Turner]

On Fri, Dec 7, 2012 at 8:55 PM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> Hey people, what are we going to do with bugs like:
>
> <https://bugs.gentoo.org/show_bug.cgi?id=421839>
> <https://bugs.gentoo.org/show_bug.cgi?id=445848>
>
> I'd like to help with things. Is the process of building livecd .isos
> and stages documented somewhere? I'd like to reproduce problems locally,
> work on fixes, and join the release teams.
>
> I also think points made at
> <https://bugs.gentoo.org/show_bug.cgi?id=438234> are very reasonable,
> and we should do more testing of published media/stages.
>
> The serious problem here is that we need *new* users. A non-working
> install CD is a really bad thing here, don't you think? ;-)
>
> Again, I'm willing to do the work, just need some documentation/pointers.
>
> Paweł
>

Indeed, it is a problem. Fortunately the missing /run was confirmed
fixed earlier today on IRC, so that should be resolved shortly and
with it the second bug you mention.

The main problem here is that it's really easy to break the release
media. Mistakes happen and are a normal part of development, but for
instance stabilizing linux-headers-3.6 (bug 443532) with multiple
outstanding bugs caused some completely predictable breakage.

I have never once been able to grab a portage snapshot and build a
stage 1, 2, 3 series from it without encountering at least a couple of
problems with the tree.

I think we should consider things that break release media serious
regressions. I don't know what that entails specifically, but whether
it need be QA bashing down your door or a quick fix or revert, it sure
would be nice to get Gentoo to a place where release media always
works.

In any case, we'd love some extra help. jmbsvicetto and armin76 have
been managing all of the autobuilds, to my knowledge, for a long time.
catalyst could also use some work. Spend a day or so building some
stages and I have no doubt you'd find things you want to change. :)

In short, I think the conversation we should be having should be about
how to avoid breaking release builds and how to quickly fix problems
when they're discovered.

Thanks,
Matt

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner <mattst88@gentoo.org> wrote:
> I have never once been able to grab a portage snapshot and build a
> stage 1, 2, 3 series from it without encountering at least a couple of
> problems with the tree.

Ditto - the latest issue I've run into is: 443472.  Probably won't
impact the average user, and perhaps I should just modify the script
to not bother reading that file and figure out what the latest build
is on its own.

>
> I think we should consider things that break release media serious
> regressions. I don't know what that entails specifically, but whether
> it need be QA bashing down your door or a quick fix or revert, it sure
> would be nice to get Gentoo to a place where release media always
> works.

Agreed.  If a user can't just burn a CD and then do an emerge kde-meta
there is a problem.

>
> In short, I think the conversation we should be having should be about
> how to avoid breaking release builds and how to quickly fix problems
> when they're discovered.

I think those working with catalyst have the most to add regarding
what breaks them.

As far as detect-ability goes, do we need some kind of tinderbox that
just does a daily build.  Perhaps just build from stage3 to a couple
of world targets, including one with some server-oriented software,
one with gnome, and one with kde?  I've reported a bunch of bugs with
the EC2 bootstrap script described on my blog (not my original work),
but it is only automated from a build perspective - testing is manual.
 That takes about 18 hours to build (with an emphasis on economy), and
I use spot instances so it really only costs maybe a buck or two.

My experience has been that if it builds it usually works.  So, simply
testing for whether the build completes is a pretty-good first step.

Of course, for system packages our recourse isn't necessarily good,
since we don't have a test branch or anything like that.  If we wanted
to revert we'd have to impact users who already upgraded.  Obviously
the goal would be to fix in place with a new revbump, assuming that
were possible.

Rich

Re: [gentoo-dev] borked release media

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/08/2012 06:50 AM, Rich Freeman wrote:
> On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner <mattst88@gentoo.org> wrote:
>> I have never once been able to grab a portage snapshot and build a
>> stage 1, 2, 3 series from it without encountering at least a couple of
>> problems with the tree.
> 
> Ditto - the latest issue I've run into is: 443472.  Probably won't
> impact the average user, and perhaps I should just modify the script
> to not bother reading that file and figure out what the latest build
> is on its own.
> 
>>
>> I think we should consider things that break release media serious
>> regressions. I don't know what that entails specifically, but whether
>> it need be QA bashing down your door or a quick fix or revert, it sure
>> would be nice to get Gentoo to a place where release media always
>> works.
> 
> Agreed.  If a user can't just burn a CD and then do an emerge kde-meta
> there is a problem.
> 
>>
>> In short, I think the conversation we should be having should be about
>> how to avoid breaking release builds and how to quickly fix problems
>> when they're discovered.
> 
> I think those working with catalyst have the most to add regarding
> what breaks them.
> 
> As far as detect-ability goes, do we need some kind of tinderbox that
> just does a daily build.  Perhaps just build from stage3 to a couple
> of world targets, including one with some server-oriented software,
> one with gnome, and one with kde?  I've reported a bunch of bugs with
> the EC2 bootstrap script described on my blog (not my original work),
> but it is only automated from a build perspective - testing is manual.
>  That takes about 18 hours to build (with an emphasis on economy), and
> I use spot instances so it really only costs maybe a buck or two.

I build about ~1300 packages for amd64 and x86 nearly every day from a
fresh snapshot.  I'm working on automating it so it really is every day.
 Once it is automated I suppose I can add kde-meta to the list, even
though... well... it's kde.

- -Zero
> 
> My experience has been that if it builds it usually works.  So, simply
> testing for whether the build completes is a pretty-good first step.
> 
> Of course, for system packages our recourse isn't necessarily good,
> since we don't have a test branch or anything like that.  If we wanted
> to revert we'd have to impact users who already upgraded.  Obviously
> the goal would be to fix in place with a new revbump, assuming that
> were possible.
> 
> Rich
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQw2tZAAoJEKXdFCfdEflKrh4P/i1aJCtnVWh5IlTJ5QMd36S+
eE6chQuZGpm+7TLUsGkRG3rfTKe1vTkDj+e0R5KNQTWL3URsfo9Bc+x87EKBDlZd
xkx2VRA+AojFcKwJzUDznwAwCYRz9NIhEz+6bX/Gd0w1PR7ig6JucPa9e6dj4XqG
pWvf9me3D78WuNOGcQ70jYX7JxNr0+vzzRu0e4EoEphSLYzIPpdz2FIs6CHov0qD
y/imKNG8TjpWRP6/It4s3+83B6nsPfGl9JcwlMXjqncAXNHc0WStFWx5oV/NfqT/
myvV/90YdY2oI5++RcWXsI52aEYuTfvnxZM1WghiymW0UVdR7r7OYMHbiE3Tq59f
p8kLgGSxwyleOQHmX9o822mIF53A2PRZ/FEs6Jhr7r1R/NTnvMnePQUUMEAntwlq
DjPKui7MhQr8KgnekAqw6EU42spgyKc22QXvp2rdAUnviBA5+c5CtU3RDvx5b9GO
VDvuCCI24fsXe9/HyKknoyLjMwfQGHIFp8Cy3oLG40pT9LLzip+jehdv+Kdmy7nX
x69bsEioIoVw23wtuWou1+a+HAlfZzTQWlr4TbeAZug9V1YGg9HxP/amzxOrBbcs
qbT4Rtf332Kzx4FqYfU/ex6uaMN9fHLv6MAfS5D0l3+P5KK9zMc5P8Tlla3pRFZN
I0g6imtLeVA0pMQFgsym
=2tcz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] borked release media

[Peter Stuge]

Matt Turner wrote:
> I think we should consider things that break release media serious
> regressions.

I think we should consider things that break anything serious
regressions.

Why should release media be more special than anything else?

My email and bugzilla sweep a few days ago was during a stage4
catalyst run. I found several trivial problems which I fixed
in seconds by pushing some commits to my overlay.

In Gentoo, nothing has changed since then.

Nothing has happened to those bugs in bugzilla, and nothing has
happened in gentoo-x86.

I don't think it's neccessarily less serious that existing tested
trivial bug fixes don't make it to the tree.


//Peter

Re: [gentoo-dev] borked release media

[Walter Dnes]

On Fri, Dec 07, 2012 at 08:55:04PM -0800, "Pawe?? Hajdan, Jr." wrote

> The serious problem here is that we need *new* users. A non-working
> install CD is a really bad thing here, don't you think? ;-)

  While we're at it, can we please also make a USB-key "install ISO"?
I'm not asking merely because "other distros do it".  I'm asking because
the situation has changed in the past half-dozen years.  Back in 2005 or
2006, almost all machines had a CD and/or DVD, and many older PC BIOSes
did not allow for booting from a USB key.  Fast-forward to 2012 (and
soon 2013) and...
* just about every PC is capable of booting from USB
* quite a few netbooks/notebooks do not have a CD or DVD drive.  E.g. I
  had to boot from a Knoppix USB key as my working environment to do the
  initial portion of the Gentoo install on my netbook.

  Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I
have occasionally fouled up those intructions.  It doesn't exactly
encourage new Gentoo users to have to go through that tap-dance.  Arch
linux https://wiki.archlinux.org/index.php/USB_Installation_Media
manages to have a dual-bootable (CD / USB-key) image as a standard
feature.  In addition to installation, it would make the base of a good
system rescue utility.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] borked release media

[Fernando Reyes]

iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. 

# isohybrid image.ISO
# did if=image.ISO of=/dev/sdb bs=8192k

sdb being your removable device. Also keep in mind that any data on sdb will be wiped after running the dd command.

likewhoa  

Walter Dnes <waltdnes@waltdnes.org> wrote:

>On Fri, Dec 07, 2012 at 08:55:04PM -0800, "Pawe?? Hajdan, Jr." wrote
>
>> The serious problem here is that we need *new* users. A non-working
>> install CD is a really bad thing here, don't you think? ;-)
>
>  While we're at it, can we please also make a USB-key "install ISO"?
>I'm not asking merely because "other distros do it".  I'm asking because
>the situation has changed in the past half-dozen years.  Back in 2005 or
>2006, almost all machines had a CD and/or DVD, and many older PC BIOSes
>did not allow for booting from a USB key.  Fast-forward to 2012 (and
>soon 2013) and...
>* just about every PC is capable of booting from USB
>* quite a few netbooks/notebooks do not have a CD or DVD drive.  E.g. I
>  had to boot from a Knoppix USB key as my working environment to do the
>  initial portion of the Gentoo install on my netbook.
>
>  Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I
>have occasionally fouled up those intructions.  It doesn't exactly
>encourage new Gentoo users to have to go through that tap-dance.  Arch
>linux https://wiki.archlinux.org/index.php/USB_Installation_Media
>manages to have a dual-bootable (CD / USB-key) image as a standard
>feature.  In addition to installation, it would make the base of a good
>system rescue utility.
>
>-- 
>Walter Dnes <waltdnes@waltdnes.org>
>I don't run "desktop environments"; I run useful applications
>

Re: [gentoo-dev] borked release media

[Peter Stuge]

Fernando Reyes wrote:
> iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. 
> 
> # isohybrid image.ISO

Please send a patch to the gentoo-catalyst@ list which adds this as
an optional step in the catalyst livecd2 target in a nice way, and
file a bug with updated ebuilds for catalyst which add the dependency.

Many thanks!


//Peter

Re: [gentoo-dev] borked release media

[Fernando Reyes]

The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards.

likewhoa 

Peter Stuge <peter@stuge.se> wrote:

>Fernando Reyes wrote:
>> iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. 
>> 
>> # isohybrid image.ISO
>
>Please send a patch to the gentoo-catalyst@ list which adds this as
>an optional step in the catalyst livecd2 target in a nice way, and
>file a bug with updated ebuilds for catalyst which add the dependency.
>
>Many thanks!
>
>
>//Peter
>

Re: [gentoo-dev] borked release media

[Markos Chandras]

On 9 December 2012 05:04, Peter Stuge <peter@stuge.se> wrote:
> Fernando Reyes wrote:
>> iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands.
>>
>> # isohybrid image.ISO
>
> Please send a patch to the gentoo-catalyst@ list which adds this as
> an optional step in the catalyst livecd2 target in a nice way, and
> file a bug with updated ebuilds for catalyst which add the dependency.
>
> Many thanks!
>
>
> //Peter
>

I think it is possible to use the unetbootin utility to make the
minimal iso image boot from a USB flash disk.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] borked release media

[Maxim Kammerer]

On Sun, Dec 9, 2012 at 11:18 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> I think it is possible to use the unetbootin utility to make the
> minimal iso image boot from a USB flash disk.

Just make the real thing…
https://github.com/mkdesu/liberte/blob/master/src/root/mkimage

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

Peter Stuge schrieb:
> Fernando Reyes wrote:
>> iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. 
>>
>> # isohybrid image.ISO
> Please send a patch to the gentoo-catalyst@ list which adds this as
> an optional step in the catalyst livecd2 target in a nice way, and
> file a bug with updated ebuilds for catalyst which add the dependency.

Bug was already reported some time ago
https://bugs.gentoo.org/show_bug.cgi?id=251719


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

Fernando Reyes schrieb:
> The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards.

isohybrid works with UEFI by passing --uefi option. This requires a UEFI
bootable image (such as a UEFI capable boot loader or kernel with EFI
stub support) to be present.

Starting with syslinux-6.00 it will be possible to boot UEFI systems in
EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2,
ELILO) might be used.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Fernando Reyes]

That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios.

Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

>Fernando Reyes schrieb:
>> The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards.
>
>isohybrid works with UEFI by passing --uefi option. This requires a UEFI
>bootable image (such as a UEFI capable boot loader or kernel with EFI
>stub support) to be present.
>
>Starting with syslinux-6.00 it will be possible to boot UEFI systems in
>EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2,
>ELILO) might be used.
>
>
>Best regards,
>Chí-Thanh Christopher Nguyễn
>
>

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes
<likewhoa@weboperative.com> wrote:
> grub seems out of the questions because of licensing issues.

What licensing issues?  Just distribute the source.  If the Gentoo
Foundation goes into the hardware business and starts distributing
hardware that only boots Gentoo-signed grub bootloaders then we'll
have to distribute our private key.  Or we could just be intelligent
and not distribute hardware that only boots Gentoo-signed grub
bootloaders.

For some reason everybody goes nuts over UEFI and GPLv3.  The license
isn't any more unclear about that than anything else that people go
nuts over the GPL about.

GPLv3 states:
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information.

You only need to provide installation information if "the conveying
occurs as part of a transaction in which the right of possession and
use of the User Product is transferred to the recipient in perpetuity
or for a fixed term."  So, as long as Gentoo doesn't distribute
hardware, we aren't bound by that clause.

If somebody else distributes hardware that only boots Gentoo-signed
GRUB bootloaders then they'll need to distribute the Gentoo private
keys along with them or they can be sued by the Grub copyright
holders.  If they ask us for said keys we'll just say no, and they can
fight it out with the FSF.  We aren't the ones distributing Grub out
of compliance, so we haven't violated the license.

If somebody has a specific licensing-related concern we can always
have the Foundation/ licensing team look into it, as we are already
doing with the copyright attribution question.

Rich

Re: [gentoo-dev] borked release media

[Fernando Reyes]

I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. 

Rich Freeman <rich0@gentoo.org> wrote:

>On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes
><likewhoa@weboperative.com> wrote:
>> grub seems out of the questions because of licensing issues.
>
>What licensing issues?  Just distribute the source.  If the Gentoo
>Foundation goes into the hardware business and starts distributing
>hardware that only boots Gentoo-signed grub bootloaders then we'll
>have to distribute our private key.  Or we could just be intelligent
>and not distribute hardware that only boots Gentoo-signed grub
>bootloaders.
>
>For some reason everybody goes nuts over UEFI and GPLv3.  The license
>isn't any more unclear about that than anything else that people go
>nuts over the GPL about.
>
>GPLv3 states:
>If you convey an object code work under this section in, or with, or
>specifically for use in, a User Product, and the conveying occurs as
>part of a transaction in which the right of possession and use of the
>User Product is transferred to the recipient in perpetuity or for a
>fixed term (regardless of how the transaction is characterized), the
>Corresponding Source conveyed under this section must be accompanied
>by the Installation Information.
>
>You only need to provide installation information if "the conveying
>occurs as part of a transaction in which the right of possession and
>use of the User Product is transferred to the recipient in perpetuity
>or for a fixed term."  So, as long as Gentoo doesn't distribute
>hardware, we aren't bound by that clause.
>
>If somebody else distributes hardware that only boots Gentoo-signed
>GRUB bootloaders then they'll need to distribute the Gentoo private
>keys along with them or they can be sued by the Grub copyright
>holders.  If they ask us for said keys we'll just say no, and they can
>fight it out with the FSF.  We aren't the ones distributing Grub out
>of compliance, so we haven't violated the license.
>
>If somebody has a specific licensing-related concern we can always
>have the Foundation/ licensing team look into it, as we are already
>doing with the copyright attribution question.
>
>Rich
>

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes
<likewhoa@weboperative.com> wrote:
> I don't know the details of the issue but I know that I was prevented from using grub on the livedvd.

Well, if some perceived legal constraint is keeping us from doing
whatever seems to be technically most appropriate we should
investigate the matter and resolve it.  If, on the other hand, it
simply makes sense to use something else, then no sense belaboring the
point.

People just seem to be really paranoid about GPLv3 and Grub.  We're
already talking to the FSF about how they handle copyright attribution
on their own projects, so I suppose we could get their opinion on UEFI
as well.  However, I don't see anything in the language of the license
that creates a problem when using it with UEFI, unless one wants to
sell locked-down hardware.  Doing that would be a violation of our
social contract, let alone the GPLv3.

Rich

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote:
> On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes
> <likewhoa@weboperative.com> wrote:
> > I don't know the details of the issue but I know that I was prevented from using grub on the livedvd.
> 
> Well, if some perceived legal constraint is keeping us from doing
> whatever seems to be technically most appropriate we should
> investigate the matter and resolve it.  If, on the other hand, it
> simply makes sense to use something else, then no sense belaboring the
> point.
> 
> People just seem to be really paranoid about GPLv3 and Grub.  We're
> already talking to the FSF about how they handle copyright attribution
> on their own projects, so I suppose we could get their opinion on UEFI
> as well.  However, I don't see anything in the language of the license
> that creates a problem when using it with UEFI, unless one wants to
> sell locked-down hardware.  Doing that would be a violation of our
> social contract, let alone the GPLv3.

The FSF has already said that using Grub2 and the GPLv3 is just fine
with the UEFI method of booting, so there is no problem from that side.
There's a statement about this somewhere on their site if you are
curious.

The only one objecting to GPLv3 and UEFI is the current rules for
getting a shim/bootloader signed by Microsoft, but the current
implementations we have all have either a GPLv2 or BSD licensed shim
which then loads GRUB, so all is fine from a licensing and legal
standpoint from everyone involved.

Hope this helps,

greg k-h

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sun, Dec 9, 2012 at 1:24 PM, Greg KH <gregkh@gentoo.org> wrote:
>
> The FSF has already said that using Grub2 and the GPLv3 is just fine
> with the UEFI method of booting, so there is no problem from that side.
> There's a statement about this somewhere on their site if you are
> curious.
>
> The only one objecting to GPLv3 and UEFI is the current rules for
> getting a shim/bootloader signed by Microsoft, but the current
> implementations we have all have either a GPLv2 or BSD licensed shim
> which then loads GRUB, so all is fine from a licensing and legal
> standpoint from everyone involved.

Makes sense to me, thanks.

An MS-signed bootloader isn't nearly as critical for Gentoo as it is
for other distros - we're not really aiming for the
stick-a-CD-in-and-you're-done  crowd.  If somebody can partition their
drive, build and install a kernel and grub, configure make.conf, and
build a system, then I'm not too concerned that they have to run some
script to generate a key, sign their bootloader, and register that key
with their firmware, or disable secure boot just to boot the install
CD (though it sounds like some firmwares just pop up a warning and let
you proceed, which is what my Chromebook does in dev mode).

Rich

Re: [gentoo-dev] borked release media

[Fernando Reyes]

Then let's get UEFI support on our release media and out the box usb booting so users don't have to go boot other livecds. 


likewhoa

Greg KH <gregkh@gentoo.org> wrote:

>On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote:
>> On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes
>> <likewhoa@weboperative.com> wrote:
>> > I don't know the details of the issue but I know that I was prevented from using grub on the livedvd.
>> 
>> Well, if some perceived legal constraint is keeping us from doing
>> whatever seems to be technically most appropriate we should
>> investigate the matter and resolve it.  If, on the other hand, it
>> simply makes sense to use something else, then no sense belaboring the
>> point.
>> 
>> People just seem to be really paranoid about GPLv3 and Grub.  We're
>> already talking to the FSF about how they handle copyright attribution
>> on their own projects, so I suppose we could get their opinion on UEFI
>> as well.  However, I don't see anything in the language of the license
>> that creates a problem when using it with UEFI, unless one wants to
>> sell locked-down hardware.  Doing that would be a violation of our
>> social contract, let alone the GPLv3.
>
>The FSF has already said that using Grub2 and the GPLv3 is just fine
>with the UEFI method of booting, so there is no problem from that side.
>There's a statement about this somewhere on their site if you are
>curious.
>
>The only one objecting to GPLv3 and UEFI is the current rules for
>getting a shim/bootloader signed by Microsoft, but the current
>implementations we have all have either a GPLv2 or BSD licensed shim
>which then loads GRUB, so all is fine from a licensing and legal
>standpoint from everyone involved.
>
>Hope this helps,
>
>greg k-h
>

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

Fernando Reyes schrieb:
> That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios.

No, all we need is to enable EFI stub support in the kernel, and
integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
some location where UEFI looks for it (/efi/boot/bootx64.efi).

This has the disadvantage of not allowing to pass additional kernel
parameters during boot. But it might still be an acceptable stopgap
measure if the alternative is to not boot at all.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 07:46:59PM +0100, Chí-Thanh Christopher Nguyễn wrote:
> Fernando Reyes schrieb:
> > That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios.
> 
> No, all we need is to enable EFI stub support in the kernel, and
> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
> some location where UEFI looks for it (/efi/boot/bootx64.efi).
> 
> This has the disadvantage of not allowing to pass additional kernel
> parameters during boot. But it might still be an acceptable stopgap
> measure if the alternative is to not boot at all.

No, don't do that for an "install" kernel, that way is madness, just use
a real UEFI bootloader which can handle an initrd and the like properly
(like gummiboot, which arch is using for their UEFI bootloader, and I've
been using for months quite successfully.)

Only boot a kernel directly from UEFI if you build your own and have
customized it for your hardware.  Some bioses will let you do this in
secure boot mode without having to sign anything, I took a video of this
on Friday showing how easy it can be:
	https://plus.google.com/u/0/111049168280159033135/posts/81V5oyzwK63

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 01:35:57PM -0500, Rich Freeman wrote:
> On Sun, Dec 9, 2012 at 1:24 PM, Greg KH <gregkh@gentoo.org> wrote:
> >
> > The FSF has already said that using Grub2 and the GPLv3 is just fine
> > with the UEFI method of booting, so there is no problem from that side.
> > There's a statement about this somewhere on their site if you are
> > curious.
> >
> > The only one objecting to GPLv3 and UEFI is the current rules for
> > getting a shim/bootloader signed by Microsoft, but the current
> > implementations we have all have either a GPLv2 or BSD licensed shim
> > which then loads GRUB, so all is fine from a licensing and legal
> > standpoint from everyone involved.
> 
> Makes sense to me, thanks.
> 
> An MS-signed bootloader isn't nearly as critical for Gentoo as it is
> for other distros - we're not really aiming for the
> stick-a-CD-in-and-you're-done  crowd.  If somebody can partition their
> drive, build and install a kernel and grub, configure make.conf, and
> build a system, then I'm not too concerned that they have to run some
> script to generate a key, sign their bootloader, and register that key
> with their firmware, or disable secure boot just to boot the install
> CD (though it sounds like some firmwares just pop up a warning and let
> you proceed, which is what my Chromebook does in dev mode).

The UEFI spec does not allow that mode of operation in secure boot mode,
sorry. You will have to disable it in order to boot a Gentoo image,
which is fine, but there's no reason why Gentoo can't use the MS-signed
shim bootloader like all other distros are using, right?

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[likewhoa]

On 12/09/2012 01:46 PM, Chí-Thanh Christopher Nguyễn wrote:
> Fernando Reyes schrieb:
>> That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios.
> No, all we need is to enable EFI stub support in the kernel, and
> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
> some location where UEFI looks for it (/efi/boot/bootx64.efi).
>
> This has the disadvantage of not allowing to pass additional kernel
> parameters during boot. But it might still be an acceptable stopgap
> measure if the alternative is to not boot at all.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
interesting and probably something we can get away with since not all
users actually touch the kernel line but some do so it might not be a
smart option to disable kernel parameters on UEFI only systems.

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

Greg KH schrieb:
>> No, all we need is to enable EFI stub support in the kernel, and
>> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
>> some location where UEFI looks for it (/efi/boot/bootx64.efi).
>>
>> This has the disadvantage of not allowing to pass additional kernel
>> parameters during boot. But it might still be an acceptable stopgap
>> measure if the alternative is to not boot at all.
> 
> No, don't do that for an "install" kernel, that way is madness, just use
> a real UEFI bootloader which can handle an initrd and the like properly

Can you explain what problems you see with that? How does
CONFIG_INITRAMFS_SOURCE handle initrd improperly?

> Only boot a kernel directly from UEFI if you build your own and have
> customized it for your hardware.

I booted genkernel generated non-customized kernels as well as customized
hand-configured kernels using that method.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

likewhoa schrieb:

> interesting and probably something we can get away with since not all
> users actually touch the kernel line but some do so it might not be a
> smart option to disable kernel parameters on UEFI only systems.

The kernel parameters are not disabled, they just have to be specified at
build time instead of runtime. With a customized kernel you typically set
CONFIG_CMDLINE="root=PARTUUID=..." or similar.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Diego Elio Pettenò]

On 09/12/2012 19:59, Greg KH wrote:
> The UEFI spec does not allow that mode of operation in secure boot mode,
> sorry. You will have to disable it in order to boot a Gentoo image,
> which is fine, but there's no reason why Gentoo can't use the MS-signed
> shim bootloader like all other distros are using, right?

I wouldn't say we have any problem with that. Fabio already got Sabayon
to support the shim. The only problem is that we'd have to provide a
shim binary that _is_ signed, rather than building it from source, but I
don't see it as a mayor problem myself.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 09/12/2012 19:59, Greg KH wrote:
>> The UEFI spec does not allow that mode of operation in secure boot mode,
>> sorry. You will have to disable it in order to boot a Gentoo image,
>> which is fine, but there's no reason why Gentoo can't use the MS-signed
>> shim bootloader like all other distros are using, right?

I thought I had read something in Google+ posted by somebody who
mentioned that their firmware was doing exactly that.  It may very
well be prohibited by the spec though, in which case we shouldn't
count on it.

>
> I wouldn't say we have any problem with that. Fabio already got Sabayon
> to support the shim. The only problem is that we'd have to provide a
> shim binary that _is_ signed, rather than building it from source, but I
> don't see it as a mayor problem myself.

Agreed.  We don't need to make our own shim either - we can just use
one of the ones floating around.  It should be open source, though
obviously if anybody wants to build their own they'll need to get MS
to sign it, or install the key in their firmware.

I really would like Gentoo to support a self-signed secure boot
framework (obviously this would be for after the system is installed).
 The shim might work, but I'd hardly call it "secure boot" if every
motherboard manufacturer and OEM in the world has the ability to sign
things, even if MS vouched for them all.  Even if I installed Windows
I'd want the ability to re-sign it with a key I controlled and tell
the firmware to refuse to boot the MS key.

But, we can learn to walk before we learn to run - anything that works
with UEFI is a good first step.

Oh, and for anybody who is really daring - you can have that kind of
security even without UEFI.  Just use Trusted Grub and enable TPM
support in Linux, and then encrypt all but the boot partition with a
key stored in the TPM that it only yields when the boot path is
validated.  Probably wouldn't hurt to stick a copy of the key on a
flash drive or something just in case you update your kernel and
forget to update the TPM.

Rich

Re: [gentoo-dev] borked release media

[Diego Elio Pettenò]

On 10/12/2012 01:52, Rich Freeman wrote:
>  The shim might work, but I'd hardly call it "secure boot" if every
> motherboard manufacturer and OEM in the world has the ability to sign
> things, even if MS vouched for them all.  Even if I installed Windows
> I'd want the ability to re-sign it with a key I controlled and tell
> the firmware to refuse to boot the MS key.

I don't think it's Gentoo's place to do that kind of stuff especially
since I think you're in dreamland if you think that's achievable in
_every_ case. It probably works in some cases, though.

> Oh, and for anybody who is really daring - you can have that kind of
> security even without UEFI.  Just use Trusted Grub and enable TPM
> support in Linux, and then encrypt all but the boot partition with a
> key stored in the TPM that it only yields when the boot path is
> validated.

From the comments I read from Matthew Garrett, this looks like it's
going to be a world full of pain. Again I don't think we have to go there.

Also the title of the threads is now completely misleading so let's stop
here, k?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] borked release media

[Peter Stuge]

Chí-Thanh Christopher Nguyễn wrote:
> >> # isohybrid image.ISO
> > 
> > Please send a patch to the gentoo-catalyst@ list which adds this as
> > an optional step in the catalyst livecd2 target in a nice way, and
> > file a bug with updated ebuilds for catalyst which add the dependency.
> 
> Bug was already reported some time ago
> https://bugs.gentoo.org/show_bug.cgi?id=251719

That bug doesn't complete the more important action item. It's nice
that the isolinux cdtars include isohybrid, but please do patch
livecd2 in a nice way to also use it. (Note, I don't know what would
be nice, I haven't used catalyst for livecds.)


//Peter

Re: [gentoo-dev] borked release media

[Rich Freeman]

On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 10/12/2012 01:52, Rich Freeman wrote:
>>  The shim might work, but I'd hardly call it "secure boot" if every
>> motherboard manufacturer and OEM in the world has the ability to sign
>> things, even if MS vouched for them all.  Even if I installed Windows
>> I'd want the ability to re-sign it with a key I controlled and tell
>> the firmware to refuse to boot the MS key.
>
> I don't think it's Gentoo's place to do that kind of stuff especially
> since I think you're in dreamland if you think that's achievable in
> _every_ case. It probably works in some cases, though.

Any Windows-logo-compliant firmware has to support changing the keys.
I have no idea whether Windows itself supports this, but that really
isn't our concern.  In any case, nobody is forcing anybody to build in
that support - I just think it is a good idea.  I doubt it would be
difficult to accomplish - it just requires signing the bootloader.
But, if nobody wants to do it now I'll just deal with it when I buy
something with UEFI firmware in a year or two.  :)

>
>> Oh, and for anybody who is really daring - you can have that kind of
>> security even without UEFI.  Just use Trusted Grub and enable TPM
>> support in Linux, and then encrypt all but the boot partition with a
>> key stored in the TPM that it only yields when the boot path is
>> validated.
>
> From the comments I read from Matthew Garrett, this looks like it's
> going to be a world full of pain. Again I don't think we have to go there.

Wasn't really suggesting that we go there - only that anybody who
wants to do it is welcome to do so.  There are even howtos floating
around.  I wasn't suggesting that Gentoo support TPM-based full-disk
encryption - just UEFI.

Rich

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 01:24:53AM +0100, Diego Elio Pettenò wrote:
> On 09/12/2012 19:59, Greg KH wrote:
> > The UEFI spec does not allow that mode of operation in secure boot mode,
> > sorry. You will have to disable it in order to boot a Gentoo image,
> > which is fine, but there's no reason why Gentoo can't use the MS-signed
> > shim bootloader like all other distros are using, right?
> 
> I wouldn't say we have any problem with that. Fabio already got Sabayon
> to support the shim. The only problem is that we'd have to provide a
> shim binary that _is_ signed, rather than building it from source, but I
> don't see it as a mayor problem myself.

I see the shim is checked into Sabayon, with my recent testing on real
hardware, I think there's a bug in the existing shim binary that will
keep it from working on most hardware, so it will need to be updated.

Some of us are currently working with Microsoft to do that right now...

But, if you have access to UEFI secure boot hardware, please test, it
might work for you and if so, please let us know.

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 07:52:16PM -0500, Rich Freeman wrote:
> On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò
> <flameeyes@flameeyes.eu> wrote:
> > On 09/12/2012 19:59, Greg KH wrote:
> >> The UEFI spec does not allow that mode of operation in secure boot mode,
> >> sorry. You will have to disable it in order to boot a Gentoo image,
> >> which is fine, but there's no reason why Gentoo can't use the MS-signed
> >> shim bootloader like all other distros are using, right?
> 
> I thought I had read something in Google+ posted by somebody who
> mentioned that their firmware was doing exactly that.  It may very
> well be prohibited by the spec though, in which case we shouldn't
> count on it.

I have not seen that at all, any pointers?  Based on my interactions
with the UEFI group, and Microsoft, that's either a bug that will be
fixed up, or some misinformation.

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 08:08:01PM -0500, Rich Freeman wrote:
> On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò
> <flameeyes@flameeyes.eu> wrote:
> > On 10/12/2012 01:52, Rich Freeman wrote:
> >>  The shim might work, but I'd hardly call it "secure boot" if every
> >> motherboard manufacturer and OEM in the world has the ability to sign
> >> things, even if MS vouched for them all.  Even if I installed Windows
> >> I'd want the ability to re-sign it with a key I controlled and tell
> >> the firmware to refuse to boot the MS key.
> >
> > I don't think it's Gentoo's place to do that kind of stuff especially
> > since I think you're in dreamland if you think that's achievable in
> > _every_ case. It probably works in some cases, though.
> 
> Any Windows-logo-compliant firmware has to support changing the keys.

Not necessarily, as I'm finding out with real hardware.  My only options
on the box I have is to either zero out all keys, or specifically tell
the BIOS what binary to run (doesn't need to be signed, and can not be
changed after telling the BIOS to use it.)

I'm working with others to see if we can programatically add keys,
which we should, and if so we will offer the code up to do so (it's
published already, we are working on getting it signed by the needed
Microsoft keys right now.)

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
> >> No, all we need is to enable EFI stub support in the kernel, and
> >> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
> >> some location where UEFI looks for it (/efi/boot/bootx64.efi).
> >>
> >> This has the disadvantage of not allowing to pass additional kernel
> >> parameters during boot. But it might still be an acceptable stopgap
> >> measure if the alternative is to not boot at all.
> > 
> > No, don't do that for an "install" kernel, that way is madness, just use
> > a real UEFI bootloader which can handle an initrd and the like properly
> 
> Can you explain what problems you see with that? How does
> CONFIG_INITRAMFS_SOURCE handle initrd improperly?

Ah, didn't notice that, it might work, have you tried it?

greg k-h

Re: [gentoo-dev] borked release media

[Chí-Thanh Christopher Nguyễn]

Greg KH schrieb:
> On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote:
>> Greg KH schrieb:
>>>> No, all we need is to enable EFI stub support in the kernel, and
>>>> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
>>>> some location where UEFI looks for it (/efi/boot/bootx64.efi).
>>>>
>>>> This has the disadvantage of not allowing to pass additional kernel
>>>> parameters during boot. But it might still be an acceptable stopgap
>>>> measure if the alternative is to not boot at all.
>>> No, don't do that for an "install" kernel, that way is madness, just use
>>> a real UEFI bootloader which can handle an initrd and the like properly
>> Can you explain what problems you see with that? How does
>> CONFIG_INITRAMFS_SOURCE handle initrd improperly?
> Ah, didn't notice that, it might work, have you tried it?

Yes, it works here.
This is the kernel which I used to boot my development box at work
(including genkernel initramfs for mdraid+luks+lvm):
http://dev.gentoo.org/~chithanh/efi/boot/bootx64.efi

It has hardcoded crypt_root and real_root via CONFIG_CMDLINE, and
initramfs executables are built with -march=bdver2 so this particular
file will probably not be useful to many people.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] borked release media

[Maxim Kammerer]

On Mon, Dec 10, 2012 at 2:52 AM, Rich Freeman <rich0@gentoo.org> wrote:
> I really would like Gentoo to support a self-signed secure boot
> framework (obviously this would be for after the system is installed).

https://bugs.gentoo.org/show_bug.cgi?id=444830

You can see how such framework works by booting Liberté Linux 2012.3
on a machine with Secure Boot. Just extract the .zip file into USB key
root (or burn the .iso to CD), and import
EFI/Liberte-SecureBoot-CA.der certificate in UEFI Secure Boot
interface: http://dee.su/liberte-install (see “Secure Boot” section).

> The shim might work, but I'd hardly call it "secure boot" if every
> motherboard manufacturer and OEM in the world has the ability to sign
> things, even if MS vouched for them all.

I think there are some popular misunderstanding about the purpose of
shim. What shim essentially allows a user to do is to enroll custom
certificates into Secure Boot databases in an interactive,
user-friendly fashion (caveat emptor: I didn't try shim yet). It does
some clever UEFI API interaction and management of certificates in
protected variables, but the effect is identical to enrolling a
certificate into DB or KEK (OVMF names) via UEFI interface. Being
signed by MS is just a technical way to achieve that user
friendliness. So personally, I don't think that rushing to support
shim in Gentoo is that critical, since users can be expected to enroll
certificates by themselves.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] borked release media

[Walter Dnes]

On Sat, Dec 08, 2012 at 11:57:13PM -0500, Fernando Reyes wrote
> iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. 
> 
> # isohybrid image.ISO
> # did if=image.ISO of=/dev/sdb bs=8192k
> 
> sdb being your removable device. Also keep in mind that any data on
> sdb will be wiped after running the dd command.

  Thanks.  Much easier than the instructions on the Gentoo wiki.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] borked release media

[Walter Dnes]

On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote

> Not necessarily, as I'm finding out with real hardware.  My only options
> on the box I have is to either zero out all keys, or specifically tell
> the BIOS what binary to run (doesn't need to be signed, and can not be
> changed after telling the BIOS to use it.)

  Howsabout the binary being Matthew Garret's chainloader shim as per
http://mjg59.dreamwidth.org/20303.html

> I'm working with others to see if we can programatically add keys,
> which we should, and if so we will offer the code up to do so (it's
> published already, we are working on getting it signed by the needed
> Microsoft keys right now.)

  He's already done the heavy lifting.  Aren't you re-inventing the
wheel?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 10:31:25AM -0500, Walter Dnes wrote:
> On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote
> 
> > Not necessarily, as I'm finding out with real hardware.  My only options
> > on the box I have is to either zero out all keys, or specifically tell
> > the BIOS what binary to run (doesn't need to be signed, and can not be
> > changed after telling the BIOS to use it.)
> 
>   Howsabout the binary being Matthew Garret's chainloader shim as per
> http://mjg59.dreamwidth.org/20303.html

That's a nice one, but note my previous comment about a bug in it at the
moment that prevents it from working on some hardware.  It's also a
valid solution for some implementations, have you tried it yourself?

> > I'm working with others to see if we can programatically add keys,
> > which we should, and if so we will offer the code up to do so (it's
> > published already, we are working on getting it signed by the needed
> > Microsoft keys right now.)
> 
>   He's already done the heavy lifting.  Aren't you re-inventing the
> wheel?

Not at all, we are sharing the same code base here, just two different
frontend implementations that do different things, with the same crypto
backend and local (MOK) key checking functionality, which was done by
SUSE.

Matthew's frontend "shim" code is nice and tiny, but the one I am
referring to provides the ability to enroll your own keys in the BIOS,
which shim does not.

Don't worry, we are all working together here, it's not like there is a
ton of people involved :)

greg "there is no cabal" k-h

Re: [gentoo-dev] borked release media

[Maxim Kammerer]

On Mon, Dec 10, 2012 at 8:36 PM, Greg KH <gregkh@gentoo.org> wrote:
> Matthew's frontend "shim" code is nice and tiny, but the one I am
> referring to provides the ability to enroll your own keys in the BIOS,
> which shim does not.

I just tried shim in OVMF, and it provides an interface to enroll keys
/ signatures. It works as advertised, even after enrolling “Microsoft
Corporation UEFI CA 2011” certificate into UEFI (instead of shim.efi
hash), which is supposedly trusted by vendors, but the keys and
signatures are only visible to shim — as I understand, it keeps them
in authenticated variables. I don't think the difference matters much
to the user. By the way, shim's interface is not much prettier than
the one provided by OVMF — I am a bit disappointed. :)

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte