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)]

Previous Next

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