Reconfiguring from chroot to fix Grub/boot partition fails because D-bus crashes

Dear Guix users,

For some reason, still to be understood, my EFI partition is no longer detected at boot and I cannot boot my existing Guix System. I could confirm that the Guix partition (encrypted) is fine, but my BIOS won't detect any bootable partition. Turns out my `/dev/nvme0n1p1` partition only contains a single file: `EFI/Guix/grubx64.efi`.

Then there is 3.72 GiB of unallocated space on the drive, and then `/dev/nvme0n1p3` which is my LUKS encrypted Guix root.

I tried following this guide: https://guix.gnu.org/manual/en/html_node/Chrooting-into-an-existing-system.html

I only had to add an extra step at the beginning to decrypt the partition with `cryptsetup luksOpen /dev/nvme0n1p3 cryptroot` and then mounted `/dev/mapper/cryptroot` to `/mnt` before following the next instructions.

Unfortunately, the last step of the guide, `guix system reconfigure /path/to/config.scm`, fails because D-bus crashes, which in turn breaks all my network interfaces (they all are toggled "DOWN" and won't get a IP when I turn them up again), and ultimately the `guix system reconfigure` cannot work either without an Internet connection.

This is what `/var/log/messages` say when I run the last step at 22:51: https://0x0.st/Hv2f.jpg

This looks like a bug since I did everything the guide indicates. Can anyone reproduce it and confirm that chrooting into an existing Guix installation to reconfigure and rescue the system does not work? Is there something missing in the how-to to prevent the D-bus crash? Would there be another way to save my system, i.e., reinstalling Guix from scratch on another SSD and then `dd` the LUKS partition from the broken SSD onto the root partition of the new one?

Any help would be welcome, as it'd give me hope that I can save my system and data. Many thanks in advance!

Kabouik

Hi Mathieu,

Mathieu <matf@disr.it> writes:

It could be broken 'nvram' of a motherboard. Because of that happened to

me on a single UEFI motherboard, personally I try not to use it at all,

but use all available disks instead.

With current Guix I'm not sure it is supported by the distribution. If

anyone would like to implement it in the upstream, here is my

configuration which I use [1] hopefully 'nvram' is not touched at all on

'guix system reconfigure' and survive a disk failure.

[…]

I could recommend to delete everything not required for a boot from the

configuration file and try to reconfigure again (warning that you will

probably get permission errors after adding those services again which

will require to 'chown' their state directories).

Another way to recover is reinstalling Guix from scratch, but it's

possible to do this without reformating or using another drive. Just

move every directory in your '/' to '/old-system' and proced regular

installation.

[1]: guix 1f734a6

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 1f734a6f0a7db5b0e12091a0c869c5c4810ac80e

config.scm:

/boot?/efi current state:

as you can see /boot?/efi/EFI/BOOT/BOOTX64.EFI is the thing needed for

boot, everything else probably a garbage.

mount points:

'/boot/grub' is not configured anywhere, but it's placed on a '/' mount

point which mounted from a raid disk array.