Re: [RESEND RESEND RESEND PATCH] templates: introduce GRUB_TOP_LEVEL_* vars

[Oskari Pirhonen]

On Thu, Sep 29, 2022 at 03:23:07 -0700, Denton Liu wrote:
> Thanks for the response, Oskari!
> 
> On Thu, Sep 29, 2022 at 01:08:03AM -0500, Oskari Pirhonen wrote:
> > On Tue, Sep 27, 2022 at 05:30:45 -0700, Denton Liu wrote:
> > > A user may wish to use an image that is not sorted as the "latest"
> > > version as the top-level entry. For example, in Arch Linux, if a user
> > > has the LTS and regular kernels installed, `/boot/vmlinuz-linux-lts`
> > > gets sorted as the "latest" compared to `/boot/vmlinuz-linux`. However,
> > > a user may wish to use the regular kernel as the default with the LTS
> > > only existing as a backup.
> > > 
> > > Introduce the GRUB_TOP_LEVEL_LINUX and GRUB_TOP_LEVEL_XEN variables to
> > > allow users to specify the top-level entry.
> > > 
> > 
> > A couple questions:
> > 
> > - If all you're looking for is /boot/vmlinuz-linux to be booted, is
> >   setting GRUB_DEFAULT in /etc/default/grub "good enough" for your use
> >   case?
> 
> I think it is "good enough" for what I need but it feels a little bit
> weird that grub doesn't give the user any choice as to what the
> top-level kernel is.
> 

Perhaps no one has felt the need up until now ;)

> > - Is it possible to make this solution more universal? Maybe BSD users
> >   would like to set their top level entry.
> 
> I'm not too familiar with what end-users might want. If we want to make
> this more universal, we could either do GRUB_TOP_LEVEL_KERNEL and have
> that shared amongst all of the 10_* files or we could have multiple
> variables, e.g. GRUB_TOP_LEVEL_LINUX, GRUB_TOP_LEVEL_BSD, etc.
> 

A single GRUB_TOP_LEVEL or something is what I was thinking. I'm not
familiar with Xen, but based on your original patch, it may warrant its
own.

> > - What about for os-prober? My understanding is that it creates its own
> >   top level entries as well.
> 
> The same thing could work with os-prober, although it wouldn't be a
> cut-and-paste.
> 

os-prober would probably have its own GRUB_TOP_LEVEL_OS_PROBER or
something as well.

> I'm open to all ideas here and I can cook up the patches. The thing is
> that I'm not sure what the project's conventions are regarding
> too-granular/not-granular-enough configurations so some advice here
> would be very much appreciated!
> 

Generating a config for multiple OS's would use os-prober, so a single
"main" variable for top level entries would be simpler and should be
enough IMO.

- Oskari

signature.asc
Description: PGP signature