bug#69891: QEMU image downloaded from website fails to reconfigure with current config

[Josh Simmons]

A couple of clarifications on the last update, sent it a bit quickly before turning in for the night ^^;

The time-machine commit I arbitrarily chose as the Shepherd 0.10.2 release commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=72a0d8350a5edfe7d9e4b9c2665069a16c1cfbfd No idea if the issue is actually with one of the more recent Shepherd versions or some other package, though. As I'd mentioned in the previous comment, wondering if a more recent package is relying on the `service` interface being defined without declaring a specific dependency on Shepherd>0.10? Either way, running an incremental pull+reconfigure to shortly after Shepherd 0.10's release, then a present-day pull+reconfigure appeared to fix it.

For the bootloader issue, I copied /run/current-system/configuration.scm to /etc/config.scm and made the following update to the `file-systems` section before the above reconfigures:

```

(bootloader (bootloader-configuration

  (bootloader grub-bootloader)

  (targets '("/dev/vda"))

  (terminal-outputs '(console))))

(file-systems (cons (file-system

    (mount-point "/")

    (device "/dev/vda2") ;; <- Updated from /dev/vda1

    (type "ext4"))

  %base-file-systems))

```

Again, I'm doubtful this is the _right_ fix, but worked for me! Happy to have an updated Guix VM now :)

Cheers,

Josh

On Mon, Jun 3, 2024 at 12:36 AM Josh Simmons <josh.simmons@gmail.com> wrote:

I also hit this same issue with the QEMU image and have made some progress:

 - Folks in IRC logs had mentioned that Shepherd added support for the "service" interface in 0.10 (https://logs.guix.gnu.org/guix/2024-03-12.log#133456). I took a stab that maybe there was a 0.9 compatibility layer that was removed at some point between the release of 0.10 and the current day, so I did a `guix time-machine --commit=72a0d835 -- pull` and reconfigure. That did appear to get around the "service" interface Shepherd error that OP mentioned in their report.

 - For the magic number disk issue, it appears that the bootloader is mistakenly (???) configured to boot from /dev/vda1 with the grub-bootloader. When I changed it to /dev/vda2 (the root partition of the QEMU image) it booted successfully. /dev/vda1 appears to be an EFI partition, so maybe `grub-efi-bootloader` should be used instead?

Hope this helps others, too!

-Josh