unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Stefan <stefan-guix@vodafonemail.de>
Cc: Mathieu Othacehe <othacehe@gnu.org>, 41011@debbugs.gnu.org
Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.
Date: Sun, 24 May 2020 15:42:15 +0200	[thread overview]
Message-ID: <20200524154215.1fdb0a94@scratchpost.org> (raw)
In-Reply-To: <078D1EA7-0875-4F24-AA49-D39CCDC77403@vodafonemail.de>

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

Hi Stefan,

On Sun, 24 May 2020 15:09:02 +0200
Stefan <stefan-guix@vodafonemail.de> wrote:

> Hm, if I select an older system generation in GRUB, than that older one is booted. But this doesn't change the bootloader.

Correct.  It doesn't need to since it just changes which Linux kernel will be booted temporarily, including what system and so on.

"System" here excludes $HOME.

Since the guix package manager itself is in $HOME, I think that that doesn't revert though.

> If I then delete some system generations – as I’ve seen so far, but I might be wrong – the bootloader is not reinstalled either.
> Only the grub.cfg is regenerated to remove the deleted generations.

You are totally right O_O

reinstall-bootloader says:

>          ;; Only install bootloader configuration file.

What happened here?  Why?!

(I think we should document these bootloader Guix intricacies in some better place than the mailing list archives; can't keep the thing straight otherwise :P)

>If I reboot, then I'm still using the latest generation GRUB, but boot some older system generation, which would not be able by itself to install this very recent GRUB in use.

It should be able to since guix package manager including package definitions is in $HOME, which is not rolled back, I think.  The only way to install the very recent GRUB is guix system reconfigure, and that will totally be able to see the newest guix packages.

> If I then reconfigure the system, only then another GRUB - or even a different bootloader, depending on my etc/config.scm – will be installed and the according configuration file will be generated as well. Then again all will fit.

Yes, that case is fine.

> In the worst case the (bootloader (bootloader-configuration …) …) in my etc/config.scm is still newer than this older guix system in use is able to handle.

I think guix-the-package-manager is not reverted, so it will be able to see the newest installable stuff. 

> Oh, by the way, does booting an older system generation also change the guix version in use from the latest 'guix pull'? I don't think it does.

No, that is per-user and not per-system.

> And does booting an older generation change the config.scm? I don’t think so either.

No.

> Actually, I don’t really understand what you mean. Are there circumstances beside a 'guix system reconfigure' in which the bootloader gets reinstalled? And with reinstall I don’t mean to only regenerate the grub.cfg, but calling /sbin/grub-install.

I think the actual bootloader (any of them those worked before) should be reinstalled by guix system delete-generations too, but apparently it doesn't do it right now.
Sounds very dangerous.  Doesn't that mean if one changed bootloaders in the past and then keeps using guix system delete-generations, that one eventually couldn't boot anymore?  O_O

> Isn’t the actual problem for an older running system generation to know which bootloder is currently in use? I think this can't be inferred by the currently running system generation. It may happen, that you use a brand new bootloader which is not known by the older system generation you just switched to.

I think guix-the-package-manager is still the newest one even after selecting an older system generation.

So the "brand new bootloader" case should be fine.
But the delete-generation case basically would have had to do the actual bootloader installation too.  Like it is now, it totally has a huge problem.

A possible way around having to know which bootloader is in use would be to just always install the configurations for all the known bootloaders.

> But still then, if you invoke a 'sudo -E guix system delete-generations' or a 'sudo -E guix system reconfigure' I think you still use the very latest guix version that you 'guix pull'-ed last.

Yes.

> And that guix version should still know all brand new bootloader. The problem may “only” be to know for 'sudo -E guix system delete-generations' which one to use.

Yep.

> But actually the bootloader-name field in /var/guix/profiles/system/parameters can't tell either, as it must be an older bootloader than the brand new one.

Correct.

> Maybe the information about the bootloader version in use needs to reside with the installed bootloader somewhere below /boot/efi/…? But this may be impossible for the legacy grub-bootloader.

That sounds like a huge can of worms to open.  Better would be some kind of bootloader detector (can package "os-prober" do it maybe?)--or better yet, just also install the bootloader each time a system generation is deleted and/or system in reconfigured.  That was the original plan.

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

  reply	other threads:[~2020-05-24 13:43 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 20:32 [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs Stefan
2020-05-10  8:20 ` Mathieu Othacehe
2020-05-10 21:13   ` Stefan
2020-05-18 21:43     ` Stefan
2020-05-21 15:07       ` Stefan
2020-05-21 18:40         ` Stefan
2020-05-23  8:10           ` Mathieu Othacehe
2020-05-24  0:22             ` Stefan
2020-05-23  8:02     ` Mathieu Othacehe
2020-05-24 10:18       ` Stefan
2020-05-24 11:00         ` Danny Milosavljevic
2020-05-24 13:09           ` Stefan
2020-05-24 13:42             ` Danny Milosavljevic [this message]
2020-05-24 13:58               ` Danny Milosavljevic
2020-05-24 17:06                 ` Stefan
2020-05-24 16:47               ` Stefan
2020-06-06 13:30         ` Stefan
2020-06-06 13:33           ` Stefan
2020-06-06 17:37             ` Danny Milosavljevic
     [not found]               ` <46CD97B3-9994-4AB7-AA7D-4DE39AB7A238@vodafonemail.de>
2020-06-09 13:44                 ` Danny Milosavljevic
2020-06-09 14:25                   ` Stefan
2020-06-11  4:21                   ` Maxim Cournoyer
2020-06-11 11:36                     ` Stefan
2020-06-11 13:07                       ` Maxim Cournoyer
2020-06-11 13:19                     ` Danny Milosavljevic
2020-06-12 14:41                       ` Stefan
2020-06-14 18:56                       ` Maxim Cournoyer
2020-06-11 23:43                     ` [bug#41820] [PATCH] file-systems: Add record type <nfs-share> for a file system device Stefan
2020-06-20 13:52                       ` Stefan
2020-06-12  0:06                     ` [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs Stefan
2020-06-14 19:09                       ` Maxim Cournoyer
2020-06-17 13:12                         ` Stefan
2020-09-05 11:25 ` Stefan
2020-09-06 13:07   ` Stefan
2020-09-06 14:35   ` Danny Milosavljevic
2020-09-06 15:14     ` Danny Milosavljevic
2020-09-07 22:59     ` Stefan
2020-09-08 22:37       ` Danny Milosavljevic
2020-09-13 17:46         ` [bug#41011] [PATCH] gnu: grub: Support for network boot via TFTP Stefan
2020-09-14  6:59           ` Efraim Flashner
2020-09-15 20:28             ` Stefan
2020-09-16  7:51               ` Efraim Flashner
2020-09-19 17:54                 ` Stefan
2020-09-20 11:47                   ` Stefan
2020-09-20 11:56                     ` Stefan
2020-09-26 10:52                       ` Stefan
2020-09-26 10:54                       ` Stefan
2020-09-26 16:13                         ` Danny Milosavljevic
2020-09-27 10:50                           ` Stefan
2020-09-27 10:51                             ` Stefan
2020-09-27 11:47                               ` Danny Milosavljevic
2020-09-14 12:34           ` Danny Milosavljevic
2020-09-15 22:10           ` Danny Milosavljevic
2020-09-27 11:57 ` bug#41011: " Stefan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200524154215.1fdb0a94@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=41011@debbugs.gnu.org \
    --cc=othacehe@gnu.org \
    --cc=stefan-guix@vodafonemail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).