bug#64196: Can't boot due to discrepancy between reconfigure and init

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Csepp]

I'm trying to move my installation from /dev/sda to /dev/sdb, I created
the file system and changed the bootloader config in my operating-system
definition to point to /dev/sdb and the file-system to use the correct
UUID (previously it was using a label).
First I tried to simply reconfigure my running system and then taking a
BTRFS snapshot and copying that over the /dev/sdb1, but that failed.
The exact error was GRUB not being able to find a file system with a
given UUID, which matched the UUID of /dev/sda1.  This error happened
before GRUB loaded any of its modules, so I was dropped into a rescue
shell.
I thought this might be related to subvolumes, maybe I originally used
the wrong config and the updated config was written to a different
subvolume and GRUB doesn't recognize the default subvolume ID option on
the BTRFS partition.
I think this is a fairly critical error.

The error doesn't manifest when I run guix system init with the same
config, so there is some (possibly un(der)documented) difference between
guix system reconfigure and guix system init that makes the former rely
on the state of the running system in a way that doesn't take into
account the new configuration.

Is this intended behaviour for some reason?

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Josselin Poiret via Bug reports for GNU Guix]

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

Hi Csepp,

Csepp <raingloom@riseup.net> writes:

> I'm trying to move my installation from /dev/sda to /dev/sdb, I created
> the file system and changed the bootloader config in my operating-system
> definition to point to /dev/sdb and the file-system to use the correct
> UUID (previously it was using a label).
> First I tried to simply reconfigure my running system and then taking a
> BTRFS snapshot and copying that over the /dev/sdb1, but that failed.

Any reason you didn't try in the reverse order?  This seems prone to error.

> The exact error was GRUB not being able to find a file system with a
> given UUID, which matched the UUID of /dev/sda1.  This error happened
> before GRUB loaded any of its modules, so I was dropped into a rescue
> shell.
> I thought this might be related to subvolumes, maybe I originally used
> the wrong config and the updated config was written to a different
> subvolume and GRUB doesn't recognize the default subvolume ID option on
> the BTRFS partition.
> I think this is a fairly critical error.

This is too fuzzy to be actionable, but if you manage to reproduce
reliably then I would gladly take a look at it.

> The error doesn't manifest when I run guix system init with the same
> config, so there is some (possibly un(der)documented) difference between
> guix system reconfigure and guix system init that makes the former rely
> on the state of the running system in a way that doesn't take into
> account the new configuration.

I don't think there is, the biggest difference is that `guix system
init` will copy stuff into the target store and initialize the basic
directories for Guix, whereas reconfigure will just build everything in
the current store.

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Csepp]

Josselin Poiret <dev@jpoiret.xyz> writes:

> [[PGP Signed Part:Undecided]]
> Hi Csepp,
>
> Csepp <raingloom@riseup.net> writes:
>
>> I'm trying to move my installation from /dev/sda to /dev/sdb, I created
>> the file system and changed the bootloader config in my operating-system
>> definition to point to /dev/sdb and the file-system to use the correct
>> UUID (previously it was using a label).
>> First I tried to simply reconfigure my running system and then taking a
>> BTRFS snapshot and copying that over the /dev/sdb1, but that failed.
>
> Any reason you didn't try in the reverse order?  This seems prone to error.

Since reconfigure overwrites /dev/sdb, I don't see how reversing the
order would fix things??
Maybe copying the file system over and *then* running init would make
sense.

>> The exact error was GRUB not being able to find a file system with a
>> given UUID, which matched the UUID of /dev/sda1.  This error happened
>> before GRUB loaded any of its modules, so I was dropped into a rescue
>> shell.
>> I thought this might be related to subvolumes, maybe I originally used
>> the wrong config and the updated config was written to a different
>> subvolume and GRUB doesn't recognize the default subvolume ID option on
>> the BTRFS partition.
>> I think this is a fairly critical error.
>
> This is too fuzzy to be actionable, but if you manage to reproduce
> reliably then I would gladly take a look at it.

I tried reproducing it, it seems to happen every time, but I can try to
create a more minimal test case.

>> The error doesn't manifest when I run guix system init with the same
>> config, so there is some (possibly un(der)documented) difference between
>> guix system reconfigure and guix system init that makes the former rely
>> on the state of the running system in a way that doesn't take into
>> account the new configuration.
>
> I don't think there is, the biggest difference is that `guix system
> init` will copy stuff into the target store and initialize the basic
> directories for Guix, whereas reconfigure will just build everything in
> the current store.
>
> Best,

I mean, that's the theory, but either Guix or GRUB seems to get the
incorrect UUID from *somewhere*.

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Josselin Poiret via Bug reports for GNU Guix]

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

Hi,

Csepp <raingloom@riseup.net> writes:
>> I don't think there is, the biggest difference is that `guix system
>> init` will copy stuff into the target store and initialize the basic
>> directories for Guix, whereas reconfigure will just build everything in
>> the current store.
>>
>> Best,
>
> I mean, that's the theory, but either Guix or GRUB seems to get the
> incorrect UUID from *somewhere*.

You can manually check that the generated grub.cfg file contains the
expected UUID after the reconfigure, it should be in
/boot/grub/grub.cfg.

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Csepp]

Josselin Poiret <dev@jpoiret.xyz> writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> Csepp <raingloom@riseup.net> writes:
>>> I don't think there is, the biggest difference is that `guix system
>>> init` will copy stuff into the target store and initialize the basic
>>> directories for Guix, whereas reconfigure will just build everything in
>>> the current store.
>>>
>>> Best,
>>
>> I mean, that's the theory, but either Guix or GRUB seems to get the
>> incorrect UUID from *somewhere*.
>
> You can manually check that the generated grub.cfg file contains the
> expected UUID after the reconfigure, it should be in
> /boot/grub/grub.cfg.
>
> Best,

I did, I think I already wrote that it wasn't coming from there, but
I'll check again when I next try it.

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Csepp]

Csepp <raingloom@riseup.net> writes:

> Josselin Poiret <dev@jpoiret.xyz> writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi,
>>
>> Csepp <raingloom@riseup.net> writes:
>>>> I don't think there is, the biggest difference is that `guix system
>>>> init` will copy stuff into the target store and initialize the basic
>>>> directories for Guix, whereas reconfigure will just build everything in
>>>> the current store.
>>>>
>>>> Best,
>>>
>>> I mean, that's the theory, but either Guix or GRUB seems to get the
>>> incorrect UUID from *somewhere*.
>>
>> You can manually check that the generated grub.cfg file contains the
>> expected UUID after the reconfigure, it should be in
>> /boot/grub/grub.cfg.
>>
>> Best,
>
> I did, I think I already wrote that it wasn't coming from there, but
> I'll check again when I next try it.

This is still happening.  Couldn't figure out a decent way to transfer
my system with btrfs send.
I checked the generated bootloader installer script that gets run, it
seems to refer to the correct device, but somehow the UUID of the booted
partition still gets accessed.
I guess I'll have to strace it.