Hi,

I work on GNU Boot, and as part of that I upstream what I can in Guix.

So at the end I was asked to join the (embedded) team that manages the
gnu/packages/coreboot.scm file.

So now part of my duties is to review patches, and that requires
testing them, and this is the biggest issue I have here.

Basically I have limited time and I cannot spend a week or a month
full time (why it's potentially so long is explained below) to test a
single patch.

Ideally I'd like to spend about 1 day max scattered here and there in
a week so it could be done relatively quickly to not make patch
submitters wait too much.

Most of the time my workflow is to first look at the patch and comment
on it. This is easy to do for me and it takes a few hours at most.

But then to give my Ack / Reviewed-by, I really want to test the patch
myself in various conditions.

For a simple package that is often trivial because it already builds
for the person sending the patch, and there isn't many possible side
effects, and most of the time it also build on top of the latest
master commit, so I can easily reproduce and validate that everything
is fine, enabling other people to push it.

The problem is that I'm part of the embedded team and so I've some
knowledge about things like GRUB which at the end of the day pushes me
to review patches that touches things like GRUB.

And for GRUB, I added grub-coreboot to Guix, I'm familiar with
grub-emu and several other --platform GRUB runs on, so I've also
knowledge and code to test many of these (system images, ways to build
grub-coreboot and to test it with Coreboot, etc).

And here serious testing often requires to build system images, to run
guix system reconfigure, etc.

The problem is that on my main computer (ThinkPad X200 with GNU
Boot with GRUB), Guix system x86_64-linux is very broken. And in many
cases that prevents testing.

So far It doesn't boot anymore without editing grub.cfg by hand.

I very strongly suspect that the problem is in GNU Boot but not Guix
but to fix it I need to create a Guix system image with an encrypted
rootfs and mess with GRUB to see if some files are in its memdisk.

And ideally I'd also like to fix that before to properly review GRUB
patches, including with my setup.

Alternatively I've also a shell script to relatively quickly generate an
image with an encrypted rootfs, but for some reasons, even without
graphical login and or a desktop environmenent it fails to build
gst-plugins-good (I've no idea why this is a dependency).

It would be OK for me if there was 1 failure like that and that it was
quite rare, but I often encounter issues with building images that
prevent me from testing GRUB.

Last time that happened was when GRUB was to be updated to the last
version. 

At the time when I finally managed to do very simple tests (generate an
image with MBR, and validate that it booted), I didn't have time
anymore to do more advanced tests. Hopefully I wasn't part of the
embedded team yet and other people did tests.

I've also other issues that combine with the above:

- I can't connect a second screen, if I do GDM, SDDM, or lightdm do
  crash. This is probably related to some Mesa update a while ago.

- Now I have artefacts in Gajim: if I right click I've some graphic
  issues that prevent me from seeing the menu. And if I do it often I
  can easily crash GDM again.

In these two cases I didn't find yet how to run GDM from the command
line and here too my plan is to make system images to do the tests
because there is some cache that can influence GDM at least: I had
tested older revisions that worked before and that stopped working
after testing newer Guix revisions.

I also have an additional issue: I can't easily use VMs under Guix
system anymore, because after suspend-resume /dev/kvm stops working
(the VM crash). But I can test images on real hardware instead, it just
requires a bit more time to do that.

I can provide details on all these issues and/or investigate but right
now I would rather welcome ideas on how to get out of this mess.

Most of the time I tried to solve a given issue, it didn't yield
anything due to other issues (broken packages) or dead ends (I didn't
manage to run GDM by hand, so I can't easily run it in GDB to get a
backtrace).

I even tried to help fix neox's issues with a specific Nvidia GPU in
the hope to get a more constrained issue and in the hope that maybe
it was the same root than mine, but at the end I ended up breaking
capacitors of my KGPE-D16 while installing the GPU (I managed to find a
GPU of the same family).

My main issue is that often issues combines together which prevents me
from fixing them (like system images not building which prevent me
from trying to fix my boot issues and/or test reconfigure with GRUB
patches).

Given the above I've also migrated away from Guix system: I still use
it from time to time (I'm sending this mail from Guix) but most of the
time I use Trisquel with Guix on top, so that can at least give
me a good base to start fixing these issues one by one.

Dual booting is also not great though as the /gnu/store isn't shared so
I need to again download a big amount of dependencies etc.

Though maybe having a stable distribution can be used somehow to help me
getting out of this mess and go back to helping reviewing patches as
soon as possible.

If people have ideas on how to get out of this mess they're really
welcome and I basically wrote this email because I'm out of ideas as
I've already tried many things since probably 6 months or more and it
I didn't manage to fix any of these alone, and the more I wait the more
issues accumulate.

In parallel I also had issues with the ARM support (my main server runs
Guix system aarch64-linux) but here I don't need any help as things are
now clear for me on how to fix them (and I've advanced a lot on this
front).

Attachment: pgp1TQC6pUaHS.pgp
Description: OpenPGP digital signature

  • Painful patch tes... Denis 'GNUtoo' Carikli

Reply via email to