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.simm...@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
>

Reply via email to