Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Sun, Dec 6, 2015 at 7:05 AM, drago01  wrote:
> On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski  wrote:
>> Since the old proposal to have the bootloader automatically enumerate
>> boot options never went anywhere, can we do the next best thing?
>>
>> Specifically, these days grub2-mkconfig appears to produce output
>> that's functionally identical to what grubby generates.  Can we switch
>> new-kernel-pkg to just regenerate the grub2 config using
>> grub2-mkconfig instead of using grubby?
>>
>> Debian has worked like this forever, and IMO it's superior in pretty
>> much all respects.  There are already nice config hooks for making
>> custom changes, and they're a lot more reliable than trusting grubby
>> to do what you expect it to do.
>
> Well mkconfig can produce a configuration that does not actually work
> when grub2 itself gets updated (in which case the bootloader does not
> get rewritten).
> Until this is fixed grub2-mkconfig is dangerous and should not be used.

I have never seen this happen on any distro.  In any event, even if
there's a case in which mkconfig screws up, Fedora is unlikely to be
able to install in the first place.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[drago01]

On Sun, Dec 6, 2015 at 6:20 PM, Andrew Lutomirski  wrote:
> On Sun, Dec 6, 2015 at 7:05 AM, drago01  wrote:
>> On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski  wrote:
>>> Since the old proposal to have the bootloader automatically enumerate
>>> boot options never went anywhere, can we do the next best thing?
>>>
>>> Specifically, these days grub2-mkconfig appears to produce output
>>> that's functionally identical to what grubby generates.  Can we switch
>>> new-kernel-pkg to just regenerate the grub2 config using
>>> grub2-mkconfig instead of using grubby?
>>>
>>> Debian has worked like this forever, and IMO it's superior in pretty
>>> much all respects.  There are already nice config hooks for making
>>> custom changes, and they're a lot more reliable than trusting grubby
>>> to do what you expect it to do.
>>
>> Well mkconfig can produce a configuration that does not actually work
>> when grub2 itself gets updated (in which case the bootloader does not
>> get rewritten).
>> Until this is fixed grub2-mkconfig is dangerous and should not be used.
>
> I have never seen this happen on any distro.  In any event, even if
> there's a case in which mkconfig screws up, Fedora is unlikely to be
> able to install in the first place.

No that has nothing to do with the installation process.

The events are:

1) You install Fedora -- grub2-mkconfig creates a config that matches
the bootloader
2) The grub package gets updated / upgraded --- grub2-mkconfig is no
longer guaranted to generate a config file that works with the grub
that is actually installed (i.e you'd have to rerun grub2-install to
be sure).

Yes in most of the cases that works but it is fragile and therefore
dangerous to do that by default.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[drago01]

On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski  wrote:
> Since the old proposal to have the bootloader automatically enumerate
> boot options never went anywhere, can we do the next best thing?
>
> Specifically, these days grub2-mkconfig appears to produce output
> that's functionally identical to what grubby generates.  Can we switch
> new-kernel-pkg to just regenerate the grub2 config using
> grub2-mkconfig instead of using grubby?
>
> Debian has worked like this forever, and IMO it's superior in pretty
> much all respects.  There are already nice config hooks for making
> custom changes, and they're a lot more reliable than trusting grubby
> to do what you expect it to do.

Well mkconfig can produce a configuration that does not actually work
when grub2 itself gets updated (in which case the bootloader does not
get rewritten).
Until this is fixed grub2-mkconfig is dangerous and should not be used.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Tomasz Torcz]

On Sun, Dec 06, 2015 at 06:25:09PM +0100, drago01 wrote:
> >> Well mkconfig can produce a configuration that does not actually work
> >> when grub2 itself gets updated (in which case the bootloader does not
> >> get rewritten).
> >> Until this is fixed grub2-mkconfig is dangerous and should not be used.
> >
> > I have never seen this happen on any distro.  In any event, even if
> > there's a case in which mkconfig screws up, Fedora is unlikely to be
> > able to install in the first place.
> 
> No that has nothing to do with the installation process.
> 
> The events are:
> 
> 1) You install Fedora -- grub2-mkconfig creates a config that matches
> the bootloader
> 2) The grub package gets updated / upgraded --- grub2-mkconfig is no
> longer guaranted to generate a config file that works with the grub
> that is actually installed (i.e you'd have to rerun grub2-install to
> be sure).
> 
> Yes in most of the cases that works but it is fragile and therefore
> dangerous to do that by default.

  Can you list specific cases?  It sounds awfully theoretical.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Chris Murphy]

On Sun, Dec 6, 2015 at 8:05 AM, drago01  wrote:
> On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski  wrote:
>> Since the old proposal to have the bootloader automatically enumerate
>> boot options never went anywhere, can we do the next best thing?
>>
>> Specifically, these days grub2-mkconfig appears to produce output
>> that's functionally identical to what grubby generates.  Can we switch
>> new-kernel-pkg to just regenerate the grub2 config using
>> grub2-mkconfig instead of using grubby?
>>
>> Debian has worked like this forever, and IMO it's superior in pretty
>> much all respects.  There are already nice config hooks for making
>> custom changes, and they're a lot more reliable than trusting grubby
>> to do what you expect it to do.
>
> Well mkconfig can produce a configuration that does not actually work
> when grub2 itself gets updated (in which case the bootloader does not
> get rewritten).

Hypothetically on BIOS systems, a GRUB core.img [1] could become stale
over time, and an upgraded grub-mkconfig could introduce an
incompatible format change, but that's really unlikely and wouldn't be
intentional.

This isn't possible on UEFI. Any update of grub2-efi means the
core.img is replaced with a generically built one (that's also signed
by a Fedora key for the purposes of supporting UEFI Secure Boot).

> Until this is fixed grub2-mkconfig is dangerous and should not be used.

That's such an overstatement as to be wrong. Pretty much all other
distributions have been doing this for a long time to no ill effect.

On a BIOS computer, a Fedora upgrade (fedup or
dnf-plugin-system-upgrade) will lack generation of a new core.img,
where a new installation will have a new core.img (and new grub.cfg).
So there's a risk of problems due to core.img becoming increasingly
stale with successful upgrades rather than reinstalls. But since
grubby is responsible for modifying rather than replacing grub.cfg
with grub-mkconfig, it's probably less of a concern than the lack of
bug and security fixes going into the core.img.

[1] The code embedded into the MBR gap, or BIOSBoot partition; a.k.a.
GRUB legacy terminology was stage 2 bootloader. It's created and
embedded by the grub2-install command; which is unnecessary (and
arguably deprecated) on UEFI systems.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Chris Murphy]

On Sun, Dec 6, 2015 at 12:11 PM, drago01  wrote:
> On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz  wrote:

>>   Can you list specific cases?  It sounds awfully theoretical.
>
> I got bitten by it before so its not theoretical ... unfortunately I
> do not remember the exact versions.

I'm willing to bet it happened during the GRUB 2 beta era, when Fedora
carried multiple works-in-progress of GRUB 1.9x where the grub.cfg
format was in flux, and grubby also had some problems dealing with
those changes. It's also possible it happened when Fedora's GRUB
introduced linuxefi/initrdefi and linux16/initrd16 which GRUB upstream
don't have; so your core.img didn't understand those commands while
the grub2-mkconfig produced grub.cfg would have.

So yeah it's possible, but it's also unintended. And the same problem
could happen whether grubby modifies grub.cfg or grub-mkconfig
replaces it.

The way this works on UEFI obviates the problem by always replacing
grubx64.efi (which contains core.img) anytime the grub2 package is
updated. There's no equivalent to this on BIOS computers that won't
piss off some significant(ly vocal) minority, but there's still a sane
argument for the default behavior rewriting core.img anytime the grub
package is updated: and the start of that argument is that
reinstalling the bootloader manually is esoteric, and users shouldn't
have to know such esoteric things to get their computer to boot or be
secure. The reality is that anyone multibooting has to have ninjitsu
level bootloader knowledge anyway, so I'd burden those people with
managing exceptions rather than single boot users (or even dual boot
Fedora+OSX or Fedora+Windows).

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 06.12.2015 um 21:06 schrieb Chris Murphy:

On Sun, Dec 6, 2015 at 8:05 AM, drago01  wrote:
Hypothetically on BIOS systems, a GRUB core.img [1] could become stale
over time, and an upgraded grub-mkconfig could introduce an
incompatible format change, but that's really unlikely and wouldn't be
intentional.

This isn't possible on UEFI. Any update of grub2-efi means the
core.img is replaced with a generically built one (that's also signed
by a Fedora key for the purposes of supporting UEFI Secure Boot).


the world don't turn around UEFI


Until this is fixed grub2-mkconfig is dangerous and should not be used.


That's such an overstatement as to be wrong. Pretty much all other
distributions have been doing this for a long time to no ill effect.


he told you he was personally affected


[1] The code embedded into the MBR gap, or BIOSBoot partition; a.k.a.
GRUB legacy terminology was stage 2 bootloader. It's created and
embedded by the grub2-install command; which is unnecessary (and
arguably deprecated) on UEFI systems.


and you are going to change existing systems running for many years and 
surivived all dist-upgrades to UEFI *without* reinstall or lose /boot 
redundancy by RAID1? grub2-install needs to be manually done on all 4 
drives


frankly my current workstations where installed with F14 and RAID1 for 
/boot as well as RAID10 for anything else, they support UEFI but i gave 
up with Anaconda, now they happily run Fedora 23 with dist-upgrades and 
will as long some jerk decides to kill BIOS support or i die


the same applies to more than 30 production servers installed with 
Fedora 9 years ago and currentyl on F22 on top of VMware - fine, Vmware 
now supports UEFI too - but tell me *one valid* reason to change them!




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 06.12.2015 um 21:22 schrieb Chris Murphy:

So yeah it's possible, but it's also unintended. And the same problem
could happen whether grubby modifies grub.cfg or grub-mkconfig
replaces it


that's wrong because grubby *clones* the last recent entry with all it's 
parameters and don't touch other boot entrie snor the rest of the 
configuration




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[drago01]

On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz  wrote:
> On Sun, Dec 06, 2015 at 06:25:09PM +0100, drago01 wrote:
>> >> Well mkconfig can produce a configuration that does not actually work
>> >> when grub2 itself gets updated (in which case the bootloader does not
>> >> get rewritten).
>> >> Until this is fixed grub2-mkconfig is dangerous and should not be used.
>> >
>> > I have never seen this happen on any distro.  In any event, even if
>> > there's a case in which mkconfig screws up, Fedora is unlikely to be
>> > able to install in the first place.
>>
>> No that has nothing to do with the installation process.
>>
>> The events are:
>>
>> 1) You install Fedora -- grub2-mkconfig creates a config that matches
>> the bootloader
>> 2) The grub package gets updated / upgraded --- grub2-mkconfig is no
>> longer guaranted to generate a config file that works with the grub
>> that is actually installed (i.e you'd have to rerun grub2-install to
>> be sure).
>>
>> Yes in most of the cases that works but it is fragile and therefore
>> dangerous to do that by default.
>
>   Can you list specific cases?  It sounds awfully theoretical.

I got bitten by it before so its not theoretical ... unfortunately I
do not remember the exact versions.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Kevin Kofler]

Andrew Lutomirski wrote:
> 2 .If I want to edit boot options, grubby makes it unnecessarily
> painful, and the directions are simply wrong.  For example, my
> /etc/grub2-efi.cfg says:
> 
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub2-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
> 
> That's grossly misleading.  It *was* automatically generated, but it
> is certainly not automatically generated on an ongoing basis.  If I
> change settings in /etc/default/grub, nothing happens.  If I actually
> want to change boot options, I have to either manually edit every
> instance (or somehow, magically, the correct subset of copies) in
> /etc/grub2-efi.cfg, which is a real pain and easy to screw up.  Or I
> can cross my fingers any try to figure out the right invocation to
> just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
> presumably).  Assuming that such an incantation exists (which it does
> these days!), one wonders why it's not happening automatically on
> kernel upgrades.

There are several issues with the current approach:
* Our approach to updating grub.cfg differs from the approach recommended
  and documented by upstream.
* As you pointed out, even the documentation IN the file we ship
  misleadingly documents the upstream approach and not the one we are
  actually using. (At least that part would be easily fixable though, by
  patching the boilerplate grub.cfg header in grub2-mkconfig.)
* Any third-party configuration tools such as kcm_grub2 expect the upstream
  mechanisms, because we are pretty much the only distro that bypasses them.
  Thus, they WILL rerun grub2-mkconfig, and any changes you or grubby
  manually made to the file will be overwritten.

Now our approach does have the advantage that you have more detailed control 
over the contents of the file than with grub2-mkconfig (though you have to 
be careful not to confuse grubby). I am torn as to whether this is enough 
justification for continuing to ignore upstream's recommended configuration 
system.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Dec 2, 2015 8:15 AM, "Josh Boyer"  wrote:
>
> On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski  wrote:
> > Since the old proposal to have the bootloader automatically enumerate
> > boot options never went anywhere, can we do the next best thing?
> >
> > Specifically, these days grub2-mkconfig appears to produce output
> > that's functionally identical to what grubby generates.  Can we switch
> > new-kernel-pkg to just regenerate the grub2 config using
> > grub2-mkconfig instead of using grubby?
>
> I don't think so.  Despite the similarity in name, grubby does more
> than just deal with grub stuff.  Namely, it handles bootloaders that
> aren't grub.  We're close to having all arches on grub2, but I believe
> armv7hl won't ever get there and it's a primary arch.

Could we switch for grub2 architectures and keep using grubby for other
architectures?

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Peter Robinson]

On Wed, Dec 2, 2015 at 4:14 PM, Josh Boyer  wrote:
> On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski  wrote:
>> Since the old proposal to have the bootloader automatically enumerate
>> boot options never went anywhere, can we do the next best thing?
>>
>> Specifically, these days grub2-mkconfig appears to produce output
>> that's functionally identical to what grubby generates.  Can we switch
>> new-kernel-pkg to just regenerate the grub2 config using
>> grub2-mkconfig instead of using grubby?
>
> I don't think so.  Despite the similarity in name, grubby does more
> than just deal with grub stuff.  Namely, it handles bootloaders that
> aren't grub.  We're close to having all arches on grub2, but I believe
> armv7hl won't ever get there and it's a primary arch.

Correct, I also believe there's plans to move the cloud images back to
syslinux. Both ARMv7 and at least some of the cloud images use
exlinux.conf. I believe pjones was developing a new version of grubby
or a replacement to it.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:


On Dec 2, 2015 8:15 AM, "Josh Boyer" > wrote:
 >
 > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski > wrote:
 > > Since the old proposal to have the bootloader automatically enumerate
 > > boot options never went anywhere, can we do the next best thing?
 > >
 > > Specifically, these days grub2-mkconfig appears to produce output
 > > that's functionally identical to what grubby generates.  Can we switch
 > > new-kernel-pkg to just regenerate the grub2 config using
 > > grub2-mkconfig instead of using grubby?
 >
 > I don't think so.  Despite the similarity in name, grubby does more
 > than just deal with grub stuff.  Namely, it handles bootloaders that
 > aren't grub.  We're close to having all arches on grub2, but I believe
 > armv7hl won't ever get there and it's a primary arch.

Could we switch for grub2 architectures and keep using grubby for other
architectures?


no - there is a world without grub2
https://fedoraproject.org/wiki/Features/SyslinuxOption




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Josh Boyer]

On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski  wrote:
> Since the old proposal to have the bootloader automatically enumerate
> boot options never went anywhere, can we do the next best thing?
>
> Specifically, these days grub2-mkconfig appears to produce output
> that's functionally identical to what grubby generates.  Can we switch
> new-kernel-pkg to just regenerate the grub2 config using
> grub2-mkconfig instead of using grubby?

I don't think so.  Despite the similarity in name, grubby does more
than just deal with grub stuff.  Namely, it handles bootloaders that
aren't grub.  We're close to having all arches on grub2, but I believe
armv7hl won't ever get there and it's a primary arch.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Colin Walters]

On Tue, Dec 1, 2015, at 10:30 PM, Andrew Lutomirski wrote:
> Since the old proposal to have the bootloader automatically enumerate
> boot options never went anywhere, can we do the next best thing?
> 
> Specifically, these days grub2-mkconfig appears to produce output
> that's functionally identical to what grubby generates.  Can we switch
> new-kernel-pkg to just regenerate the grub2 config using
> grub2-mkconfig instead of using grubby.

Note this is what ostree (as used by Fedora Atomic Host) does.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Dec 2, 2015 8:38 AM, "Reindl Harald"  wrote:
>
>
>
> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:
>>
>>
>> On Dec 2, 2015 8:15 AM, "Josh Boyer" > > wrote:
>>  >
>>  > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski > > wrote:
>>  > > Since the old proposal to have the bootloader automatically
enumerate
>>  > > boot options never went anywhere, can we do the next best thing?
>>  > >
>>  > > Specifically, these days grub2-mkconfig appears to produce output
>>  > > that's functionally identical to what grubby generates.  Can we
switch
>>  > > new-kernel-pkg to just regenerate the grub2 config using
>>  > > grub2-mkconfig instead of using grubby?
>>  >
>>  > I don't think so.  Despite the similarity in name, grubby does more
>>  > than just deal with grub stuff.  Namely, it handles bootloaders that
>>  > aren't grub.  We're close to having all arches on grub2, but I believe
>>  > armv7hl won't ever get there and it's a primary arch.
>>
>> Could we switch for grub2 architectures and keep using grubby for other
>> architectures?
>
>
> no - there is a world without grub2
> https://fedoraproject.org/wiki/Features/SyslinuxOption

Then let's make the same change across all bootloaders.  For grub2, use
grub2-mkconfig.  For syslinux, use whatever Anaconda uses to generate the
config in the first place.

Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
also like to see grubby go away.

--Andy

>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Josh Boyer]

On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski  wrote:
>
> On Dec 2, 2015 8:38 AM, "Reindl Harald"  wrote:
>>
>>
>>
>> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:
>>>
>>>
>>> On Dec 2, 2015 8:15 AM, "Josh Boyer" >> > wrote:
>>>  >
>>>  > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski >> > wrote:
>>>  > > Since the old proposal to have the bootloader automatically
>>> enumerate
>>>  > > boot options never went anywhere, can we do the next best thing?
>>>  > >
>>>  > > Specifically, these days grub2-mkconfig appears to produce output
>>>  > > that's functionally identical to what grubby generates.  Can we
>>> switch
>>>  > > new-kernel-pkg to just regenerate the grub2 config using
>>>  > > grub2-mkconfig instead of using grubby?
>>>  >
>>>  > I don't think so.  Despite the similarity in name, grubby does more
>>>  > than just deal with grub stuff.  Namely, it handles bootloaders that
>>>  > aren't grub.  We're close to having all arches on grub2, but I believe
>>>  > armv7hl won't ever get there and it's a primary arch.
>>>
>>> Could we switch for grub2 architectures and keep using grubby for other
>>> architectures?
>>
>>
>> no - there is a world without grub2
>> https://fedoraproject.org/wiki/Features/SyslinuxOption
>
> Then let's make the same change across all bootloaders.  For grub2, use
> grub2-mkconfig.  For syslinux, use whatever Anaconda uses to generate the
> config in the first place.

And you would do that via a single command how?  By wrapping it in an
architecture/bootloader agnostic wrapper.  Which is what grubby is.

> Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
> also like to see grubby go away.

Maybe you could start by listing the problems you have with grubby
(and apparently grub2) instead of just saying get rid of it?

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Neal Gompa]

On Wed, Dec 2, 2015 at 12:50 PM, Josh Boyer 
wrote:

> On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski  wrote:
> >
> > On Dec 2, 2015 8:38 AM, "Reindl Harald"  wrote:
> >>
> >>
> >>
> >> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:
> >>>
> >>>
> >>> On Dec 2, 2015 8:15 AM, "Josh Boyer"  >>> > wrote:
> >>>  >
> >>>  > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski  >>> > wrote:
> >>>  > > Since the old proposal to have the bootloader automatically
> >>> enumerate
> >>>  > > boot options never went anywhere, can we do the next best thing?
> >>>  > >
> >>>  > > Specifically, these days grub2-mkconfig appears to produce output
> >>>  > > that's functionally identical to what grubby generates.  Can we
> >>> switch
> >>>  > > new-kernel-pkg to just regenerate the grub2 config using
> >>>  > > grub2-mkconfig instead of using grubby?
> >>>  >
> >>>  > I don't think so.  Despite the similarity in name, grubby does more
> >>>  > than just deal with grub stuff.  Namely, it handles bootloaders that
> >>>  > aren't grub.  We're close to having all arches on grub2, but I
> believe
> >>>  > armv7hl won't ever get there and it's a primary arch.
> >>>
> >>> Could we switch for grub2 architectures and keep using grubby for other
> >>> architectures?
> >>
> >>
> >> no - there is a world without grub2
> >> https://fedoraproject.org/wiki/Features/SyslinuxOption
> >
> > Then let's make the same change across all bootloaders.  For grub2, use
> > grub2-mkconfig.  For syslinux, use whatever Anaconda uses to generate the
> > config in the first place.
>
> And you would do that via a single command how?  By wrapping it in an
> architecture/bootloader agnostic wrapper.  Which is what grubby is.
>
> > Frankly, I'd like to see Fedora move away from grub2 even on x86.  But
> I'd
> > also like to see grubby go away.
>
> Maybe you could start by listing the problems you have with grubby
> (and apparently grub2) instead of just saying get rid of it?
>
> josh


​My big pain point right now is that we can't have /boot be a subvolume on
btrfs and boot properly.

GRUB2 and ExtLinux both support booting from btrfs just fine, but we don't
seem to support it for some reason?

I can't recall the issue off the top of my head, but I *think* the issue
was related to grubby. Perhaps using grub2-mkconfig would fix this?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:31 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 12:21 PM, Reindl Harald  wrote:



Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:


On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer 
wrote:


That's a matter of preference.  If I have a newer kernel version
installed that doesn't actually work, I want the older kernel I _just_
installed to be the default and top entry so my machine boots to
something I can use.  This happens often when people try rawhide -rcX
kernels to test something.

Fixing this might be better served by filing an RFE for grubby to
change the preference order.



Or file an RFE for grub2 to have an option to use the file timestamps
instead of the version for the sort order



breaking news: file timestamps of packages are independent of the install
time so this can't work - any attributes like timestamp, owner, permision
are part of the package for good reasons (rkhunter as example compares them
with the rpm database)


Can you please try to reduce your level of sarcasm on the list?


i try, but sometimes it's obviously needed


It's especially irritating when you're simultaneously sarcastic and
factually incorrect:


no, i am 100% correct in that context or why does my kernel have a 
timestamp from yesterday but was updated today?


[root@rawhide ~]# cat /var/log/dnf.rpm.log | grep kernel | grep 
4.4.0-0.rc3.git1.1

Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64
Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64

[root@rawhide ~]# ls -lha /boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64
-rwxr-xr-x 1 root root 6.4M 2015-12-01 17:34 
/boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Josh Boyer]

On Wed, Dec 2, 2015 at 2:35 PM, Andrew Lutomirski  wrote:
> On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  wrote:
>> On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski  wrote:
>>>
>>> On Dec 2, 2015 8:38 AM, "Reindl Harald"  wrote:



 Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:
>
>
> On Dec 2, 2015 8:15 AM, "Josh Boyer"  > wrote:
>  >
>  > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski  > wrote:
>  > > Since the old proposal to have the bootloader automatically
> enumerate
>  > > boot options never went anywhere, can we do the next best thing?
>  > >
>  > > Specifically, these days grub2-mkconfig appears to produce output
>  > > that's functionally identical to what grubby generates.  Can we
> switch
>  > > new-kernel-pkg to just regenerate the grub2 config using
>  > > grub2-mkconfig instead of using grubby?
>  >
>  > I don't think so.  Despite the similarity in name, grubby does more
>  > than just deal with grub stuff.  Namely, it handles bootloaders that
>  > aren't grub.  We're close to having all arches on grub2, but I believe
>  > armv7hl won't ever get there and it's a primary arch.
>
> Could we switch for grub2 architectures and keep using grubby for other
> architectures?


 no - there is a world without grub2
 https://fedoraproject.org/wiki/Features/SyslinuxOption
>>>
>>> Then let's make the same change across all bootloaders.  For grub2, use
>>> grub2-mkconfig.  For syslinux, use whatever Anaconda uses to generate the
>>> config in the first place.
>>
>> And you would do that via a single command how?  By wrapping it in an
>> architecture/bootloader agnostic wrapper.  Which is what grubby is.
>
> But it's not.  grubby does things like adding kernels and removing
> kernels.  grub2-mkconfig enumerates kernels and generates a config.

Hm.  Wait.  I think there might be a terminology conflict here.  Are
you specifically referring to grubby the binary, or do you mean grubby
the package?  Because I was talking about the latter, as it contains
new-kernel-pkg, etc.

>>> Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
>>> also like to see grubby go away.
>>
>> Maybe you could start by listing the problems you have with grubby
>> (and apparently grub2) instead of just saying get rid of it?
>
> Fair enough.  Two major problems come to mind:
>
> 1. grubby puts the most recently-installed kernel on top.
> grub2-mkconfig puts the highest version on top.  In the cases where
> they differ, I'd argue that the latter is better.

That's a matter of preference.  If I have a newer kernel version
installed that doesn't actually work, I want the older kernel I _just_
installed to be the default and top entry so my machine boots to
something I can use.  This happens often when people try rawhide -rcX
kernels to test something.

Fixing this might be better served by filing an RFE for grubby to
change the preference order.

> 2 .If I want to edit boot options, grubby makes it unnecessarily
> painful, and the directions are simply wrong.  For example, my
> /etc/grub2-efi.cfg says:
>
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub2-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #

TBH, I just edit /boot/EFI/efi/grub.cfg directly.  It works fine.

> That's grossly misleading.  It *was* automatically generated, but it
> is certainly not automatically generated on an ongoing basis.  If I
> change settings in /etc/default/grub, nothing happens.  If I actually
> want to change boot options, I have to either manually edit every
> instance (or somehow, magically, the correct subset of copies) in
> /etc/grub2-efi.cfg, which is a real pain and easy to screw up.  Or I
> can cross my fingers any try to figure out the right invocation to
> just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
> presumably).  Assuming that such an incantation exists (which it does
> these days!), one wonders why it's not happening automatically on
> kernel upgrades.

How often are you editing the boot options for _all_ installed
kernels?  I'm not questioning what you're saying, but my experience
tends show people edit boot options for a single stanza which isn't
all that arduous.

Also, once edited, any newly installed kernel after that picks up the
added options auto-magically.

> To the extent that I do it wrong and grub2-efi.cfg diverges from that
> which is implied by /etc/default/grub, etc, we have a mess.  This can
> happen due to settings editing and presumably due to other things.

This sounds like a documentation issue?  You're looking at the files
grub2 installs and trying to follow their advice, but the distro
doesn't actually 

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 20:35 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  wrote:

And you would do that via a single command how?  By wrapping it in an
architecture/bootloader agnostic wrapper.  Which is what grubby is.


But it's not.  grubby does things like adding kernels and removing
kernels.  grub2-mkconfig enumerates kernels and generates a config.


and if it has a bug you are lot with *all* entries borked


#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

That's grossly misleading.  It *was* automatically generated, but it
is certainly not automatically generated on an ongoing basis.  If I
change settings in /etc/default/grub, nothing happens.  If I actually
want to change boot options, I have to either manually edit every
instance (or somehow, magically, the correct subset of copies) in
/etc/grub2-efi.cfg, which is a real pain and easy to screw up


no - if you want them all identically just run grub2-mkconfig manually 
but don't expect that i am happy when something put's the same error 
into every entry


https://bugzilla.redhat.com/show_bug.cgi?id=840204 is probably the best 
example - with grubby you where able to add the needed option to the 
most recent entry and survived kernel updates


with grub2-mkconfig *every* single kernel update without edit the config 
before reboot meant go to your car and drive 300 miles to the remote 
machine or explain somebody how to get screen and keyboard on the 
headless machine and hand out the password




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 20:35 schrieb Andrew Lutomirski:

1. grubby puts the most recently-installed kernel on top.
grub2-mkconfig puts the highest version on top.  In the cases where
they differ, I'd argue that the latter is better


it's not better

it's pure crap when you have to downgrade because the higher kernel just 
don't work proper on your machine - there is one and only single reason 
why the most recently is lower - a downgrade by intention




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:

On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer  wrote:

That's a matter of preference.  If I have a newer kernel version
installed that doesn't actually work, I want the older kernel I _just_
installed to be the default and top entry so my machine boots to
something I can use.  This happens often when people try rawhide -rcX
kernels to test something.

Fixing this might be better served by filing an RFE for grubby to
change the preference order.


Or file an RFE for grub2 to have an option to use the file timestamps
instead of the version for the sort order


breaking news: file timestamps of packages are independent of the 
install time so this can't work - any attributes like timestamp, owner, 
permision are part of the package for good reasons (rkhunter as example 
compares them with the rpm database)




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 12:21 PM, Reindl Harald  wrote:
>
>
> Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:
>>
>> On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer 
>> wrote:
>>>
>>> That's a matter of preference.  If I have a newer kernel version
>>> installed that doesn't actually work, I want the older kernel I _just_
>>> installed to be the default and top entry so my machine boots to
>>> something I can use.  This happens often when people try rawhide -rcX
>>> kernels to test something.
>>>
>>> Fixing this might be better served by filing an RFE for grubby to
>>> change the preference order.
>>
>>
>> Or file an RFE for grub2 to have an option to use the file timestamps
>> instead of the version for the sort order
>
>
> breaking news: file timestamps of packages are independent of the install
> time so this can't work - any attributes like timestamp, owner, permision
> are part of the package for good reasons (rkhunter as example compares them
> with the rpm database)

Can you please try to reduce your level of sarcasm on the list?

It's especially irritating when you're simultaneously sarcastic and
factually incorrect:

$ stat /boot/vmlinuz-4.2.6-301.fc23.x86_64
  File: ‘/boot/vmlinuz-4.2.6-301.fc23.x86_64’
  Size: 5980440   Blocks: 11688  IO Block: 4096   regular file
Device: 10302h/66306dInode: 13  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Context: system_u:object_r:modules_object_t:s0
Access: 2015-11-20 14:35:27.0 -0800
Modify: 2015-11-20 14:35:27.0 -0800
Change: 2015-11-29 13:02:59.410471082 -0800

^^
Note the ctime

 Birth: -

For something more reliable, grub2-mkconfig for similar could do something like:

$ rpm -qf /boot/vmlinuz-4.2.6-301.fc2-queryformat '%{installtime}\n'

with some appropriate provision for packages that don't come from RPM
in the first place.

For human readability:

$ rpm -qf /boot/vmlinuz-4.2.6-301.fc23.x86_64 --queryformat
'%{installtime:date}\n'
Sun 29 Nov 2015 01:01:52 PM PST

Note that this is suspiciously similar to ctime above.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 12:37 PM, Reindl Harald  wrote:
>
>
> Am 02.12.2015 um 21:31 schrieb Andrew Lutomirski:
>>
>> On Wed, Dec 2, 2015 at 12:21 PM, Reindl Harald 
>> wrote:
>>>
>>>
>>>
>>> Am 02.12.2015 um 21:16 schrieb Andrew Lutomirski:


 On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer 
 wrote:
>
>
> That's a matter of preference.  If I have a newer kernel version
> installed that doesn't actually work, I want the older kernel I _just_
> installed to be the default and top entry so my machine boots to
> something I can use.  This happens often when people try rawhide -rcX
> kernels to test something.
>
> Fixing this might be better served by filing an RFE for grubby to
> change the preference order.



 Or file an RFE for grub2 to have an option to use the file timestamps
 instead of the version for the sort order
>>>
>>>
>>>
>>> breaking news: file timestamps of packages are independent of the install
>>> time so this can't work - any attributes like timestamp, owner, permision
>>> are part of the package for good reasons (rkhunter as example compares
>>> them
>>> with the rpm database)
>>
>>
>> Can you please try to reduce your level of sarcasm on the list?
>
>
> i try, but sometimes it's obviously needed
>
>> It's especially irritating when you're simultaneously sarcastic and
>> factually incorrect:
>
>
> no, i am 100% correct in that context or why does my kernel have a timestamp
> from yesterday but was updated today?
>
> [root@rawhide ~]# cat /var/log/dnf.rpm.log | grep kernel | grep
> 4.4.0-0.rc3.git1.1
> Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64
> Dec 02 19:55:47 INFO Installed: kernel-core-4.4.0-0.rc3.git1.1.fc24.x86_64
>
> [root@rawhide ~]# ls -lha /boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64
> -rwxr-xr-x 1 root root 6.4M 2015-12-01 17:34
> /boot/vmlinuz-4.4.0-0.rc3.git1.1.fc24.x86_64

You're not 100% correct.  Try ls -lhca.  Note the 'c' in there.  And
maybe try at least searching the manpage for the most obvious keywork
('ctime' in this case) before digging in your heels.  (Or even try the
exact commands I put in my email, which would have lead to much the
same conclusion.)

The fact that you assert your absolute correctness on a frequent basis
even when you're not correct makes me, and probably other people,
likely to discount everything you say even in the cases when you are
correct.  If you want your opinion to be helpful, please reconsider
how you write your emails.

Anyway, I filed an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1287854

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  wrote:
> On Wed, Dec 2, 2015 at 12:09 PM, Andrew Lutomirski  wrote:
>>
>> On Dec 2, 2015 8:38 AM, "Reindl Harald"  wrote:
>>>
>>>
>>>
>>> Am 02.12.2015 um 17:23 schrieb Andrew Lutomirski:


 On Dec 2, 2015 8:15 AM, "Josh Boyer" > wrote:
  >
  > On Tue, Dec 1, 2015 at 10:30 PM, Andrew Lutomirski > wrote:
  > > Since the old proposal to have the bootloader automatically
 enumerate
  > > boot options never went anywhere, can we do the next best thing?
  > >
  > > Specifically, these days grub2-mkconfig appears to produce output
  > > that's functionally identical to what grubby generates.  Can we
 switch
  > > new-kernel-pkg to just regenerate the grub2 config using
  > > grub2-mkconfig instead of using grubby?
  >
  > I don't think so.  Despite the similarity in name, grubby does more
  > than just deal with grub stuff.  Namely, it handles bootloaders that
  > aren't grub.  We're close to having all arches on grub2, but I believe
  > armv7hl won't ever get there and it's a primary arch.

 Could we switch for grub2 architectures and keep using grubby for other
 architectures?
>>>
>>>
>>> no - there is a world without grub2
>>> https://fedoraproject.org/wiki/Features/SyslinuxOption
>>
>> Then let's make the same change across all bootloaders.  For grub2, use
>> grub2-mkconfig.  For syslinux, use whatever Anaconda uses to generate the
>> config in the first place.
>
> And you would do that via a single command how?  By wrapping it in an
> architecture/bootloader agnostic wrapper.  Which is what grubby is.

But it's not.  grubby does things like adding kernels and removing
kernels.  grub2-mkconfig enumerates kernels and generates a config.

>
>> Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
>> also like to see grubby go away.
>
> Maybe you could start by listing the problems you have with grubby
> (and apparently grub2) instead of just saying get rid of it?

Fair enough.  Two major problems come to mind:

1. grubby puts the most recently-installed kernel on top.
grub2-mkconfig puts the highest version on top.  In the cases where
they differ, I'd argue that the latter is better.

2 .If I want to edit boot options, grubby makes it unnecessarily
painful, and the directions are simply wrong.  For example, my
/etc/grub2-efi.cfg says:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

That's grossly misleading.  It *was* automatically generated, but it
is certainly not automatically generated on an ongoing basis.  If I
change settings in /etc/default/grub, nothing happens.  If I actually
want to change boot options, I have to either manually edit every
instance (or somehow, magically, the correct subset of copies) in
/etc/grub2-efi.cfg, which is a real pain and easy to screw up.  Or I
can cross my fingers any try to figure out the right invocation to
just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
presumably).  Assuming that such an incantation exists (which it does
these days!), one wonders why it's not happening automatically on
kernel upgrades.

To the extent that I do it wrong and grub2-efi.cfg diverges from that
which is implied by /etc/default/grub, etc, we have a mess.  This can
happen due to settings editing and presumably due to other things.

In fact, looking more closely, there's already a divergence.
grub2-mkconfig doesn't emit LANG=en_US.UTF-8.  The grubby-generated
config has LANG=en_US.UTF-8 on all entries except vmlinuz-0-rescue.  I
would argue that that's a bug.  If grubby went away or started using
grub2-mkconfig internally, this bug and all bugs like it would become
impossible.

A more minor (from my POV) problem:

3. More critical-path code.  grub2-mkconfig must work for Anaconda to
work.  ostree requires it, too.  But grubby is a separate and
presumably rather more complicated codebase, and it needs to be kept
in sync for kernel upgrades to work, and those are also critical path.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Reindl Harald]

Am 02.12.2015 um 21:46 schrieb Andrew Lutomirski:

The fact that you assert your absolute correctness on a frequent basis
even when you're not correct makes me, and probably other people,
likely to discount everything you say even in the cases when you are
correct.  If you want your opinion to be helpful, please reconsider
how you write your emails.


the problem with that thread is that you discount anything because you 
refuse trying to understand that it is a *very* bad idea to touch *all* 
boot entries after a kernel install



Anyway, I filed an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1287854


and i answered why it is a bad idea there

"regenerating config instead of incrementally" leads in change 
*intentional* differences of options when someone tries to debug kernel 
problems and much more worse: a bug there would render *all* boot 
options unbootable instead only the last installed one


frankly one can even raise "installonly_limit" by intention and have the 
same kernel version with *multiple* options - that all would be erased 
by try out if a newer build fixes the problem


now you can say: that's not a problem for the ordinary user
i say: the ordianry user don't touch kernel options at all



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer  wrote:
> On Wed, Dec 2, 2015 at 2:35 PM, Andrew Lutomirski  wrote:
>> On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  wrote:
>>> And you would do that via a single command how?  By wrapping it in an
>>> architecture/bootloader agnostic wrapper.  Which is what grubby is.
>>
>> But it's not.  grubby does things like adding kernels and removing
>> kernels.  grub2-mkconfig enumerates kernels and generates a config.
>
> Hm.  Wait.  I think there might be a terminology conflict here.  Are
> you specifically referring to grubby the binary, or do you mean grubby
> the package?  Because I was talking about the latter, as it contains
> new-kernel-pkg, etc.

I'm talking about grubby the binary and grubby the approach of
incrementally editing the config rather than regenerating it each
time.

>
 Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
 also like to see grubby go away.
>>>
>>> Maybe you could start by listing the problems you have with grubby
>>> (and apparently grub2) instead of just saying get rid of it?
>>
>> Fair enough.  Two major problems come to mind:
>>
>> 1. grubby puts the most recently-installed kernel on top.
>> grub2-mkconfig puts the highest version on top.  In the cases where
>> they differ, I'd argue that the latter is better.
>
> That's a matter of preference.  If I have a newer kernel version
> installed that doesn't actually work, I want the older kernel I _just_
> installed to be the default and top entry so my machine boots to
> something I can use.  This happens often when people try rawhide -rcX
> kernels to test something.
>
> Fixing this might be better served by filing an RFE for grubby to
> change the preference order.

Or file an RFE for grub2 to have an option to use the file timestamps
instead of the version for the sort order.

In my case, I do a lot of kernel compiling, and I don't like the
RPM-provided 4.2-whatever kernels to end up above my 4.4+patches
kernel whenever dnf pulls in a new kernel.

>
>> 2 .If I want to edit boot options, grubby makes it unnecessarily
>> painful, and the directions are simply wrong.  For example, my
>> /etc/grub2-efi.cfg says:
>>
>> #
>> # DO NOT EDIT THIS FILE
>> #
>> # It is automatically generated by grub2-mkconfig using templates
>> # from /etc/grub.d and settings from /etc/default/grub
>> #
>
> TBH, I just edit /boot/EFI/efi/grub.cfg directly.  It works fine.

I do that to.  I find it to be extremely tedious and error prone.  In
comparison, managing /etc/default/grub on the Ubuntu servers I
maintain is a piece of work, works every time, and requires no thought
about exactly how many copies of the same thing I have to change.  And
that file exists on Fedora, with the same contents, but uselessly,
unlike Ubuntu.  Debian/Ubuntu's update-grub tool is wonderful, and
it's really quite simple:

#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"

Of course, the paths would be a bit different for Fedora.

>
>> That's grossly misleading.  It *was* automatically generated, but it
>> is certainly not automatically generated on an ongoing basis.  If I
>> change settings in /etc/default/grub, nothing happens.  If I actually
>> want to change boot options, I have to either manually edit every
>> instance (or somehow, magically, the correct subset of copies) in
>> /etc/grub2-efi.cfg, which is a real pain and easy to screw up.  Or I
>> can cross my fingers any try to figure out the right invocation to
>> just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
>> presumably).  Assuming that such an incantation exists (which it does
>> these days!), one wonders why it's not happening automatically on
>> kernel upgrades.
>
> How often are you editing the boot options for _all_ installed
> kernels?  I'm not questioning what you're saying, but my experience
> tends show people edit boot options for a single stanza which isn't
> all that arduous.

I generally update for all because I don't trust grubby to propagate
them if I don't or I edit for all because I'm sometimes fastidious.
If I only do one, it's because I'm lazy.

>
> Also, once edited, any newly installed kernel after that picks up the
> added options auto-magically.

Depends which stanza I edit in my experience.

>
>> To the extent that I do it wrong and grub2-efi.cfg diverges from that
>> which is implied by /etc/default/grub, etc, we have a mess.  This can
>> happen due to settings editing and presumably due to other things.
>
> This sounds like a documentation issue?  You're looking at the files
> grub2 installs and trying to follow their advice, but the distro
> doesn't actually use any of that?
>
>> In fact, looking more closely, there's already a divergence.
>> grub2-mkconfig doesn't emit LANG=en_US.UTF-8.  The grubby-generated
>> config has LANG=en_US.UTF-8 on all entries except vmlinuz-0-rescue.  I
>> would argue that that's a 

Re: RFC: switching from grubby to grub2-mkconfig

[Josh Boyer]

On Wed, Dec 2, 2015 at 3:16 PM, Andrew Lutomirski  wrote:
> On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer  wrote:
>> On Wed, Dec 2, 2015 at 2:35 PM, Andrew Lutomirski  wrote:
>>> On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  
>>> wrote:
 And you would do that via a single command how?  By wrapping it in an
 architecture/bootloader agnostic wrapper.  Which is what grubby is.
>>>
>>> But it's not.  grubby does things like adding kernels and removing
>>> kernels.  grub2-mkconfig enumerates kernels and generates a config.
>>
>> Hm.  Wait.  I think there might be a terminology conflict here.  Are
>> you specifically referring to grubby the binary, or do you mean grubby
>> the package?  Because I was talking about the latter, as it contains
>> new-kernel-pkg, etc.
>
> I'm talking about grubby the binary and grubby the approach of
> incrementally editing the config rather than regenerating it each
> time.

Hm.  OK.

> Frankly, I'd like to see Fedora move away from grub2 even on x86.  But I'd
> also like to see grubby go away.

Could you elaborate on that grub2 part?

 Maybe you could start by listing the problems you have with grubby
 (and apparently grub2) instead of just saying get rid of it?
>>>
>>> Fair enough.  Two major problems come to mind:
>>>
>>> 1. grubby puts the most recently-installed kernel on top.
>>> grub2-mkconfig puts the highest version on top.  In the cases where
>>> they differ, I'd argue that the latter is better.
>>
>> That's a matter of preference.  If I have a newer kernel version
>> installed that doesn't actually work, I want the older kernel I _just_
>> installed to be the default and top entry so my machine boots to
>> something I can use.  This happens often when people try rawhide -rcX
>> kernels to test something.
>>
>> Fixing this might be better served by filing an RFE for grubby to
>> change the preference order.
>
> Or file an RFE for grub2 to have an option to use the file timestamps
> instead of the version for the sort order.

That sounds reasonable.

>>> 2 .If I want to edit boot options, grubby makes it unnecessarily
>>> painful, and the directions are simply wrong.  For example, my
>>> /etc/grub2-efi.cfg says:
>>>
>>> #
>>> # DO NOT EDIT THIS FILE
>>> #
>>> # It is automatically generated by grub2-mkconfig using templates
>>> # from /etc/grub.d and settings from /etc/default/grub
>>> #
>>
>> TBH, I just edit /boot/EFI/efi/grub.cfg directly.  It works fine.
>
> I do that to.  I find it to be extremely tedious and error prone.  In

*shrug*.  I guess we're going to disagree on that point, but that
isn't the end of the world.

> comparison, managing /etc/default/grub on the Ubuntu servers I
> maintain is a piece of work, works every time, and requires no thought
> about exactly how many copies of the same thing I have to change.  And
> that file exists on Fedora, with the same contents, but uselessly,
> unlike Ubuntu.  Debian/Ubuntu's update-grub tool is wonderful, and
> it's really quite simple:
>
> #!/bin/sh
> set -e
> exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
>
> Of course, the paths would be a bit different for Fedora.

I have no experience with other distros.  That may be why I don't
understand the desire to rip everything up.  However, even in thinking
about it some I can't see where I would personally care that much.

>>> That's grossly misleading.  It *was* automatically generated, but it
>>> is certainly not automatically generated on an ongoing basis.  If I
>>> change settings in /etc/default/grub, nothing happens.  If I actually
>>> want to change boot options, I have to either manually edit every
>>> instance (or somehow, magically, the correct subset of copies) in
>>> /etc/grub2-efi.cfg, which is a real pain and easy to screw up.  Or I
>>> can cross my fingers any try to figure out the right invocation to
>>> just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
>>> presumably).  Assuming that such an incantation exists (which it does
>>> these days!), one wonders why it's not happening automatically on
>>> kernel upgrades.
>>
>> How often are you editing the boot options for _all_ installed
>> kernels?  I'm not questioning what you're saying, but my experience
>> tends show people edit boot options for a single stanza which isn't
>> all that arduous.
>
> I generally update for all because I don't trust grubby to propagate
> them if I don't or I edit for all because I'm sometimes fastidious.
> If I only do one, it's because I'm lazy.

How funny!  I only edit one because I'm lazy.  Grubby propagates the
change to every kernel thereafter.  Also, I'm not sure I'd blindly
want an option passed to all existing kernels.  Quite often it is
something I'm trying that is new enough to only exist in certain
kernels, or a debug setting I only want on certain kernels.  But your
point is certainly valid.

>>> To the extent that I do it wrong and 

Re: RFC: switching from grubby to grub2-mkconfig

[Tomasz Torcz]

On Wed, Dec 02, 2015 at 12:54:43PM -0500, Neal Gompa wrote:
> >
> > > Frankly, I'd like to see Fedora move away from grub2 even on x86.  But
> > I'd
> > > also like to see grubby go away.
> >
> > Maybe you could start by listing the problems you have with grubby
> > (and apparently grub2) instead of just saying get rid of it?
> >
> > josh
> 
> 
> ​My big pain point right now is that we can't have /boot be a subvolume on
> btrfs and boot properly.
> 
> GRUB2 and ExtLinux both support booting from btrfs just fine, but we don't
> seem to support it for some reason?
> 
> I can't recall the issue off the top of my head, but I *think* the issue
> was related to grubby. Perhaps using grub2-mkconfig would fix this?​

  https://bugzilla.redhat.com/show_bug.cgi?id=124246
   
  It used to work, then it got broke.  To spare you from reading all the 
comments
in bug, the solution was to remove (from Anaconda) the ability to configure
this specific btrfs layout.  This solved release criteria compliance, but
left all previously installed systems with the pants down.

  I've been using grub2-mkconfig after every kernel upgrade succesfully on
those systems, since then.  On current, UEFI systems I'm using systemd-boot.

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Chris Murphy]

On Wed, Dec 2, 2015 at 10:46 AM, Colin Walters  wrote:
> On Tue, Dec 1, 2015, at 10:30 PM, Andrew Lutomirski wrote:
>> Since the old proposal to have the bootloader automatically enumerate
>> boot options never went anywhere, can we do the next best thing?
>>
>> Specifically, these days grub2-mkconfig appears to produce output
>> that's functionally identical to what grubby generates.  Can we switch
>> new-kernel-pkg to just regenerate the grub2 config using
>> grub2-mkconfig instead of using grubby.
>
> Note this is what ostree (as used by Fedora Atomic Host) does.

What's using (approximate) bootloaderspec drop-in snippets? Is that
rpm-ostree? I know Fedora carries bls.mod patch for GRUB 2 to support
those snippets, rather than depending on rewriting or modifying
grub.cfg; I'm not sure what the status of this work is for syslinux,
if any.

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 1:44 PM, Tomasz Torcz  wrote:
> On Wed, Dec 02, 2015 at 12:54:43PM -0500, Neal Gompa wrote:
>> >
>> > > Frankly, I'd like to see Fedora move away from grub2 even on x86.  But
>> > I'd
>> > > also like to see grubby go away.
>> >
>> > Maybe you could start by listing the problems you have with grubby
>> > (and apparently grub2) instead of just saying get rid of it?
>> >
>> > josh
>>
>>
>> My big pain point right now is that we can't have /boot be a subvolume on
>> btrfs and boot properly.
>>
>> GRUB2 and ExtLinux both support booting from btrfs just fine, but we don't
>> seem to support it for some reason?
>>
>> I can't recall the issue off the top of my head, but I *think* the issue
>> was related to grubby. Perhaps using grub2-mkconfig would fix this?
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=124246
>   It used to work, then it got broke.  To spare you from reading all the 
> comments
> in bug, the solution was to remove (from Anaconda) the ability to configure
> this specific btrfs layout.  This solved release criteria compliance, but
> left all previously installed systems with the pants down.
>
>   I've been using grub2-mkconfig after every kernel upgrade succesfully on
> those systems, since then.  On current, UEFI systems I'm using systemd-boot.

Is the issue that grub2-mkconfig can handle useful configs that grubby
can't?  If so, maybe that's another reason to switch to
grub2-mkconfig.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

On Wed, Dec 2, 2015 at 1:03 PM, Josh Boyer  wrote:
> On Wed, Dec 2, 2015 at 3:16 PM, Andrew Lutomirski  wrote:
>> On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer  
>> wrote:
>>> On Wed, Dec 2, 2015 at 2:35 PM, Andrew Lutomirski  wrote:
 On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer  
 wrote:
> And you would do that via a single command how?  By wrapping it in an
> architecture/bootloader agnostic wrapper.  Which is what grubby is.

 But it's not.  grubby does things like adding kernels and removing
 kernels.  grub2-mkconfig enumerates kernels and generates a config.
>>>
>>> Hm.  Wait.  I think there might be a terminology conflict here.  Are
>>> you specifically referring to grubby the binary, or do you mean grubby
>>> the package?  Because I was talking about the latter, as it contains
>>> new-kernel-pkg, etc.
>>
>> I'm talking about grubby the binary and grubby the approach of
>> incrementally editing the config rather than regenerating it each
>> time.
>
> Hm.  OK.
>
>> Frankly, I'd like to see Fedora move away from grub2 even on x86.  But 
>> I'd
>> also like to see grubby go away.
>
> Could you elaborate on that grub2 part?

Sure.  grub2 is really, really complicated.  Admittedly, it seems to
at least work reliably now, whereas it used to have serious problems.

As an example, back in the grub 1 days, menu entries were pretty
trivial.  With grub 1, I used to set up a password that was needed for
non-default interactions with the menu, and it was easy.  In grub 2,
it seems to be a multi-step process that's complicated for no great
reason and makes me nervous that I'll break my boot sequence entirely.

IIRC the IMO really nice BootLoaderSpec died, in part because grub2
didn't play along well.
(http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/)

Something like systemd-boot (that which used to be known as gummiboot)
or syslinux is much simpler and, especially with EFI, does what's
needed quite well.

>
> How funny!  I only edit one because I'm lazy.  Grubby propagates the
> change to every kernel thereafter.  Also, I'm not sure I'd blindly
> want an option passed to all existing kernels.  Quite often it is
> something I'm trying that is new enough to only exist in certain
> kernels, or a debug setting I only want on certain kernels.  But your
> point is certainly valid.
>
 To the extent that I do it wrong and grub2-efi.cfg diverges from that
 which is implied by /etc/default/grub, etc, we have a mess.  This can
 happen due to settings editing and presumably due to other things.
>>>
>>> This sounds like a documentation issue?  You're looking at the files
>>> grub2 installs and trying to follow their advice, but the distro
>>> doesn't actually use any of that?
>
> I still think this is an issue.  It might be worth focusing on documentation.
>

True.

 In fact, looking more closely, there's already a divergence.
 grub2-mkconfig doesn't emit LANG=en_US.UTF-8.  The grubby-generated
 config has LANG=en_US.UTF-8 on all entries except vmlinuz-0-rescue.  I
 would argue that that's a bug.  If grubby went away or started using
 grub2-mkconfig internally, this bug and all bugs like it would become
 impossible.

 A more minor (from my POV) problem:

 3. More critical-path code.  grub2-mkconfig must work for Anaconda to
 work.  ostree requires it, too.  But grubby is a separate and
 presumably rather more complicated codebase, and it needs to be kept
 in sync for kernel upgrades to work, and those are also critical path.
>>>
>>> I have a hard time being convinced this is a problem given the number
>>> of releases we've done and the number of times it's been a problem in
>>> said releases.
>>
>> Certainly the status quo seems to work for the most part, especially
>> if users don't do anything fancy.
>>
>> But Fedora's approach really seems to be considerably more complicated
>> than what everyone else does, and Fedora also packages all the code
>> for the simpler approach already.  Other than some people having a
>> preference for a different sort order (which could easily be added to
>> grub2-mkconfig), what's the benefit, if any, of Fedora's incremental
>> update approach?
>
> It leaves existing configs which are known to work alone and doesn't
> blow them away if you happen to make a typo in /etc/grub.cfg or
> whatever?  Breaking a single kernel boot because of a typo is fine.
> Making your machine unbootable because you regenerated an entire
> config file with a typo just seems silly.  Why would you want to
> expose users to that?

/etc/default/grub IIRC has GRUB_CMDLINE_LINUX and
GRUB_CMDLINE_LINUX_DEFAULT for this use case.  One affects the default
entry and the other affects recovery entries.  This might be a Debian
or Ubuntu-specific thing, though.

--Andy
--
devel mailing list

Re: RFC: switching from grubby to grub2-mkconfig

[Chris Murphy]

On Wed, Dec 2, 2015 at 10:54 AM, Neal Gompa  wrote:
>
> On Wed, Dec 2, 2015 at 12:50 PM, Josh Boyer 
> wrote:

>> Maybe you could start by listing the problems you have with grubby
>> (and apparently grub2) instead of just saying get rid of it?
>>
>> josh
>
>
> My big pain point right now is that we can't have /boot be a subvolume on
> btrfs and boot properly.
>
> GRUB2 and ExtLinux both support booting from btrfs just fine, but we don't
> seem to support it for some reason?
>
> I can't recall the issue off the top of my head, but I think the issue was
> related to grubby. Perhaps using grub2-mkconfig would fix this?

That would be the 100+ comment bug "grubby fatal error updating
grub.cfg when /boot is btrfs" from 2012.
https://bugzilla.redhat.com/show_bug.cgi?id=864198

Switching to grub2-mkconfig would fix this problem.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RFC: switching from grubby to grub2-mkconfig

[Andrew Lutomirski]

Since the old proposal to have the bootloader automatically enumerate
boot options never went anywhere, can we do the next best thing?

Specifically, these days grub2-mkconfig appears to produce output
that's functionally identical to what grubby generates.  Can we switch
new-kernel-pkg to just regenerate the grub2 config using
grub2-mkconfig instead of using grubby?

Debian has worked like this forever, and IMO it's superior in pretty
much all respects.  There are already nice config hooks for making
custom changes, and they're a lot more reliable than trusting grubby
to do what you expect it to do.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org