GNU bug report logs - #69891
QEMU image downloaded from website fails to reconfigure with current config

Previous Next

To reply to this bug, email your comments to 69891 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leon Deml <festerdam <at> posteo.net>
To: bug-guix <at> gnu.org
Subject: QEMU image downloaded from website fails to reconfigure with
 current config
Date: Mon, 18 Mar 2024 17:42:00 +0000

[Message part 1 (text/plain, inline)]

Dear guix,

Your work on a functional package manager has perked my interest and
compelled me to try it out for myself.  Unfortunately GNU Guix doesn't
run on Fedora due to the dependence on nscd, I thus had to resort to
downloading your qcow2 image available at
https://ftpmirror.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2
I checked the signature and ran the image with the following command
(which I copied from the reference manual page on running GNU Guix on a
virtual machine, with the difference that I increased the amount of
memory because the system couldn't do a «guix pull» without freezing
and invoking the OOM killer):

> qemu-system-x86_64 \
>    -nic user,model=virtio-net-pci \
>    -enable-kvm -m 4096 \
>    -device virtio-blk,drive=myhd \
>    -drive 
> if=none,file=guix-system-vm-image-1.4.0.x86_64-linux.qcow2,id=myhd

However I noticed that every time I run «guix system reconfigure», I
get a file system check failure and am dumped into a bournish shell
when I reboot.  I therefore tried to see what happens if I simply do
«guix pull», followed by «sudo guix system reconfigure
/run/current-system/configuration.scm» without doing anything else,
which from what I understand should always work.  However, this also
leads to a file system check failure on reboot.

At the beginning of the system reconfigure command output, there's this
warning:

> guix system: warning: cannot determine provenance for current system

And at the end of the output there is:

> shepherd: Evaluating user expression (and (defined? (quote transient?)) 
> (map (# ?) ?)).
> The following derivation will be built:
> /gnu/store/zadlv1c08flw782s2vgii264pvh6a3d1-upgrade-shepherd-services.scm.drv
> 
> building 
> /gnu/store/zadlv1c08flw782s2vgii264pvh6a3d1-upgrade-shepherd-services.scm.drv...
> guix system: warning: exception caught while executing 'eval' on 
> service 'root':
> error: service: unbound variable
> guix system: warning: some services could not be upgraded
> hint: To allow changes to all the system services to take effect, you 
> will need to reboot.

I have sent you the last few lines in an attachment.  (it only contains
the last lines, because the xfce-terminal doesn't remember that much
output and because I couldn't figure out how to get tee to save all
output)

On reboot I get the following (transcribed, since I don't know how I
can copy-paste the vm output to the host machine):

> loading kernel modules...
> e2fsck: Bad magic number in super-block while trying to open /dev/vda1
> /dev/vda1:
> The superblock could not be read or does not describe a valid 
> ext2/ext3/ext4
> filesystem.  If the device is valid and it really contains an 
> ext2/ext3/ext4
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt and you might try running e2fsck with an alternate 
> superblock:
>     e2fsck -b 8193 <device>
>  or
>     e2fsck -b 32768 <device>
> 
> /dev/vda1 contains a vfat file system labelled 'GNU-ESP'
> File system check on /dev/vda1 failed
> Spawning Bourne-like REPL.

If in the boot menu I choose to run an old configuration, the error
does not occur.

I hope this report will be of help.

Regards,

Leon Deml

[guix-output.txt (text/plain, attachment)]

Message #8 received at 69891 <at> debbugs.gnu.org (full text, mbox):

From: Josh Simmons <josh.simmons <at> gmail.com>
To: 69891 <at> debbugs.gnu.org
Subject: RE: QEMU image downloaded from website fails to reconfigure with
 current config
Date: Mon, 3 Jun 2024 00:36:50 +0900

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #11 received at 69891 <at> debbugs.gnu.org (full text, mbox):

From: Josh Simmons <josh.simmons <at> gmail.com>
To: 69891 <at> debbugs.gnu.org
Subject: Re: QEMU image downloaded from website fails to reconfigure with
 current config
Date: Mon, 3 Jun 2024 08:57:00 +0900

[Message part 1 (text/plain, inline)]

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 <at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.