bug#50676: [core-updates-frozen] Image production is broken.

bug#50676: [core-updates-frozen] Image production is broken.

[Mathieu Othacehe]

Hello,

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

--8<---------------cut here---------------start------------->8---
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...
--8<---------------cut here---------------end--------------->8---

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

bug#50676: [core-updates-frozen] Image production is broken.

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

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

--8<---------------cut here---------------start------------->8---
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"
	}
}
--8<---------------cut here---------------end--------------->8---

> 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’.

bug#50676: [core-updates-frozen] Image production is broken.

[Mathieu Othacehe]

Hey Ludo!

> What command did you use?

The same one as you :)

> 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

bug#50676: [core-updates-frozen] Image production is broken.

[Mathieu Othacehe]

Hey,

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

Running:

--8<---------------cut here---------------start------------->8---
./pre-inst-env guix system image gnu/system/examples/bare-bones.tmpl -t qcow2 --no-grafts
--8<---------------cut here---------------end--------------->8---

produces an image that boots fine in QEMU.

Mathieu

bug#50676: [core-updates-frozen] Image production is broken.

[Ludovic Courtès]

Howdy!

Mathieu Othacehe <othacehe@gnu.org> skribis:

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

> 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’.

bug#50676: [core-updates-frozen] Image production is broken.

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

> 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’.

bug#50676: [core-updates-frozen] Image production is broken.

[Mathieu Othacehe]

Hey!

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

> 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

bug#50676: [core-updates-frozen] Image production is broken.

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> 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’.