bug#53005: [PATCH 1/1] gnu: glibc: Preserve "__pthread_key_create" symbol.

[Tom Fitzhenry]

On 13/1/22 08:22, Simon South wrote:

No, this would've been a volume I created myself; I expect only users
who are partitioning their drives manually or replacing an existing
system would encounter this.


+1. I encountered this while installing Guix on my pre-existing LUKS 
volume that I share with another distro.


As a workaround to the immediate issue, I replaced my LUKS volume's 
argon2 key with a pbkdf2 key, via `cryptsetup luksAddKey --pbkdf pbkdf2 
$DEV` and `cryptsetup luksRemoveKey $DEV`. Changing cryptographic 
algorithms introduces risk, which might not be right for everyone, however.

bug#55848: [cuirass] workers stalled

[Tom Fitzhenry]

Greg Hogan  writes:

> On Wed, Jun 8, 2022 at 11:32 AM Mathieu Othacehe  wrote:
>> The aarch64 workers were all idle whereas 70k builds were
>> available. Once restarted, they started building again.

>From following the builds on http://ci.guix.gnu.org/workers , many
(all?) builds are failing on the following workers:

* grunewald
* kreuzberg
* pankow

The builds are failing with the same error:

"substitute: updating substitutes from 'https://ci.guix.gnu.org'...
0.0%guix substitute: error: TLS error in procedure 'handshake': Error in
the pull function."

Here's some examples:
* http://ci.guix.gnu.org/build/998403/details
* http://ci.guix.gnu.org/build/978678/details
* http://ci.guix.gnu.org/build/978243/details


On worker overdrive1, in the raw log of
http://ci.guix.gnu.org/build/875908/details we can see this
rust-async-mutex build managing to pull substitutes, but it 
seems to be compiling rust-1.57 itself.

bug#55909: linux-libre-arm64-generic with %base-initrd-module => kernel module not found "ahci"

[Tom Fitzhenry]

When building linux-libre-arm64-generic with %base-initrd-modules, the
linux-modules derivation fails with `kernel module not found "ahci"'.

Here's the steps to reproduce:

--8<---cut here---start->8---
$ cat minimal.scm
(use-modules
 (gnu packages linux)
 (gnu bootloader)
 (gnu bootloader grub)
 (gnu system file-systems))

(operating-system
  (host-name "foobar")
  (timezone "Australia/Sydney")
  (locale "en_AU.utf8")
  (bootloader (bootloader-configuration
   (bootloader grub-efi-removable-bootloader)
   (targets '("/boot/efi"
  (kernel linux-libre-arm64-generic)
  (file-systems (cons* (file-system
 (device (file-system-label "my-root"))
 (mount-point "/")
 (type "ext4"))
   (file-system
 (device (file-system-label "boot"))
 (mount-point "/boot/efi")
 (type "vfat"))
   %base-file-systems)))
$ guix time-machine --commit=a99015c8783eb5281618173779a0550b15a79617 --
  system reconfigure minimal.scm
$ zcat /var/log/guix/drvs/f3/2ljaayhsdlza6napn6d62ra1x5cm5f-linux-modules.drv.gz
Backtrace:
   5 (primitive-load "/gnu/store/bpaj7mfbws69b7pfwrdl7dw5pzs?")
In ice-9/eval.scm:
619:8  4 (_ #f)
   626:19  3 (_ #)
   293:34  2 (_ #(# #))
In srfi/srfi-1.scm:
   586:17  1 (map1 ("ahci" "usb-storage" "uas" "usbhid" "hid-gene?" ?))
In gnu/build/linux-modules.scm:
257:5  0 (_)

gnu/build/linux-modules.scm:257:5: kernel module not found "ahci" 
"/gnu/store/lvdihzd96kwqf31gs37n2b8ykdv1jp07-linux-libre-arm64-generic-5.17.14/lib/modules"
--8<---cut here---end--->8---

This fails beacuse %base-initrd-modules expects the "ahci" module, but
linux-libre-arm64-generic has that built in[0].

Workarounds for users include:

* use linux-libre-5.17, which has the disadvantage that
  linux-libre-5.17 is built from aux-files/linux-libre/*.conf rather
  than defconfig, thus making it less clear how much linux-libre-5.17
  has deviated from mainline's defconfig.
* don't use %base-initrd-modules, which has the disadvantage that users
  have to figure out which modules should be in their initrd
* disabling the check (?), which has the disadvantage that the check can be 
useful

Ideally users could use linux-libre-arm64-generic with
%base-initrd-modules. To do this, we could:

* replace "CONFIG_SATA_AHCI=m" with "CONFIG_SATA_AHCI=y" in
  gnu/packages/aux-files/linux-libre/*.conf .
* remove "ahci" from %base-initrd-modules

This amounts to converging aux-files/linux-libre/* towards the mainline
defconfigs. Is this a goal?

Thoughts?

0. CONFIG_SATA_AHCI=y, 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/configs/defconfig?h=v5.17.14#n291

bug#55848: [cuirass] workers stalled

[Tom Fitzhenry]

Mathieu Othacehe  writes:

Substitutes for aarch64 are a lot healthier now. Thanks Ludovic!

* kreuzberg is now successfully building and has been for a while.
* ci.guix.gnu.has has 41% of substitutes (a low percentage, but likely a
  high percentage of toolchains). 0 jobs are queued, presumably because Curiass
  believes its up-to-date. This should increase over time, as packages
  are updated.
* bordeaux has 83.8% of substitutes.

A few issues remain for aarch64:

* grunewald and kreuzberg are not on .
  Perhaps they were taken down while the substitute ratio was low to
  avoid each worker independently recompiling expensive toolchains?
* rust@1.39.0 (and thus all of Rust) is missing from ci and bordeaux. I
  had expected this would have been working. I'll take a look and raise
  a separate issue.

--8<---cut here---start->8---
$ ./pre-inst-env guix weather -s aarch64-linux -c2000
computing 15514 package derivations for aarch64-linux...
looking for 16265 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  41.0% substitutes available (6668 out of 16265)
  at least 34188.1 MiB of nars (compressed)
  45362.5 MiB on disk (uncompressed)
  0.015 seconds per request (144.9 seconds in total)
  66.2 requests per second

  0.0% (0 out of 9597) of the missing items are queued
  at least 1000 queued builds
  aarch64-linux: 110 (11.0%)
  powerpc64le-linux: 890 (89.0%)
  build rate: 36.81 builds per hour
  aarch64-linux: 17.23 builds per hour
  x86_64-linux: 14.25 builds per hour
  powerpc64le-linux: 1.01 builds per hour
  i686-linux: 4.83 builds per hour
1871 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', 
among which:
  3479  rust@1.39.0 
/gnu/store/xxlgndidxvhdd391k35vcmviixq5d9b0-rust-1.39.0-cargo 
/gnu/store/cfy1p8q4bwwy1i01cjfssfry21kpljz3-rust-1.39.0 
  2111  cairomm@1.14.2  
/gnu/store/bxknxn3nbmmvavf537k0pggrynhrgsaf-cairomm-1.14.2-doc 
/gnu/store/3sn66mgr29v73zpp93c2v09a0rj87l3w-cairomm-1.14.2 
  2101  texlive-latex-pgf@59745 
/gnu/store/l6jr7v8ygn3ybj4gxcwskf8ifsjcj6x1-texlive-latex-pgf-59745 
looking for 16265 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
  83.8% substitutes available (13624 out of 16265)
  35138.6 MiB of nars (compressed)
  109501.6 MiB on disk (uncompressed)
  0.060 seconds per request (699.4 seconds in total)
  16.7 requests per second
  (continuous integration information unavailable)
579 packages are missing from 'https://bordeaux.guix.gnu.org' for 
'aarch64-linux', among which:
  3479  rust@1.39.0 
/gnu/store/xxlgndidxvhdd391k35vcmviixq5d9b0-rust-1.39.0-cargo 
/gnu/store/cfy1p8q4bwwy1i01cjfssfry21kpljz3-rust-1.39.0
--8<---cut here---end--->8---



> Hello,
>
> The aarch64 workers were all idle whereas 70k builds were
> available. Once restarted, they started building again.
>
> The problem might be that when the server is unavailable for a while the
> worker connections expire and cannot be resumed once the server is
> available again.
>
> Thanks,
>
> Mathieu

bug#55848: [cuirass] workers stalled

[Tom Fitzhenry]

On Mon, 20 Jun 2022, at 12:39 PM, Maxim Cournoyer wrote:
> That's a known issue with mrustc; it only succeeds with x86_64; the
> other architectures have problems.  That's a bug the mrustc author would
> like to fix, so perhaps in time in will improve (especially if
> interested parties can lend a hand).

mrustc was fixed on aarch64 in https://issues.guix.gnu.org/54580 on staging, 
which was recently merged to master.

I had tested mrustc and rust-1.39 to compile on aarch64 on staging, but now I 
observe rust-1.39 failing.

I'll take a closer look, maybe I'm missing something.

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Tom Fitzhenry]

On 20/07/2021 04:21, Katherine Cox-Buday wrote:

I think this is because the EEPROM on the card is set as global. What
am I missing? Do you know how Linux intend for people to notify the
stack that this is an OK thing to do? I know projects like OpenWRT
carry patches to the driver, but I keep thinking surely this is not
the only way.


https://github.com/pcengines/apu2-documentation/issues/189 tracks this 
issue for PC Engines, which retails wireless cards whose EEPROM uses a 
global region.


My poor understanding is that Linux does not offer a way for end users 
to override the EEPROM, per "It should be reasonably impossible for a 
user to fail to comply with local regulations either unwittingly or by 
accident."[0]


It looks like the two supported ways to set regulatory domain are:
* a card vendor/retailer that performs certification, and flashes the 
EEPROM.
* a system integrator (e.g. off-the-shelf wireless routers, mobile 
phones, etc.) that performs certification and sets 
CONFIG_CFG80211_CERTIFICATION_ONUS.


Linux does offer a way to indicate your current region via CRDA[1], but 
this is for the "travelling in another country" usecase, and acts to 
restrict the driver to intersection(EEPROM, country).


0. https://wireless.wiki.kernel.org/en/developers/regulatory/statement
1. https://wireless.wiki.kernel.org/en/developers/regulatory

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Tom Fitzhenry]

On 20/07/2021 04:21, Katherine Cox-Buday wrote:

This is not part of the bug per-say, but a question around this space:
despite all of this, I still cannot broadcast on US approved channels.
I think this is because the EEPROM on the card is set as global. What
am I missing? Do you know how Linux intend for people to notify the
stack that this is an OK thing to do? I know projects like OpenWRT
carry patches to the driver, but I keep thinking surely this is not
the only way.


https://github.com/pcengines/apu2-documentation/issues/189 tracks this 
issue for PC Engines, which retails wireless cards whose EEPROM uses a 
global region.


Disclaimer: I don't understand this well.

My understanding is that Linux does not offer a way for end users to 
override the EEPROM, per "It should be reasonably impossible for a user 
to fail to comply with local regulations either unwittingly or by 
accident."[0]


I can see two supported ways to set the regulatory domain:
* a card vendor/retailer performs certification, and flashes the EEPROM 
accordingly.
* a system integrator (e.g. off-the-shelf wireless routers, mobile 
phones, etc.) performs certification and sets 
CONFIG_CFG80211_CERTIFICATION_ONUS.


Linux does offer a way to indicate your current region via CRDA[1], but 
this is for the "travelling in another country" usecase, and acts to 
restrict the driver to intersection(EEPROM, country).


0. https://wireless.wiki.kernel.org/en/developers/regulatory/statement
1. https://wireless.wiki.kernel.org/en/developers/regulatory

bug#51547: Erase / on boot

[Tom Fitzhenry]

Adventures so far...

I've pasted a working system configuration at the bottom.

The idea is to boot / as tmpfs, and to mount the minimal set of 
directories from persistent storage:

* /boot
* /gnu
* /home is not strictly required, but is useful!
* /var/guix

What's working:
* Booting to GNOME
* `guix system reconfigure`
* Booting previous generations
* /etc and /var are empty upon boot, woo!

A few issues:

* Bootstrapping all this is non-trivial. It requires fiddling with 
partitions, and getting it wrong can easily make your system unbootable. 
Suggestions? Maybe the user could set up bind-mounts to map to their 
preferred partition scheme? A basic cookbook entry could bind-mount 
directories from a single ext4 partition to the required directories.


* I tried setting up /gnu and /var/guix as bind-mounts per 
, 
but this didn't seem to work from initrd: the kernel panic'd on boot. I 
need to confirm this and raise a bug.


* Mounting / as tmpfs falsely requires a device, otherwise it waits 
forever on boot. I need to confirm this and raise a bug.


* Activation-on-boot fails due to inexistence of /run and /var/run. 
 fixes this.



Here's the config:



(use-modules (gnu))
(use-service-modules desktop networking ssh xorg)

(operating-system
 (timezone "Australia/Sydney")
 (host-name "test")
 (users (cons* (user-account
(name "tom")
(comment "Tom")
(group "users")
(home-directory "/home/tom")
;; Needed since /etc/passwd is not persisted.
(password (crypt "password" "foobar"))
(supplementary-groups
 '("wheel" "netdev" "audio" "video")))
   %base-user-accounts))
 (packages
  (append
   (list
(specification->package "emacs-next"))
   %base-packages))
 (services
  (append
   (list (service gnome-desktop-service-type)
 (set-xorg-configuration
  (xorg-configuration
   (keyboard-layout keyboard-layout
   %desktop-services))
 (bootloader
  (bootloader-configuration
   (bootloader grub-bootloader)
   (target "/dev/sda")
   (keyboard-layout keyboard-layout)))
 (file-systems
  (cons* (file-system
  (mount-point "/")
  (device
   ;; TODO: Raise bug that root-as-tmpfs falsely requires a partition.
   (uuid "59457d60-2b08-4f5c-b1c7-e29cd5f7a3da"
 'btrfs))
  (options "size=1G")
  (type "tmpfs"))
 (file-system
  (mount-point "/boot")
  (device
   (uuid "59457d60-2b08-4f5c-b1c7-e29cd5f7a3da"
 'btrfs))
  (options "subvol=boot")
  (needed-for-boot? #t)
  (type "btrfs")) 
 (file-system
  (mount-point "/home")
  (device
   (uuid "59457d60-2b08-4f5c-b1c7-e29cd5f7a3da"
 'btrfs))
  (options "subvol=home")
  (type "btrfs"))
 (file-system
  (mount-point "/var/guix")
  (device
   (uuid "59457d60-2b08-4f5c-b1c7-e29cd5f7a3da"
 'btrfs))
  (options "subvol=var/guix")
  ;; Needed to boot old generations, which needs /var/guix/profiles/
  (needed-for-boot? #t)
  (type "btrfs"))
 (file-system
  (mount-point "/gnu")
  (device
   (uuid "59457d60-2b08-4f5c-b1c7-e29cd5f7a3da"
 'btrfs))
  (options "subvol=gnu")
  (needed-for-boot? #t)
  (type "btrfs"))
 %base-file-systems)))

bug#51547: Erase / on boot

[Tom Fitzhenry]

This issue tracks the creation of a Guix System implementation of 
https://grahamc.com/blog/erase-your-darlings :


"I erase my systems at every boot.
[...]
NixOS can boot with only two directories: /boot, and /nix."

I have a working prototype of 
https://elis.nu/blog/2020/05/nixos-tmpfs-as-root/ . I will submit some 
small fixes in the short term, and later some larger patches.


Ideally this will result in a cookbook entry, and a CI test.

bug#51547: Erase / on boot

[Tom Fitzhenry]

On 1/11/21 23:19, Tom Fitzhenry wrote:

A few issues:


Another issue: /var/tmp/ is not created on boot, which breaks vi:

tom@computer ~/src$ vi
ex/vi: Error: /var/tmp/vi.recover: No such file or directory
ex/vi: Modifications not recoverable if the session fails
ex/vi: Error: /var/tmp/vi.recover/vi.u8Kkbb: No such file or directory