* Could not prepare Boot variable @ 2025-01-09 19:01 Christophe Pisteur 2025-01-09 19:19 ` Felix Lechner via 2025-01-09 20:05 ` Roman Riabenko via 0 siblings, 2 replies; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 19:01 UTC (permalink / raw) To: help guix Hello, On my guix system, I did a simple guix pull then sudo guix system reconfigure /etc/config.scm but at the end of the process, when updating the boot loader, the following message appears in the console: construction de /gnu/store/15g01mbkxmjhy5fbl1cnwazf5bs4p5yl-install- bootloader.scm.drv... guix system: erreur : '/gnu/store/b923c23w9qr185xk40392434dm85wd72- grub-efi-2.12/sbin/grub-install --bootloader-id=Guix --boot-directory //boot --efi-directory //boot/efi' exited with status 1; output follows: Installation pour la plate-forme x86_64-efi. Could not prepare Boot variable: No space left on device /gnu/store/b923c23w9qr185xk40392434dm85wd72-grub-efi-2.12/sbin/grub- install : erreur : efibootmgr n'a pas réussi à enregistrer l'entrée de démarrage: Erreur d'entrée/sortie. I checked my partitions, which all have enough free space: /boot/efi 14% occupied space / 39% occupied space /gnu/store 39% occupied space Note that I'm dual-boot with ubuntu (24.10), but I hardly ever use this partition. Any idea to help me? Christophe ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 19:01 Could not prepare Boot variable Christophe Pisteur @ 2025-01-09 19:19 ` Felix Lechner via 2025-01-09 19:33 ` Christophe Pisteur 2025-01-09 20:05 ` Roman Riabenko via 1 sibling, 1 reply; 31+ messages in thread From: Felix Lechner via @ 2025-01-09 19:19 UTC (permalink / raw) To: Christophe Pisteur; +Cc: help guix Hi Christophe, On Thu, Jan 09 2025, Christophe Pisteur wrote: > Could not prepare Boot variable [...] efibootmgr n'a pas réussi à > enregistrer l'entrée de démarrage: Erreur d'entrée/sortie. Did you boot in EFI or in legacy mode? I don't read French, but 'efibootmgr' and the Boot variables (which look like 0001 and determine the boot order) are only available in EFI mode. Kind regards Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 19:19 ` Felix Lechner via @ 2025-01-09 19:33 ` Christophe Pisteur 2025-01-09 19:38 ` Felix Lechner via 0 siblings, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 19:33 UTC (permalink / raw) To: Felix Lechner; +Cc: help guix Hi Felix, Thanks a lot for the help. Apparently, I boot with efi (I have the file /sys/firmware/efi). I regularly do guix pull then sudo guix system reconfigure /etc/config.scm, and it goes without a hitch. I don't know what's wrong this time. Kind regards, Christophe Le jeudi 09 janvier 2025 à 11:19 -0800, Felix Lechner a écrit : > Hi Christophe, > > On Thu, Jan 09 2025, Christophe Pisteur wrote: > > > Could not prepare Boot variable [...] efibootmgr n'a pas réussi à > > enregistrer l'entrée de démarrage: Erreur d'entrée/sortie. > > Did you boot in EFI or in legacy mode? I don't read French, but > 'efibootmgr' and the Boot variables (which look like 0001 and > determine > the boot order) are only available in EFI mode. > > Kind regards > Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 19:33 ` Christophe Pisteur @ 2025-01-09 19:38 ` Felix Lechner via 2025-01-09 20:04 ` Christophe Pisteur 0 siblings, 1 reply; 31+ messages in thread From: Felix Lechner via @ 2025-01-09 19:38 UTC (permalink / raw) To: Christophe Pisteur; +Cc: help guix Hi Christophe, On Thu, Jan 09 2025, Christophe Pisteur wrote: > I boot with efi Can you run efibootmgr manually (in a shell)? Kind regards Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 19:38 ` Felix Lechner via @ 2025-01-09 20:04 ` Christophe Pisteur 0 siblings, 0 replies; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 20:04 UTC (permalink / raw) To: Felix Lechner; +Cc: help guix Hi Felix, Le jeudi 09 janvier 2025 à 11:38 -0800, Felix Lechner a écrit : > > > Can you run efibootmgr manually (in a shell)? This is what the command produces in my console (but I don't know what to do with it): ~$ sudo efibootmgr Mot de passe : BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0002,0001,001D,001E,001F,0020,0021,0022,0023,0024,0025 Boot0001* Windows Boot Manager HD(1,GPT,dd200da3-9719-464e-aa1d- 3f4149ef14d8,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494 e444f5753000100000088000000780000004200430044004f0042004a00450043005400 3d007b00390064006500610038003600320063002d0035006300640064002d003400650 0370030002d0061006300630031002d0066003300320062003300340034006400340037 00390035007d00000030000100000010000000040000007fff0400 Boot0002* Ubuntu HD(1,GPT,dd200da3-9719-464e-aa1d- 3f4149ef14d8,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi) Boot0010 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9) Boot0011 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850) Boot0012 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d- 163e59a7a380) Boot0013 Lenovo Diagnostics FvFile(3f7e615b-0d45-4f80-88dc- 26b234958560) Boot0014 ThinkShield secure wipe FvFile(3593a0d5-bd52-43a0-808e- cbff5ece2477) Boot0015 ThinkShield Passwordless Power-On Device Manager FvFile(08448b41-7f83-49be-82a7-0e84790ab133) Boot0016 Wi-Fi Configuration FvFile(d3aaff0f-cb22-4792-896c- 802c2e9383ba)2d004100700070000000 Boot0017 Reinstall Windows from Cloud FvFile(3edbaac4-5017-4870-8cc4- 721f9ef1974f)2d004100700070000000 Boot0018 Intel(R) MEBx FvFile(29a70110-7762-4211-ae88-fab19b7665be) Boot0019 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d- 7f786c3c8479) Boot001A Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26- db46eee9f1b5) Boot001B Regulatory Information FvFile(478c92a0-2622-42b7-a65d- 5894169e4d24) Boot001C Asset Information FvFile(da465b87-a26f-4c12-b78a-0361428fa026) Boot001D* USB CD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55) Boot001E* USB FDD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,6ff015a28830b543a8b8641009461e49) Boot001F* NVMe0 VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,001c199932d94c4eae9aa0b6e98eb8a400) Boot0020* USB HDD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,33e821aaaf33bc4789bd419f88c50803) Boot0021* PXE BOOT VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot0022* LENOVO CLOUD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,ad38ccbbf7edf04d959cf42aa74d3650)/Uri(https://download.lenovo.com/pccbbs/cdeploy/efi/boot.efi ) Boot0023* ON-PREMISE VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,ad38ccbbf7edf04d959cf42aa74d3650)/Uri() Boot0024 Other CD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,aea2090adfde214e8b3a5e471856a35400) Boot0025 Other HDD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,ca88c2349e7ae947beeb43038a5aeae700) Boot0026* IDER BOOT CDROM PciRoot(0x0)/Pci(0x14,0x0)/USB(11,1) Boot0027* IDER BOOT Floppy PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0) Boot0028* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,91af625956449f41a7b91f4f892ab0f6) Boot0029* ATAPI CD VenMsg(bc7838d2-0f82-4d60-8316- c068ee79d25b,aea2090adfde214e8b3a5e471856a354) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 19:01 Could not prepare Boot variable Christophe Pisteur 2025-01-09 19:19 ` Felix Lechner via @ 2025-01-09 20:05 ` Roman Riabenko via 2025-01-09 20:15 ` Christophe Pisteur 2025-01-09 20:16 ` Felix Lechner via 1 sibling, 2 replies; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 20:05 UTC (permalink / raw) To: Christophe Pisteur; +Cc: help guix Hello Christophe On Thu, 09 Jan 2025 20:01:55 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > Could not prepare Boot variable: No space left on device I also had this issue recently. The device here is not the boot partition. Instead, the device here is the EFI itself. Check whether you have any files begninning with "dump" in /sys/firmware/efi/efivars/ Those are dump files saved by the pstore kernel module. They should be safe to remove. Removing them frees up space for a new boot variable. I do not recommend rebooting until you complete the failed system reconfiguration. Otherwise, the boot may fail. GRUB did not show up for me at all. To prevent dump files from filling up space, I disabled the pstore backend which saves dump files to efi variables. I added the following configuration in the operating-system declaration. ;; Prevent filling /sys/firmware/efi/efivars/ with dumps (kernel-arguments (cons* "efi_pstore.pstore_disable=1" %default-kernel-arguments)) Hope this helps. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:05 ` Roman Riabenko via @ 2025-01-09 20:15 ` Christophe Pisteur 2025-01-09 20:24 ` Roman Riabenko via 2025-01-09 20:16 ` Felix Lechner via 1 sibling, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 20:15 UTC (permalink / raw) To: Roman Riabenko; +Cc: help guix Hello Roman, Thank you very much for your help. Le jeudi 09 janvier 2025 à 22:05 +0200, Roman Riabenko a écrit : > Hello Christophe > > > > I also had this issue recently. The device here is not the boot > partition. Instead, the device here is the EFI itself. Ah ok > > Check whether you have any files begninning with "dump" > in /sys/firmware/efi/efivars/ > > Those are dump files saved by the pstore kernel module. They should > be > safe to remove. Removing them frees up space for a new boot variable. I have 218 (!) files begninning with "dump": do I delete them all without distinction? > > I do not recommend rebooting until you complete the failed system > reconfiguration. Otherwise, the boot may fail. GRUB did not show up > for me at all. Ok , Thanks for the advice! Kind Regards Christophe ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:15 ` Christophe Pisteur @ 2025-01-09 20:24 ` Roman Riabenko via 2025-01-09 20:42 ` Christophe Pisteur 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 20:24 UTC (permalink / raw) To: Christophe Pisteur; +Cc: help guix On Thu, 09 Jan 2025 21:15:22 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > I have 218 (!) files begninning with "dump": do I delete them all > without distinction? Yes, that's what I did. To be more precise, they all seem to begin with dump-type0-... They are error logs. But I do not know how to use them, so they were of no use to me. I just removed them all. Considering that they appear, there is a persisting error, so they reappear over time. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:24 ` Roman Riabenko via @ 2025-01-09 20:42 ` Christophe Pisteur 2025-01-09 20:49 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 20:42 UTC (permalink / raw) To: Roman Riabenko, Felix Lechner; +Cc: help guix Hi Roman, Le jeudi 09 janvier 2025 à 22:24 +0200, Roman Riabenko a écrit : > On Thu, 09 Jan 2025 21:15:22 +0100 > Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > > > I have 218 (!) files begninning with "dump": do I delete them all > > without distinction? > > Yes, that's what I did. I can't delete these files: I need privileges not accessible from nautilus. Is the following console command correct? sudo rm /sys/firmware/efi/efivars/dump-type0-* Best Regards, Christophe ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:42 ` Christophe Pisteur @ 2025-01-09 20:49 ` Roman Riabenko via 2025-01-09 21:10 ` Christophe Pisteur 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 20:49 UTC (permalink / raw) To: Christophe Pisteur; +Cc: Felix Lechner, help guix On Thu, 09 Jan 2025 21:42:28 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > Le jeudi 09 janvier 2025 à 22:24 +0200, Roman Riabenko a écrit : > > On Thu, 09 Jan 2025 21:15:22 +0100 > > Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > > > > > I have 218 (!) files begninning with "dump": do I delete them all > > > without distinction? > > > > Yes, that's what I did. > > I can't delete these files: I need privileges not accessible from > nautilus. > Is the following console command correct? > sudo rm /sys/firmware/efi/efivars/dump-type0-* Yes, this is the command that removes the dump files. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:49 ` Roman Riabenko via @ 2025-01-09 21:10 ` Christophe Pisteur 2025-01-09 21:34 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 21:10 UTC (permalink / raw) To: Roman Riabenko; +Cc: Felix Lechner, help guix Hello Roman, Le jeudi 09 janvier 2025 à 22:49 +0200, Roman Riabenko a écrit : > > > > Is the following console command correct? > > sudo rm /sys/firmware/efi/efivars/dump-type0-* > > Yes, this is the command that removes the dump files. > I deleted the “dump” files from the directory /sys/firmware/efi/efivars/, then I ran guix system reconfigure /etc/config.scm again, but the command ends with the same error message... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 21:10 ` Christophe Pisteur @ 2025-01-09 21:34 ` Roman Riabenko via 2025-01-09 22:04 ` Christophe Pisteur 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 21:34 UTC (permalink / raw) To: Christophe Pisteur; +Cc: Felix Lechner, help guix On Thu, 09 Jan 2025 22:10:07 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > Le jeudi 09 janvier 2025 à 22:49 +0200, Roman Riabenko a écrit : > > > > > > Is the following console command correct? > > > sudo rm /sys/firmware/efi/efivars/dump-type0-* > > > > Yes, this is the command that removes the dump files. > > > > I deleted the “dump” files from the directory > /sys/firmware/efi/efivars/, then I ran guix system reconfigure > /etc/config.scm again, but the command ends with the same error > message... That one did not happen to me. efivars directory is an interface that exposes EFI firmware variables. If you do not see the dump files in the directory, then EFI should have cleared them. However, in such case the memory would be freed for new variables, and you would not get the error when reconfiguring the system anymore. There are other ways to access the variables. You could try efivar to see whether the dumps are still reported by UEFI. $ guix shell efivar [env]$ efivar --list [env]$ exit The tool also allows removing variables, but I did not try that myself. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 21:34 ` Roman Riabenko via @ 2025-01-09 22:04 ` Christophe Pisteur 2025-01-09 22:34 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-09 22:04 UTC (permalink / raw) To: Roman Riabenko; +Cc: Felix Lechner, help guix Hi Roman, Le jeudi 09 janvier 2025 à 23:34 +0200, Roman Riabenko a écrit : > > There are other ways to access the variables. You could try efivar to > see whether the dumps are still reported by UEFI. > > $ guix shell efivar > [env]$ efivar --list > [env]$ exit > > The tool also allows removing variables, but I did not try that > myself. > [env]$ efivar --list do not report dumps files (cf. below) should I try logout and login (without rebooting)? Christophe -------------------------- [env]$ efivar --list e20939be-32d4-41be-a150-897f85d49829-MemoryOverwriteRequestControl 37d3e8e0-8858-4b84-a106-244bb8cbfdc3-LenovoLogging eb704011-1402-11d3-8e77-00a0c969723b-MTC 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder 0b7646a4-6b44-4332-8588-c8998117f2ef-LastBootCurrent 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications 04b37fe8-f6ae-480b-bdd5-37d98c5e89aa-VarErrorFlag 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002 bb983ccf-151d-40e1-a07b-4a17be168292-MemoryOverwriteRequestControlLock d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx 8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001 77fa9abd-0359-4d32-bd60-28f4e78f784b-OfflineMemoryDumpUseCapability 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0001 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0000 67c3208e-4fcb-498f-9729-0760bb4109a7-MailBoxQ 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0023 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0022 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0021 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0020 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001F 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001E 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001D 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0009 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0008 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0007 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0006 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0005 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0004 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0003 8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0002 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0029 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0028 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0027 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0026 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0025 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0024 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001C 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001B 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot001A 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0019 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0018 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0017 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0016 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0015 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0014 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0013 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0012 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0011 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0010 da48669f-63cc-4c23-bd99-78a09ff989c4-TdkFlashCommandLine 1fd8b79f-0be2-4d57-b241-81c5e24e01a1-AppPlatform 1fd8b79f-0be2-4d57-b241-81c5e24e01a1-AppName ca787f2e-4d68-4883-b99e-7fb12eb349cd-SoftwareInventory 77fa9abd-0359-4d32-bd60-28f4e78f784b-CurrentPolicy d9bee56e-75dc-49d9-b4d7-b534210f637a-certdb eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDEKPubCRC eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDEKPub eaec226f-c9a3-477a-a826-ddc716cdc0e3-UnlockIDCopy 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 77fa9abd-0359-4d32-bd60-28f4e78f784b-BuiltAsSecuredCorePC 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn 8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK d719b2cb-3d3a-4596-a3bc-dad00e67656f-db 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0029 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0028 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0027 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0026 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0025 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0024 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0023 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0022 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0021 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0020 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001F 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001E 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001D 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001C 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001B 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot001A 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0019 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0018 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0017 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0016 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0015 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0014 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0013 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0012 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0011 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0010 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0002 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0001 146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0000 a0b1889e-00eb-445b-8ca9-e91ce43c907d-AbtStatus a0b1889e-00eb-445b-8ca9-e91ce43c907d-AbtStatus2 a0b1889e-00eb-445b-8ca9-e91ce43c907d-ExtMsgStatusList 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev a0b1889e-00eb-445b-8ca9-e91ce43c907d-Nonce 8b604cac-3c4f-4e6c-862e-00b8b7436e5f-PreBootEventLogReset 57a34c69-4d62-0b7e-86e4-939c5c9b7c93-EventLog ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-TbtSetupVolatileData b08f97ff-e6e8-4193-a997-5e9e9b0adb32-CpuSetupVolatileData ba2df110-5140-4835-9f40-aaf6ef9b4c33-LenovoEcEkKey 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport 8be4df61-93ca-11d2-aa0d-00e098032b8c-VendorKeys d9bee56e-75dc-49d9-b4d7-b534210f637a-certdbv 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot 8be4df61-93ca-11d2-aa0d-00e098032b8c-SignatureSupport 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380-DIAGSPLSHSCRN a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380-SetupHotKey 580020c3-6c9c-4f93-8008-7fadc1fcfedd-LenovoFunctionConfig 49ad5446-9d32-4455-af9b-d774bda2cf8b-LenovoBDG aaf8e719-48f8-4099-a6f7-645fbd694c3d-SiSetup e947fcf9-dd01-4965-b808-32a7b6815657-System 14a22a97-8424-489e-9ead-dc09255658b5-UCR ac5cf0c1-a682-478f-8aa8-f285091b2a85-DptfConfig 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-SPLC 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WRDD 42780dd5-9a7d-404c-80e4-7f7094360394-BRDS 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-EWRD 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WGDS 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-SADS 42780dd5-9a7d-404c-80e4-7f7094360394-SADS 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-GPC 42780dd5-9a7d-404c-80e4-7f7094360394-GPC 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WPFC 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WCSC 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-UefiCnvWlanSarGeoOffsetMapping e65d8884-d4af-4b20-8d03-772ecc3da531-IntelUefiCnvWwanSkuSupport 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-UefiCnvWlanMPCC 42780dd5-9a7d-404c-80e4-7f7094360394-IntelUefiCnvBtBiQuadFilterBypass 42780dd5-9a7d-404c-80e4-7f7094360394-IntelUefiCnvBtPpagSupport 0ec1a7f5-4904-40a0-8eab-4bcc4666da45-PbaStatusVar 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoMfgProductID ea1fcaee-3a77-4bb8-9b98-518e75d29a99-MotherBoardHealth 89ed4fc1-4234-47bc-9081-7a6510a5e8a9-RmtRun ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-InitSetupVariable 72c5e28c-7783-43a1-8767-fad73fccafa4-SaSetup e59376d7-2dd9-42a3-9ec8-1d71d5e3c1ec-OsProfile d3f67d1d-f71f-4cae-812c-b487d03384f5-IntelVmdOsVariableV2 c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOG000 c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOGNUMBER aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54-Tcg2PhysicalPresenceFlags 0f6499b1-e9ad-493d-b9c2-2f90815c6cbc-PhysicalPresenceFlags 7b07d184-02d0-4bfd-ad6e-554c39353a13-LnvSysCfgReq dfe95647-6096-41a2-3d49-e9f1c3a3b2ca-IsTxtProvisionedSHA384 0b7646a4-6b44-4332-8588-c8998117f2ef-ProtectedBootOptions 97e533b2-6a6c-4c0b-8efb-6a493442dd1c-ESRTPLATFORMENTRY 573c8caf-fbdb-41a5-8f1a-c87d6695d39a-ESRTPLATFORMENTRY aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54-Tcg2PhysicalPresence ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-TcgSetup b318a3fb-c98c-43f4-8655-c76133acde44-VtioCfg 0af4027f-9b58-41c0-b62f-cd3a1cef54ee-LenovoWolInfo ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-Setup 943d1460-da6e-499a-af6d-4593b12bc4d7-LenovoThermalShutdown c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSMEMSIZE 54447606-288e-4136-9804-bd4f170d8695-LenovoFprData 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WRDS 5432122d-d034-49d2-a6de-65a829eb4c74-MeSetup a1d89a3a-4a90-429d-4365-1f64c3a29614- NhltEndpointsTableConfigurationVariable 27d37beb-537d-486f-916c-7ba02cff60f4-LenovoAbtStatus 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoSystemConfig 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LWO 67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoScratchData 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-ScpcChecked 92daaf2f-c02b-455b-b2ec-f5a3594f4aea-WAND 1827cfc7-4e61-4273-b796-d35f4b0c88fc-LenovoHiddenSetting 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBC 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBL 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoRuntimeConfig 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoConfig b08f97ff-e6e8-4193-a997-5e9e9b0adb32-CpuSetup 4570b7f1-ade8-4943-8dc3-406472842384-PchSetup 7975600e-4c1b-4e52-b75e-1ded70341813- SndwDevTopologyConfigurationVariable ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-PciBusSetup 7434a42f-a348-4107-9528-4341f5dfdf17-PwdUnlockErr a2c1808f-0d4f-4cc9-a619-d1e641d39d49-LenovoSecurityConfig 0b7646a4-6b44-4332-8588-c8998117f2ef-LastBootOrder 0b7646a4-6b44-4332-8588-c8998117f2ef-BootOrderDefault 711c703f-c285-4b10-a3b0-36ecbd3c8be2-CapsuleLongModeBuffer ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 22:04 ` Christophe Pisteur @ 2025-01-09 22:34 ` Roman Riabenko via 0 siblings, 0 replies; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 22:34 UTC (permalink / raw) To: Christophe Pisteur; +Cc: Felix Lechner, help guix On Thu, 09 Jan 2025 23:04:59 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > [env]$ efivar --list do not report dumps files (cf. below) > > should I try logout and login (without rebooting)? I don't know. I don't think it will have any effect. It is UEFI that refuses to take a new variable. You need to find a way to make it take the variable. The first time it happened, I rebooted and was unable to boot. GRUB did not show up. And selecting the Guix boot option in UEFI boot menu failed to load GRUB. I had to use a Guix installation USB drive to chroot into my installation (section 12 of the guix manual) and fix it. The second and third time it happend, I cleared the dumps via efivars directory the way you did. This allowed me to complete reconfiguring the system each time. It looks like my UEFI behaved better then yours. I do not know whether you can properly roll back the guix system to the last (meaning current) configuration, so that the existing boot option works. Maybe somebody else could comment on this. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:05 ` Roman Riabenko via 2025-01-09 20:15 ` Christophe Pisteur @ 2025-01-09 20:16 ` Felix Lechner via 2025-01-09 20:35 ` Roman Riabenko via 1 sibling, 1 reply; 31+ messages in thread From: Felix Lechner via @ 2025-01-09 20:16 UTC (permalink / raw) To: Roman Riabenko via; +Cc: Christophe Pisteur, Roman Riabenko Hi Roman, On Thu, Jan 09 2025, Roman Riabenko via wrote: > To prevent dump files from filling up space, I disabled the pstore > backend I think I want that, too. Did you submit a patch? Kind regards, Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:16 ` Felix Lechner via @ 2025-01-09 20:35 ` Roman Riabenko via 2025-01-09 21:45 ` Felix Lechner via 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-09 20:35 UTC (permalink / raw) To: Felix Lechner; +Cc: Roman Riabenko via, Christophe Pisteur On Thu, 09 Jan 2025 12:16:43 -0800 Felix Lechner <felix.lechner@lease-up.com> wrote: > On Thu, Jan 09 2025, Roman Riabenko via wrote: > > > To prevent dump files from filling up space, I disabled the pstore > > backend > > I think I want that, too. Did you submit a patch? While researching my issue, I noticed that some distributions turn this backend off by default to prevent users from getting into a trap. However, they seem to turn it off when packaging the software, not via a kernel argument. I do not know who should take care of that. Maybe some upstream developers should have it turned off by default? I do not know, but I assume that the real culprit is the faulty models of UEFI. Maybe UEFI should clear itself up for new boot variables instead of refusing to do so. Unfortunately, I am not knowledgeable enough to answer these questions and propose a correct solution in a patch. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 20:35 ` Roman Riabenko via @ 2025-01-09 21:45 ` Felix Lechner via 2025-01-10 13:51 ` Roman Riabenko via 2025-01-10 16:53 ` Tobias Geerinckx-Rice 0 siblings, 2 replies; 31+ messages in thread From: Felix Lechner via @ 2025-01-09 21:45 UTC (permalink / raw) To: Roman Riabenko Cc: Roman Riabenko via, Christophe Pisteur, Leo Famulari, Wilko Meyer Hi Roman, On Thu, Jan 09 2025, Roman Riabenko wrote: > some distributions turn this backend off by default to prevent users > from getting into a trap. However, they seem to turn it off when > packaging the software, not via a kernel argument. It's in the kernel's configuration, i.e. the first hit here. [1] I looped in Leo and Wilko. (EFI dump files exhaust space on the ESP.) Kind regards Felix [1] https://codesearch.debian.net/search?q=pstore_disable&literal=1 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 21:45 ` Felix Lechner via @ 2025-01-10 13:51 ` Roman Riabenko via 2025-01-12 13:33 ` Roman Riabenko via 2025-01-10 16:53 ` Tobias Geerinckx-Rice 1 sibling, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-10 13:51 UTC (permalink / raw) To: Felix Lechner Cc: Roman Riabenko via, Christophe Pisteur, Leo Famulari, Wilko Meyer On Thu, 09 Jan 2025 13:45:03 -0800 Felix Lechner <felix.lechner@lease-up.com> wrote: > Hi Roman, > > On Thu, Jan 09 2025, Roman Riabenko wrote: > > > some distributions turn this backend off by default to prevent users > > from getting into a trap. However, they seem to turn it off when > > packaging the software, not via a kernel argument. > > It's in the kernel's configuration, i.e. the first hit here. [1] > > I looped in Leo and Wilko. (EFI dump files exhaust space on the ESP.) > > Kind regards > Felix > > [1] https://codesearch.debian.net/search?q=pstore_disable&literal=1 Indeed, in the current kernel configuration, the option is not set. $ gunzip < /proc/config.gz | grep PSTORE | grep EFI CONFIG_EFI_VARS_PSTORE=m # CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-10 13:51 ` Roman Riabenko via @ 2025-01-12 13:33 ` Roman Riabenko via 2025-01-13 17:43 ` Christophe Pisteur 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-12 13:33 UTC (permalink / raw) To: Roman Riabenko Cc: Roman Riabenko via, Felix Lechner, Christophe Pisteur, Leo Famulari, Wilko Meyer Dear Felix On Fri, 10 Jan 2025 15:51:30 +0200 Roman Riabenko via <help-guix@gnu.org> wrote: > On Thu, 09 Jan 2025 13:45:03 -0800 > Felix Lechner <felix.lechner@lease-up.com> wrote: > > > Hi Roman, > > > > On Thu, Jan 09 2025, Roman Riabenko wrote: > > > > > some distributions turn this backend off by default to prevent users > > > from getting into a trap. However, they seem to turn it off when > > > packaging the software, not via a kernel argument. > > > > It's in the kernel's configuration, i.e. the first hit here. [1] > > > > I looped in Leo and Wilko. (EFI dump files exhaust space on the ESP.) > > > > Kind regards > > Felix > > > > [1] https://codesearch.debian.net/search?q=pstore_disable&literal=1 > > Indeed, in the current kernel configuration, the option is not set. > > $ gunzip < /proc/config.gz | grep PSTORE | grep EFI > CONFIG_EFI_VARS_PSTORE=m > # CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set Debian maintainers rejected a request to set the option in the past: https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=924794 I downloaded the current Debian kernels from the stable release (Bookworm) and Sid and checked that it does not have the option set. Instead, Fedora has the option set to disable this backend by default: https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config#_2098 Arch Linux has a similar issue report undecided: https://bugs.archlinux.org/task/70140 It appears, that the objective of introducing the option was to maintain the existing behaviour but allow the user to override it on problematic hardware: https://lore.kernel.org/lkml/20130312211417.GC16558@thinkpad-t410/ It looks like there are some advantages and disadvantages to setting the option. The difference seems to be in distributions' approaches to what they think their users would want. 1. The default is to enable the backend so that the users can troubleshoot kernel issues. Turning the backend off is considered optional for faulty UEFI implementations. 2. Instead, some distributions want to limit writing to EFI variables to prevent issues with faulty UEFI implementations from happening at all. What kind of distribution is Guix System? Maybe a third option of not trusting the proprietary UEFI? Kind regards Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-12 13:33 ` Roman Riabenko via @ 2025-01-13 17:43 ` Christophe Pisteur 2025-01-13 20:01 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Christophe Pisteur @ 2025-01-13 17:43 UTC (permalink / raw) To: Roman Riabenko; +Cc: help-guix, Felix Lechner, Leo Famulari, Wilko Meyer Hi, Le dimanche 12 janvier 2025 à 15:33 +0200, Roman Riabenko a écrit : > > Debian maintainers rejected a request to set the option in the past: > https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=924794 > > I downloaded the current Debian kernels from the stable release > (Bookworm) and Sid and checked that it does not have the option set. > > Instead, Fedora has the option set to disable this backend by > default: > https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config#_2098 > > Arch Linux has a similar issue report undecided: > https://bugs.archlinux.org/task/70140 > > It appears, that the objective of introducing the option was > to maintain the existing behaviour but allow the user to > override it on problematic hardware: > https://lore.kernel.org/lkml/20130312211417.GC16558@thinkpad-t410/ > > It looks like there are some advantages and disadvantages to setting > the option. The difference seems to be in distributions' approaches > to what they think their users would want. > > 1. The default is to enable the backend so that the users can > troubleshoot kernel issues. Turning the backend off is considered > optional for faulty UEFI implementations. > > 2. Instead, some distributions want to limit writing to EFI variables > to > prevent issues with faulty UEFI implementations from happening at > all. > > What kind of distribution is Guix System? Maybe a third option of not > trusting the proprietary UEFI? > > Kind regards > Roman Since the solution seems to take time to find, and since the temporary solution of deleting the “dump” files on my device /sys/firmware/efi/efivars doesn't work, I'm going to reinstall my system before I get stuck on an unfortunate reboot. Would you advise me to use legacy mode for booting (instead of efi) to avoid this problem again in the near future? Christophe ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-13 17:43 ` Christophe Pisteur @ 2025-01-13 20:01 ` Roman Riabenko via 2025-01-21 18:58 ` Leo Famulari 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-13 20:01 UTC (permalink / raw) To: Christophe Pisteur; +Cc: help-guix, Felix Lechner, Leo Famulari, Wilko Meyer Hello, Christophe. On Mon, 13 Jan 2025 18:43:27 +0100 Christophe Pisteur <christophe.pisteur@fsfe.org> wrote: > Since the solution seems to take time to find, and since the temporary > solution of deleting the “dump” files on my device > /sys/firmware/efi/efivars doesn't work, I'm going to reinstall my > system before I get stuck on an unfortunate reboot. > > Would you advise me to use legacy mode for booting (instead of efi) to > avoid this problem again in the near future? It depends on what is the cause of the problem. I guessed the problem was due to the dump files filling the variables' storage. If UEFI ran out of storage, then I would not expect legacy mode to make a difference because it is still provided by the same firmware. However, you cleared the dumps from the storage, and it did not help. Thus, maybe my assumption that UEFI ran out of its internal storage was wrong. The next thing I would try is removing a boot entry, assuming that you have one which you do not need. This may help if there is a limit on boot entries independently of the size of EFI variables storage. I am guessing that there might be such a limit. However, if that is the case, I find it difficult to explain how you ran out of them. There is a convention to label EFI boot entries and put the binaries in directories named after the operating systems. So, the label of the entry and the name of the directory could be considered clues when checking the list of entries. Guix System labels its entry as "Guix" and puts the binary at \EFI\Guix\grubx64.efi. I assume that you have it installed. $ ls /boot/efi/EFI/Guix/grubx64.efi /boot/efi/EFI/Guix/grubx64.efi I took a closer look at the efibootmgr output that you emailed before. The Guix boot entry is missing. Instead, it shows that the following boot option is selected to boot. > Boot0002* Ubuntu HD(1,GPT,dd200da3-9719-464e-aa1d- > 3f4149ef14d8,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi) From that, your EFI partition's PARTUUID must be dd200da3-9719-464e-aa1d-3f4149ef14d8 per "sudo blkid". I assume that your operating system is Guix System because you are trying to run "guix system reconfigure ..." If you do not have Ubuntu installed, then you may want to remove Ubuntu boot option. It is possible to remove an entry with efibootmgr. You would need to provide two options at the same time: "--bootnum" option followed by four digits of the boot entry number and "--delete-bootnum" to instruct efibootmgr to delete that option. This requires sudo or root. In the output that you provided, there is only one more boot entry associated with loading a binary from EFI partition and booting an operating system. You may want to delete that instead or in addition. > Boot0001* Windows Boot Manager HD(1,GPT,dd200da3-9719-464e-aa1d- > 3f4149ef14d8,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494 > e444f5753000100000088000000780000004200430044004f0042004a00450043005400 > 3d007b00390064006500610038003600320063002d0035006300640064002d003400650 > 0370030002d0061006300630031002d0066003300320062003300340034006400340037 > 00390035007d00000030000100000010000000040000007fff0400 Other boot options are not pointing to the EFI partition. I assume that those options were generated by UEFI based on its configuration. I would not touch those with efibootmgr, at least for now. As a side note, depending on your firmware, UEFI may later re-add boot entries based on the binaries available in the EFI partition. I usually manually remove those files which may remain from any past operating system installations. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-13 20:01 ` Roman Riabenko via @ 2025-01-21 18:58 ` Leo Famulari 2025-01-21 20:17 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Leo Famulari @ 2025-01-21 18:58 UTC (permalink / raw) To: Roman Riabenko; +Cc: Christophe Pisteur, help-guix, Felix Lechner, Wilko Meyer Okay, what should Guix do about this problem? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-21 18:58 ` Leo Famulari @ 2025-01-21 20:17 ` Roman Riabenko via 2025-01-21 20:26 ` Leo Famulari 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-21 20:17 UTC (permalink / raw) To: Leo Famulari; +Cc: Christophe Pisteur, help-guix, Felix Lechner, Wilko Meyer [-- Attachment #1: Type: text/plain, Size: 606 bytes --] Hello, Leo. On Tue, 21 Jan 2025 13:58:30 -0500 Leo Famulari <leo@famulari.name> wrote: > Okay, what should Guix do about this problem? Since I associate the problem with the default configuration of linux-libre package, it looks like I have to ask on their mailing list whether it is a good idea to set the following option by default in addition to deblobbing. CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y If they agree and change the default, Guix does not need to do anything about it. If they disagree, maybe I learn a good reason why Guix should not do anything about it. Roman [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-21 20:17 ` Roman Riabenko via @ 2025-01-21 20:26 ` Leo Famulari 2025-01-22 7:18 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Leo Famulari @ 2025-01-21 20:26 UTC (permalink / raw) To: Roman Riabenko Cc: Christophe Pisteur, znavko--- via, Felix Lechner, Wilko Meyer On Tue, Jan 21, 2025, at 15:17, Roman Riabenko wrote: > Hello, Leo. > > On Tue, 21 Jan 2025 13:58:30 -0500 > Leo Famulari <leo@famulari.name> wrote: > >> Okay, what should Guix do about this problem? > > Since I associate the problem with the default configuration of > linux-libre package, it looks like I have to ask on their mailing list > whether it is a good idea to set the following option by default in > addition to deblobbing. > > CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y As far as I can tell, linux-libre mainly changes Linux to fix what they call "freedom issues". If the problem we are discussing is not related to licensing or DRM, then I think it's out of scope for them, but in scope for Linux or Guix. So, should we disable this kernel option? Patch the source code like Debian? Something else? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-21 20:26 ` Leo Famulari @ 2025-01-22 7:18 ` Roman Riabenko via 2025-01-22 8:06 ` Efraim Flashner 0 siblings, 1 reply; 31+ messages in thread From: Roman Riabenko via @ 2025-01-22 7:18 UTC (permalink / raw) To: Leo Famulari Cc: Christophe Pisteur, znavko--- via, Felix Lechner, Wilko Meyer [-- Attachment #1: Type: text/plain, Size: 2160 bytes --] On Tue, 21 Jan 2025 15:26:13 -0500 "Leo Famulari" <leo@famulari.name> wrote: > On Tue, Jan 21, 2025, at 15:17, Roman Riabenko wrote: > > Hello, Leo. > > > > On Tue, 21 Jan 2025 13:58:30 -0500 > > Leo Famulari <leo@famulari.name> wrote: > > > >> Okay, what should Guix do about this problem? > > > > Since I associate the problem with the default configuration of > > linux-libre package, it looks like I have to ask on their mailing list > > whether it is a good idea to set the following option by default in > > addition to deblobbing. > > > > CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y > > As far as I can tell, linux-libre mainly changes Linux to fix what they call "freedom issues". > > If the problem we are discussing is not related to licensing or DRM, then I think it's out of scope for them, but in scope for Linux or Guix. > > So, should we disable this kernel option? Patch the source code like Debian? Something else? After giving it another thought, I believe that there is indeed no freedom issue. Error logs in EFI variables is a Linux kernel feature relying on UEFI standard specification, not on proprietary functionality. The fact that UEFI is overwhelmingly proprietary is a separate issue. In such case, Guix should do nothing about it. I expect packages in Guix to be faithful to the software authors intentions unless there is good reason to have it configured differently to make it work with other GNU software or to achieve Guix-specific objectives. In this case, we are considering whether it is necessary to account for faulty UEFI implementations. However, the affected users can account for them by passing efi_pstore.pstore_disable=1 to kernel arguments either manually in GRUB during boot or in Guix System configuration as long as their UEFI remains functional. So, there appears to be no problem for Guix to solve. Debian refused to patch the kernel because they consider the feature useful. https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=924794 Apparently, the Linux kernel developers also consider the feature useful enough for users to have it turned on by default. Roman [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-22 7:18 ` Roman Riabenko via @ 2025-01-22 8:06 ` Efraim Flashner 2025-01-22 20:49 ` Felix Lechner via 0 siblings, 1 reply; 31+ messages in thread From: Efraim Flashner @ 2025-01-22 8:06 UTC (permalink / raw) To: Roman Riabenko Cc: Leo Famulari, Christophe Pisteur, znavko--- via, Felix Lechner, Wilko Meyer [-- Attachment #1: Type: text/plain, Size: 2838 bytes --] On Wed, Jan 22, 2025 at 09:18:37AM +0200, Roman Riabenko via wrote: > On Tue, 21 Jan 2025 15:26:13 -0500 > "Leo Famulari" <leo@famulari.name> wrote: > > > On Tue, Jan 21, 2025, at 15:17, Roman Riabenko wrote: > > > Hello, Leo. > > > > > > On Tue, 21 Jan 2025 13:58:30 -0500 > > > Leo Famulari <leo@famulari.name> wrote: > > > > > >> Okay, what should Guix do about this problem? > > > > > > Since I associate the problem with the default configuration of > > > linux-libre package, it looks like I have to ask on their mailing list > > > whether it is a good idea to set the following option by default in > > > addition to deblobbing. > > > > > > CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y > > > > As far as I can tell, linux-libre mainly changes Linux to fix what they call "freedom issues". > > > > If the problem we are discussing is not related to licensing or DRM, then I think it's out of scope for them, but in scope for Linux or Guix. > > > > So, should we disable this kernel option? Patch the source code like Debian? Something else? > > After giving it another thought, I believe that there is indeed no freedom issue. Error logs in EFI variables is a Linux kernel feature relying on UEFI standard specification, not on proprietary functionality. The fact that UEFI is overwhelmingly proprietary is a separate issue. > > In such case, Guix should do nothing about it. I expect packages in Guix to be faithful to the software authors intentions unless there is good reason to have it configured differently to make it work with other GNU software or to achieve Guix-specific objectives. > > In this case, we are considering whether it is necessary to account for faulty UEFI implementations. However, the affected users can account for them by passing efi_pstore.pstore_disable=1 to kernel arguments either manually in GRUB during boot or in Guix System configuration as long as their UEFI remains functional. So, there appears to be no problem for Guix to solve. > > Debian refused to patch the kernel because they consider the feature useful. > https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=924794 > Apparently, the Linux kernel developers also consider the feature useful enough for users to have it turned on by default. > > Roman While I like the adherence to upstream's decisions and not doing downstream development through patches, in this case we should try to remove the footgun that has bit us multiple times in the past. What if we leave the kernel config as-is but add efi_pstore.pstore_disable=1 as a default kernel argument during boot? -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-22 8:06 ` Efraim Flashner @ 2025-01-22 20:49 ` Felix Lechner via 2025-01-24 16:18 ` Roman Riabenko via 0 siblings, 1 reply; 31+ messages in thread From: Felix Lechner via @ 2025-01-22 20:49 UTC (permalink / raw) To: Roman Riabenko Cc: Leo Famulari, Christophe Pisteur, znavko--- via, Wilko Meyer Hi, On Wed, Jan 22 2025, Efraim Flashner wrote: > add efi_pstore.pstore_disable=1 as a default kernel argument Thanks, Ephraim! Due to the recent explosion of traffic on the lists, I am reluctant to add one more, but I like your proposal. Kind regards Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-22 20:49 ` Felix Lechner via @ 2025-01-24 16:18 ` Roman Riabenko via 0 siblings, 0 replies; 31+ messages in thread From: Roman Riabenko via @ 2025-01-24 16:18 UTC (permalink / raw) To: Felix Lechner Cc: Leo Famulari, Christophe Pisteur, znavko--- via, Wilko Meyer [-- Attachment #1: Type: text/plain, Size: 533 bytes --] Hello On Wed, 22 Jan 2025 12:49:20 -0800 Felix Lechner <felix.lechner@lease-up.com> wrote: > On Wed, Jan 22 2025, Efraim Flashner wrote: > > > add efi_pstore.pstore_disable=1 as a default kernel argument > > Thanks, Ephraim! Due to the recent explosion of traffic on the lists, I > am reluctant to add one more, but I like your proposal. I submitted a patch implementing this idea with explanations. https://issues.guix.gnu.org/75808 Now, the discussions can continue in the issue instead of guix-help. Roman [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-09 21:45 ` Felix Lechner via 2025-01-10 13:51 ` Roman Riabenko via @ 2025-01-10 16:53 ` Tobias Geerinckx-Rice 2025-01-10 17:22 ` Felix Lechner via 2025-01-11 10:26 ` Roman Riabenko via 1 sibling, 2 replies; 31+ messages in thread From: Tobias Geerinckx-Rice @ 2025-01-10 16:53 UTC (permalink / raw) To: Felix Lechner, Felix Lechner via, Roman Riabenko Cc: Roman Riabenko via, Christophe Pisteur, Leo Famulari, Wilko Meyer On 9 January 2025 21:45:03 UTC, Felix Lechner via <help-guix@gnu.org> wrote: >EFI dump files exhaust space on the ESP. [PSA: the ESP is a FAT file system that stores .efi executables (usually, boot loaders, but there's a Doom port too). It's not involved at all in boot variable or dump storage. 'df' is not invited to this party.] Guix Systems running out of UEFI variable storage happens disturbingly often. It must be because we unconditionally 'update' ours on every reconfiguration, despite this being unnecessary, and the (notoriously bad) firmware implementations don't handle this properly. Nor will the cheap flash be rated for this many writes. …at least that's the only thing I can think of. This doesn't happen with such frequency on other distributions. I wonder if we can reliably test whether our variable is correctly set without parsing efibootmgr output or rewriting it in Scheme. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-10 16:53 ` Tobias Geerinckx-Rice @ 2025-01-10 17:22 ` Felix Lechner via 2025-01-11 10:26 ` Roman Riabenko via 1 sibling, 0 replies; 31+ messages in thread From: Felix Lechner via @ 2025-01-10 17:22 UTC (permalink / raw) To: Tobias Geerinckx-Rice Cc: Felix Lechner via, Roman Riabenko, Christophe Pisteur, Leo Famulari, Wilko Meyer On Fri, Jan 10 2025, Tobias Geerinckx-Rice wrote: > the ESP is [...] not involved at all in boot variable or dump storage. Thank you! You are right. I noticed my error after I hit 'send' but did not wish to burden this help list further. > I wonder if we can reliably test whether our variable is correctly set > without parsing efibootmgr output or rewriting it in Scheme. Wouldn't itt require one or the other? Kind regards Felix ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Could not prepare Boot variable 2025-01-10 16:53 ` Tobias Geerinckx-Rice 2025-01-10 17:22 ` Felix Lechner via @ 2025-01-11 10:26 ` Roman Riabenko via 1 sibling, 0 replies; 31+ messages in thread From: Roman Riabenko via @ 2025-01-11 10:26 UTC (permalink / raw) To: Tobias Geerinckx-Rice Cc: Felix Lechner, Felix Lechner via, Christophe Pisteur, Leo Famulari, Wilko Meyer Hello, Tobias. On Fri, 10 Jan 2025 16:53:27 +0000 Tobias Geerinckx-Rice <me@tobias.gr> wrote: > On 9 January 2025 21:45:03 UTC, Felix Lechner via <help-guix@gnu.org> wrote: > >EFI dump files exhaust space on the ESP. > > [PSA: the ESP is a FAT file system that stores .efi executables (usually, boot loaders, but there's a Doom port too). It's not involved at all in boot variable or dump storage. 'df' is not invited to this party.] > > Guix Systems running out of UEFI variable storage happens disturbingly often. > > It must be because we unconditionally 'update' ours on every reconfiguration, despite this being unnecessary, and the (notoriously bad) firmware implementations don't handle this properly. > > Nor will the cheap flash be rated for this many writes. > > …at least that's the only thing I can think of. This doesn't happen with such frequency on other distributions. I wonder if we can reliably test whether our variable is correctly set without parsing efibootmgr output or rewriting it in Scheme. Should I open an issue with guix? What information would you need from me? I think that I can reliably reproduce the problem with guix system failing to create the boot variable. It appears to happen when /sys/firmware/efi/efivars/ is filled up with a certain amount of dump-type0-* files. This happens relatively quickly on this machine after some number of reboots. If it has any potential to help to investigate the issue, I could re-enable the backend and run some tests. I understand and accept that experimenting with this may render this machine unbootable, potentially with UEFI becoming unavailable and unrecoverable. Roman ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2025-01-24 16:19 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-01-09 19:01 Could not prepare Boot variable Christophe Pisteur 2025-01-09 19:19 ` Felix Lechner via 2025-01-09 19:33 ` Christophe Pisteur 2025-01-09 19:38 ` Felix Lechner via 2025-01-09 20:04 ` Christophe Pisteur 2025-01-09 20:05 ` Roman Riabenko via 2025-01-09 20:15 ` Christophe Pisteur 2025-01-09 20:24 ` Roman Riabenko via 2025-01-09 20:42 ` Christophe Pisteur 2025-01-09 20:49 ` Roman Riabenko via 2025-01-09 21:10 ` Christophe Pisteur 2025-01-09 21:34 ` Roman Riabenko via 2025-01-09 22:04 ` Christophe Pisteur 2025-01-09 22:34 ` Roman Riabenko via 2025-01-09 20:16 ` Felix Lechner via 2025-01-09 20:35 ` Roman Riabenko via 2025-01-09 21:45 ` Felix Lechner via 2025-01-10 13:51 ` Roman Riabenko via 2025-01-12 13:33 ` Roman Riabenko via 2025-01-13 17:43 ` Christophe Pisteur 2025-01-13 20:01 ` Roman Riabenko via 2025-01-21 18:58 ` Leo Famulari 2025-01-21 20:17 ` Roman Riabenko via 2025-01-21 20:26 ` Leo Famulari 2025-01-22 7:18 ` Roman Riabenko via 2025-01-22 8:06 ` Efraim Flashner 2025-01-22 20:49 ` Felix Lechner via 2025-01-24 16:18 ` Roman Riabenko via 2025-01-10 16:53 ` Tobias Geerinckx-Rice 2025-01-10 17:22 ` Felix Lechner via 2025-01-11 10:26 ` Roman Riabenko via
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).