bug#62379: /gnu/store/.links filling the hard drive on foreign distro
Hi, Elias Kueny skribis: > The problem is the size of /gnu/store/.links: after garbage collection > with "guix gc --delete-generations=1w", /gnu/store is 17.4 GB in > total, and /gnu/store/.links is 14.5 GB (344120 items, ranging from 93 > MB to 4.1 kB each). This is expected: /gnu/store/.links contains hard links to other files in /gnu/store. IOW /gnu/store/.links is a subset of the rest of /gnu/store, sharing the same inodes. > The garbage collector prints that "currently hard linking saves > 3717.77 MiB". With a 40GB hard drive, the gnu store regularly fills > up all the available space if I'm not careful. I found from an old > issue (https://issues.guix.gnu.org/24937#1) that 10 millions links > should need around 700 MB, so this sounds like a bug. Note that the issue you mention was addressed to a large extent in 2021: https://issues.guix.gnu.org/24937#20 HTH! Ludo’.
bug#62698: bind:utils
Αντώνιος Τσώλης writes:
Well, I use this:
(packages
(append
(map specification->package+output
'("bind:utils" ... ))
%base-packages))
But I am new to scheme/guile/guix, so maybe I do something
wrong. Anyway, thanks for confirming that it works on your
side. It's probably an issue with my configuration. :)
I suspected this was the problem. You really do need to use:
(map (compose list specification->package+output)
'("bind:utils"))
Because ‘specification->package+output’ returns two values, and
you'll need to combine those into a list for the second value (the
‘utils’ output) to be seen.
-bjc
bug#62725: Undefined activation ordering between ‘setuid-program-service-type’ and ‘account-service-type’
There is currently no way to ensure that an account exists before
creating /run/setuid-programs, which means a setuid-program which
uses a custom user or group will fail to be created if setuid
activation happens before account activation.
As an example, here's a system config where I'm trying to install
‘/run/setuid-programs/dumpcap’ as setuid root with a primary group
of ‘wireshark’, also created by this config:
--8<---cut here---start->8---
(use-modules (gnu)
(gnu system setuid))
(use-package-modules networking)
(use-service-modules setuid)
;; TODO: make name configurable
(define %wireshark-groups
(list (user-group
(name "wireshark")
(system? #t
(define %wireshark-setuid-programs
(list (setuid-program
(program (file-append wireshark "/bin/dumpcap"))
(group "wireshark")
#;(mask #o550
(define wireshark-service-type
(service-type
(name 'wireshark)
(description "Allow use of wireshark by regular users in the
@code{wireshark} group.")
(extensions
(list (service-extension account-service-type
(const %wireshark-groups))
(service-extension setuid-program-service-type
(const %wireshark-setuid-programs
(default-value #f)))
(operating-system
(locale "en_US.utf8")
(timezone "America/New_York")
(keyboard-layout (keyboard-layout "us"))
(host-name "wireshark-test")
(users (cons* (user-account
(name "test")
(group "users")
(password (crypt "test" "$6$test"))
(supplementary-groups
'("wireshark")))
%base-user-accounts))
(packages
(cons*
(specification->package "wireshark")
%base-packages))
(services
(cons*
(service wireshark-service-type)
%base-services))
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/boot/efi"))
(keyboard-layout keyboard-layout)))
(file-systems
(cons* (file-system
(mount-point "/")
(device
(uuid "14f4e958-be9e-41bb-bd25-e90a7330093c"
'btrfs))
(type "btrfs"))
(file-system
(mount-point "/boot/efi")
(device (uuid "6866-56B1" 'fat32))
(type "vfat"))
%base-file-systems)))
--8<---cut here---end--->8---
When trying to boot this system in a VM, I'm told that the dumpcap
binary couldn't be created because the file wasn't found. The
returned error is improperly attributed: the source file does
exist, and the error code is actually coming from getgrent(3)
which cannot find the ‘wireshark’ group.
Tracing through the activation scripts shows this to be because,
in this case, setuid-program activation happens before
account-activation.
Thanks to jpoiret for doing a lot of the investigative work here,
which I'm merely verifying through testing.
I believe the correct solution here is to move ‘setuid-program’
activation to a one-shot Shepherd service, because Shepherd allows
explicit ordering, as well as other advantages. To that end, I
have a patch which does precisely that, which I will send to the
patches list shorty.
-bjc
bug#62711: Suspend-to-disk with LUKS-encrypted root doesn’t work
Hi Ludo, Ludovic Courtès writes: > Hello! > > Since my laptop’s battery died, I set up suspend-to-disk as documented > in the manual (info "(guix) Swap Space"). I use a swap file on top of > my LUKS-encrypted root partition, so I added: > > "resume=/swap" > "resume_offset=OFFSET" > > to my ‘kernel-arguments’ field, where OFFSET is given by ‘filefrag’. No file systems are mounted before resuming, otherwise you would get data loss. As mekeor mentioned, you need to pass the actual device that holds the swap file instead, specifying at which offset the file is. I'm starting to think I should set this up as well :) Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62723: autogen fails to build on i686-linux
Hello, autogen fails to build on i686-linux like so, for instance on master commit c9af27d4ca733b20f09019f1465d3e5fdc1ec724: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -DPKGDATADIR=\"/gnu/store/n29inqv3rnwix1jqsxc1gd2yw0q8jkr0-autogen-5.18.16/share/autogen\" -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o In file included from libopts.c:48: usage.c: In function ‘prt_extd_usage.isra’: usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 bytes into a region of size between 0 and 9 [-Werror=format-truncation=] 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~~ usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a destination of size 12 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); | ^~ cc1: all warnings being treated as errors The version we package from https://ftp.gnu.org/pub/gnu/autogen/ dates from 2018. The website https://www.gnu.org/software/autogen/ has apparently not been updated since 2015. I wonder if we had not better drop this apparently unmaintained software, but it has quite a lot of dependents: Building the following 1275 packages would ensure 2489 dependent packages are rebuilt Andreas
