[core-updates-frozen] Image production is broken.

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Mathieu Othacehe
Severity
important

Debbugs page

Mathieu Othacehe wrote 3 years ago
(address . bug-guix@gnu.org)
87fsu07gay.fsf@gnu.org
Hello,

When a producing a disk-image, the system derivations are built twice:

Toggle snippet (11 lines)
building /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv...
successfully built /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv
building /gnu/store/bxh7s2lwl82d3lwd59swkf243h17gyg1-system.drv...
successfully built /gnu/store/bxh7s2lwl82d3lwd59swkf243h17gyg1-system.drv
building /gnu/store/81wqilcd9g8c0yh6xj7chbla9agz06d9-grub.cfg.drv...
successfully built /gnu/store/81wqilcd9g8c0yh6xj7chbla9agz06d9-grub.cfg.drv
building /gnu/store/m87i36kdb09vig99q3mj24f30i1h8bjf-grub.cfg.drv...
successfully built /gnu/store/m87i36kdb09vig99q3mj24f30i1h8bjf-grub.cfg.drv
building /gnu/store/ngdkc4dhaf9qhry71dmcp1dj7rvnaqiy-partition.img.drv...

The installed Grub configuration file in /boot/grub/grub.cfg points to a
system that is *not* part of the closure. The second Grub configuration
file shown above points to the other system that *is* part of the
closure.

While booting the image in QEMU, the boot fails when trying to access
the missing /gnu/system/xxx-system/boot file.

Thanks,

Mathieu
Ludovic Courtès wrote 3 years ago
control message for bug #50676
(address . control@debbugs.gnu.org)
874kags2g5.fsf@gnu.org
severity 50676 important
quit
Ludovic Courtès wrote 3 years ago
Re: bug#50676: [core-updates-frozen] Image production is broken.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 50676@debbugs.gnu.org)
87v92wqjim.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (2 lines)
> When a producing a disk-image, the system derivations are built twice:

What command did you use?

I tried:

./pre-inst-env guix system image -t qcow2 gnu/system/examples/bare-bones.tmpl

Running:

qemu-system-x86_64 -m 1024 -enable-kvm -snapshot /gnu/store/…-image.qcow2

drops me in the GRUB rescue shell right from the start, but I think
that’s because the command surprisingly builds an EFI image, as can be
seen from the generated genimage.cfg:

Toggle snippet (15 lines)
image image {
hdimage {}
partition GNU-ESP {
partition-type = 0xEF
image = "/gnu/store/zfia31ypdlcx5d7sxhwmh4d8jsq33cqb-partition.img"
offset = "1048576"
}
partition Guix_image {
partition-type = 0x83
image = "/gnu/store/8v4m9cqrgvmp3akajv2pk1pvcdrswx2g-partition.img"
offset = "0"
}
}

Toggle quote (8 lines)
> The installed Grub configuration file in /boot/grub/grub.cfg points to a
> system that is *not* part of the closure. The second Grub configuration
> file shown above points to the other system that *is* part of the
> closure.
>
> While booting the image in QEMU, the boot fails when trying to access
> the missing /gnu/system/xxx-system/boot file.

Uh.

Ludo’.
Mathieu Othacehe wrote 3 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 50676@debbugs.gnu.org)
87a6k7tyik.fsf@gnu.org
Hey Ludo!

Toggle quote (2 lines)
> What command did you use?

The same one as you :)

Toggle quote (4 lines)
> drops me in the GRUB rescue shell right from the start, but I think
> that’s because the command surprisingly builds an EFI image, as can be
> seen from the generated genimage.cfg:

Yep, that would be because of the Grub stripping issue. Regarding the
EFI, both the qcow2 and the efi-raw image types produce "hybrid" images
that have "grub" installed in the MBR-gap and "grub-efi" in the ESP
partition. This way, those images can be used both on legacy BIOS based
machines as well as on more modern UEFI machines.

Now the image types names can be confusing, and we could rename efi-raw
and qcow2 to pc-hybrid-raw and pc-hybrid-qcow2 respectively.

WDYT?

Thanks,

Mathieu
Mathieu Othacehe wrote 3 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 50676@debbugs.gnu.org)
87ilyvs91w.fsf@gnu.org
Hey,

The duplicated system derivation appears to be a grafted version of
the first one.

Running:

Toggle snippet (3 lines)
./pre-inst-env guix system image gnu/system/examples/bare-bones.tmpl -t qcow2 --no-grafts

produces an image that boots fine in QEMU.

Mathieu
Ludovic Courtès wrote 3 years ago
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 50676@debbugs.gnu.org)
87wnn8hp6b.fsf@gnu.org
Howdy!

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (10 lines)
>> drops me in the GRUB rescue shell right from the start, but I think
>> that’s because the command surprisingly builds an EFI image, as can be
>> seen from the generated genimage.cfg:
>
> Yep, that would be because of the Grub stripping issue. Regarding the
> EFI, both the qcow2 and the efi-raw image types produce "hybrid" images
> that have "grub" installed in the MBR-gap and "grub-efi" in the ESP
> partition. This way, those images can be used both on legacy BIOS based
> machines as well as on more modern UEFI machines.

Oh I hadn’t realized there was this fancy hybridation thing.

Toggle quote (3 lines)
> Now the image types names can be confusing, and we could rename efi-raw
> and qcow2 to pc-hybrid-raw and pc-hybrid-qcow2 respectively.

OTOH the beauty of those hybrid images is precisely that one doesn’t
need to know that it’s hybrid. Dunno, no strong opinion!

Thanks for explaining,
Ludo’.
Ludovic Courtès wrote 3 years ago
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 50676-done@debbugs.gnu.org)
87czoxmvly.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (20 lines)
> When a producing a disk-image, the system derivations are built twice:
>
> building /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv...
> successfully built /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv
> building /gnu/store/bxh7s2lwl82d3lwd59swkf243h17gyg1-system.drv...
> successfully built /gnu/store/bxh7s2lwl82d3lwd59swkf243h17gyg1-system.drv
> building /gnu/store/81wqilcd9g8c0yh6xj7chbla9agz06d9-grub.cfg.drv...
> successfully built /gnu/store/81wqilcd9g8c0yh6xj7chbla9agz06d9-grub.cfg.drv
> building /gnu/store/m87i36kdb09vig99q3mj24f30i1h8bjf-grub.cfg.drv...
> successfully built /gnu/store/m87i36kdb09vig99q3mj24f30i1h8bjf-grub.cfg.drv
> building /gnu/store/ngdkc4dhaf9qhry71dmcp1dj7rvnaqiy-partition.img.drv...
>
> The installed Grub configuration file in /boot/grub/grub.cfg points to a
> system that is *not* part of the closure. The second Grub configuration
> file shown above points to the other system that *is* part of the
> closure.
>
> While booting the image in QEMU, the boot fails when trying to access
> the missing /gnu/system/xxx-system/boot file.

This should be fixed by df46bef48eaa43c502fa9193371692c039b460c1, whose
log contains all the gory details. :-)

This should allow us to move forward with system testing on the branch!

Thanks,
Ludo’.
Closed
Mathieu Othacehe wrote 3 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 50676-done@debbugs.gnu.org)
877df3gm77.fsf@gnu.org
Hey!

Toggle quote (3 lines)
> This should be fixed by df46bef48eaa43c502fa9193371692c039b460c1, whose
> log contains all the gory details. :-)

Wooo, thanks for fixing that :) I gave it a try but this is still a part
of the code base I'm not familiar with.

Toggle quote (2 lines)
> This should allow us to move forward with system testing on the branch!

I created a "tests-core-updates-frozen" specification on Cuirass for
that purpose. Looks like there's something broken in (gnu ci) though.

Thanks,

Mathieu
Closed
Ludovic Courtès wrote 3 years ago
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 50676-done@debbugs.gnu.org)
871r5ako4o.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (5 lines)
>> This should allow us to move forward with system testing on the branch!
>
> I created a "tests-core-updates-frozen" specification on Cuirass for
> that purpose. Looks like there's something broken in (gnu ci) though.

Just fixed as 7c5f01d55634254bea8bad4c9dcc31496efd4fce!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 50676@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 50676
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help