From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id UAjwNDFyyl7ncwAA0tVLHw (envelope-from ) for ; Sun, 24 May 2020 13:10:09 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 8IXMMDFyyl4LbAAAbx9fmQ (envelope-from ) for ; Sun, 24 May 2020 13:10:09 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5B28294050A for ; Sun, 24 May 2020 13:10:09 +0000 (UTC) Received: from localhost ([::1]:54372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcqOG-0000tg-Ae for larch@yhetil.org; Sun, 24 May 2020 09:10:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcqOB-0000ta-8d for guix-patches@gnu.org; Sun, 24 May 2020 09:10:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53358) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcqOA-0002ko-Ja for guix-patches@gnu.org; Sun, 24 May 2020 09:10:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jcqOA-0005aH-EN for guix-patches@gnu.org; Sun, 24 May 2020 09:10:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs. Resent-From: Stefan Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 24 May 2020 13:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41011 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Danny Milosavljevic Cc: Mathieu Othacehe , 41011@debbugs.gnu.org Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.159032575821412 (code B ref 41011); Sun, 24 May 2020 13:10:02 +0000 Received: (at 41011) by debbugs.gnu.org; 24 May 2020 13:09:18 +0000 Received: from localhost ([127.0.0.1]:36671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcqNR-0005ZI-PQ for submit@debbugs.gnu.org; Sun, 24 May 2020 09:09:18 -0400 Received: from vsmx011.vodafonemail.xion.oxcs.net ([153.92.174.89]:37689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcqNQ-0005Z5-9q for 41011@debbugs.gnu.org; Sun, 24 May 2020 09:09:16 -0400 Received: from vsmx003.vodafonemail.xion.oxcs.net (unknown [192.168.75.197]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id CD17059CFE9; Sun, 24 May 2020 13:09:10 +0000 (UTC) Received: from macbook-pro.kuh-wiese.my-router.de (unknown [2.206.141.243]) by mta-7-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 1B488539AB3; Sun, 24 May 2020 13:09:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stefan In-Reply-To: <20200524125859.7efe5169@scratchpost.org> Date: Sun, 24 May 2020 15:09:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <078D1EA7-0875-4F24-AA49-D39CCDC77403@vodafonemail.de> References: <9AAFEFF4-8ACE-4C95-975F-67C3F4FDAF81@vodafonemail.de> <87a72gi4kz.fsf@gmail.com> <1179D890-7D6C-43D8-A286-DA7A0F61D585@vodafonemail.de> <87h7w7cc55.fsf@gnu.org> <92DB8E2B-1CA2-41AE-9265-53C4F5337686@vodafonemail.de> <20200524125859.7efe5169@scratchpost.org> X-Mailer: Apple Mail (2.3124) X-VADE-STATUS: LEGIT X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.7 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.99 X-TUID: ORZy+Msd8xX+ Hi Danny! > Am 24.05.2020 um 13:00 schrieb Danny Milosavljevic = : >=20 >> But I=E2=80=99m not sure, if the field bootloader-name can be dropped = then[after adding bootloader-configuration-file to boot-parameters] from = . But if, then we could probably also drop the field = name from the record.=20 >=20 > We definitely can't drop it. The name is required in order to know = which > bootloader to restore when deleting system generations. After all you = could be > deleting the generation that switched from extlinux to grub. How to = boot then? >=20 > (see lookup-bootloader-by-name call site) OK, I understand. I will take a look at it. > Since we are trying to have the bootloader to use part of the Guix = system > configuration (for better or for worse), we have to be really careful = to > pick the right bootloader and generate the configuration for the right > bootloader, otherwise the computer won't boot anymore *and* you = couldn't > select the before-fuckup generation anymore either. Hm, if I select an older system generation in GRUB, than that older one = is booted. But this doesn't change the bootloader. If I then delete some system generations =E2=80=93 as I=E2=80=99ve seen = so far, but I might be wrong =E2=80=93 the bootloader is not reinstalled = either. Only the grub.cfg is regenerated to remove the deleted = generations. 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. If I then reconfigure the system, only then another GRUB - or even a = different bootloader, depending on my etc/config.scm =E2=80=93 will be = installed and the according configuration file will be generated as = well. Then again all will fit. In the worst case the (bootloader = (bootloader-configuration =E2=80=A6) =E2=80=A6) in my etc/config.scm is = still newer than this older guix system in use is able to handle.=20 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. And does booting an older generation change the config.scm? I don=E2=80=99= t think so either. Actually, I don=E2=80=99t really understand what you mean. Are there = circumstances beside a 'guix system reconfigure' in which the bootloader = gets reinstalled? And with reinstall I don=E2=80=99t mean to only = regenerate the grub.cfg, but calling /sbin/grub-install. Isn=E2=80=99t 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. 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. And that guix version = should still know all brand new bootloader. The problem may =E2=80=9Conly=E2= =80=9D be to know for 'sudo -E guix system delete-generations' which one = to use. 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. Maybe the information about the bootloader version in use needs to = reside with the installed bootloader somewhere below /boot/efi/=E2=80=A6? = But this may be impossible for the legacy grub-bootloader. >> Yes, it=E2=80=99s kind of possible to inherit from = grub-efi-bootloader and overwrite > the (configuration-file) field. In a first step this seems to work. = But when > e.g. deleting a system generation, in guix/scripts/system.scm > (reinstall-bootloader) there is this code: >>=20 >> ;; Use the detected bootloader with default configuration. >> ;; It will be enough to allow the system to boot. >> (bootloader-config (bootloader-configuration >> (bootloader bootloader)))=20 >=20 >> In it seems =E2=80=93 but I=E2=80=99m not sure yet = =E2=80=93 that we only keep a symbol name to figure out the path to the = grub.cfg, although it is possible to just put that path directly there = instead. And using the symbol makes it hard do get a configurable = bootloader: A new bootloader has to be a variable, tricks with macros = come up. Also inheriting from a bootloader and overwriting the = configuration-file field =E2=80=93 for whatever reason =E2=80=93 is = problematic: It seems to work at the beginning, but only fails badly = when removing a system generation. It seems to have subtle bugs. It=E2=80=99= s not usable like other parts in guix. It=E2=80=99s not hackable. I=E2=80=99= d really prefer to change this. >=20 > Yeah, well... that is the only way we could think of to make sure it = actually > boots in all cases, as it is right now. I think after switching to an older system generation this is not true, = as explained above. Am I wrong about this? > Just to be clear, I'm fine with changing boot-parameters, but be very = very > careful that all old versions of Guix and new versions of Guix can = handle > all the boot-parameters--at least falling back to something. I see. > Could you elaborate why having that hard-coded file path is bad? >=20 > It makes booting a lot more resilient if it's hard-coded as opposed to = having > basic stuff like that configurable--and being careful all the time = it's > actually configured correctly for all the parties to it, some of them = maybe > not even inside Guix. As I wrote a bit below: I think there is a second possibility. It may be = possible to create a symlink from /boot-nfs/efi/boot/grub.cfg to = ../../../boot/grub.cfg. Then the assumption that there will always be a = /boot/grub.cfg file stays valid. But Im still unsure about this. Bye Stefan=