GNU bug report logs - #26339
[PATCH 00/18] wip: Support non grub bootloaders.

Previous Next

Package: guix-patches;

Reported by: Mathieu Othacehe <m.othacehe <at> gmail.com>

Date: Sun, 2 Apr 2017 13:51:01 UTC

Severity: important

Tags: patch

Done: Mathieu Othacehe <m.othacehe <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #393 received at 26339 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26339 <at> debbugs.gnu.org, Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#26339: [PATCH 02/18] system: Add extlinux support.
Date: Fri, 12 May 2017 14:18:37 +0200
[Message part 1 (text/plain, inline)]
Hi !

> So it should probably pick the current (not the newest) bootloader type.

I'm not fan of installing every bootloader config because it means
multiple gcroots and filling /boot with possibly useless stuff.

However, reading the "parameters" of current system, extracting
bootloader type, and reinstalling *only* the bootloader configuration
file for this type seems a good idea to me.

I'll use this solution for v4. Plus we can come up later with a more
intelligent solution, storing bootloader store path in "parameters" and
creating a gcroot for it.

Thanks,

Mathieu


2017-05-12 13:36 GMT+02:00 Ludovic Courtès <ludo <at> gnu.org>:

> Hi,
>
> Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
>
> > On Fri, 12 May 2017 10:26:53 +0200
> > ludo <at> gnu.org (Ludovic Courtès) wrote:
> >
> >> > If there is a switch between extlinux and grub, the bootloader config
> file format (and name, too) will change.
> >> >
> >> > So if you do switch the config file out but don't switch the actual
> bootloader out it will not boot, right?
> >>
> >> Unless you regenerate the bootloader’s config file upon
> >> ‘switch-configuration’.
> >
> > Yes, for the last-guix-installed bootloader (presumably the
> still-installed one).  Good point.
> >
> > That would mean only the bootloader type of the newest system generation
> would be checked - also when restoring older generations.
> >
> > Can the newest system generation be deleted?  Then eventually Guix could
> read the wrong bootloader type (of a bootloader which isn't actually
> installed at the time).
>
> The newest generation can be deleted, but the current one cannot (it’s
> possible that the current one is not the newest if you picked an old
> entry in the boot menu.)
>
> So it should probably pick the current (not the newest) bootloader type.
>
> Ludo’.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 7 years and 209 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.