bug#59823: an installer dump was sent
Hello, So I had a closer look and we do have this strange kernel warning: --8<---cut here---start->8--- Dec 4 10:49:05 localhost vmunix: [ 1351.610773] device-mapper: ioctl: remove_all left 1 open device(s) --8<---cut here---end--->8--- I also noticed that we do not have the following trace: --8<---cut here---start->8--- /dev/sdX is not eligible because it is the installation device. --8<---cut here---end--->8--- which indicates that the "eligible-devices" procedure failed to identify the installation device. So /dev/sdd could be the installation device and the "with-delay-device-in-use?" always reports true because it is in fact always in use. My proposed patch probably won't help and the question is, why is the installation device not detected? Would it be possible for you to try the installation with an instrumented installer that I would provide you with? Thanks, Mathieu
bug#48468: substitute server connection timeout
Hello, > You mentioned on IRC that nginx logs show that ‘guix publish’ times out. > Looking at /var/log/nginx/error.log, I see “Connection reset by peer” > and “Broken pipe”, which could indicate that the client closed the > connection (which was open) prematurely, maybe due to an internal > timeout. Could it be that the client is receiving 404 because the baking of some NAR was deferred to a worker, and then it closes the connection? I think that's what I had in mind with the patch 2/2 of this patchset: https://issues.guix.gnu.org/50040. Thanks, Mathieu
bug#48468: substitute server connection timeout
Hi, Mathieu Othacehe skribis: >> You mentioned on IRC that nginx logs show that ‘guix publish’ times out. >> Looking at /var/log/nginx/error.log, I see “Connection reset by peer” >> and “Broken pipe”, which could indicate that the client closed the >> connection (which was open) prematurely, maybe due to an internal >> timeout. > > Could it be that the client is receiving 404 because the baking of some > NAR was deferred to a worker, and then it closes the connection? Unlikely. Take /gnu/store/qmzr030rzgikdxv3g9msqv0l8qp5j6y2-btrfs-raid-root-os.drv, which was marked as failed earlier today due to missing .drv. It’s a 4KiB file, and the cache-bypass-threshold is ‘guix publish’ is typically set to something much higher than that. So ‘guix publish’ won’t return 404 in that case. If you find a “missing derivation” error in Cuirass, how would you search logs to find what happened? I’m not sure where to look for useful debugging info. Thanks, Ludo’.
bug#59884: ‘gui-installed-desktop-os-encrypted’ test intermittent failures
Hi,
The ‘gui-installed-desktop-os-encrypted’ test fails intermittently like
so:
--8<---cut here---start->8---
Dec 7 12:14:01 localhost installer[253]: ^M^[[Kguix system:
^[[1m^[[0mbootloader successfully installed on /dev/vda^M
Dec 7 12:14:01 localhost installer[253]: command ("guix" "system" "init"
"--fallback" "--no-grafts" "--no-substitutes" "/mnt/etc/config.scm" "/mnt")
succeeded
conversation expecting pattern ((quote installation-complete))
Dec 7 12:14:01 localhost shepherd[1]: Service guix-daemon has been stopped.
Dec 7 12:14:01 localhost shepherd[1]: Service guix-daemon has been started.
Dec 7 12:14:01 localhost installer[253]: crashing due to uncaught exception:
system-error ("umount" "~S: ~A" ("/remove" "Device or resource busy") (16))
Dec 7 12:14:01 localhost installer[253]: running form #
("Unexpected problem") with 1 clients
Dec 7 12:14:01 localhost installer[253]: form # ("Unexpected
problem"): client 20 replied #t
/gnu/store/2bdm6l1j7siky5vadr62l3ns2z8qz75a-shepherd-marionette.scm:1:1718:
ERROR:
1. &pattern-not-matched:
pattern: ((quote installation-complete))
sexp: (contents-dialog (title "Unexpected problem") (text "The installer
has encountered an unexpected problem. The backtrace is displayed below. You
may choose to exit or create a dump archive.") (content "In
./gnu/installer/steps.scm:\n 150:13 19 (run ((substitutes . #f) (network
(select-technology . #< name: \"Wired\" type: \"ethernet\"
powered?: #t connected?: #t>) (power-technology . #) (# . #<)
???) ???) ???)\n 150:13 18 (run ((user #< name: \"root\" real-name:
\"\" group: \"users\" password: home-directory: \"/root\"> #<
name: \"alice\" real-name: \"Alice\" group: \"users\" password: ???)
???) ???)\n 150:13 17 (run ((services #< name: \"GNOME\"
type: desktop recommended?: #f snippet: ((service gnome-desktop-service-type))
packages: ()> #< name: \"Xfce\" ty???> ???) ???) ???)\n
148:23 16 (run ((partition #< name: #f type: normal file-name:
\"/dev/vda1\" disk-file-name: \"/dev/vda\" crypt-label: #f crypt-password: #f
fs-type: ext4 bootable?: #t esp?:???> ???) ???) ???)\nIn
./gnu/installer/newt/final.scm:\n 132:11 15 (run-final-page ((partition
#< name: #f type: normal file-name: \"/dev/vda1\"
disk-file-name: \"/dev/vda\" crypt-label: #f crypt-password: #f fs-type: ext4
bootable???> ???) ???) ???)\n 105:21 14 (run-install-shell \"en_HK.utf8\"
#:users _)\nIn ./gnu/installer/final.scm:\n191:5 13 (install-system
\"en_HK.utf8\" #:users _)\n 113:13 12 (call-with-mnt-container #)\nIn
gnu/build/linux-container.scm:\n 265:16 11 (run-container _ _ (mnt) _
# #:guest-uid _
#:guest-gid _)\nIn ./gnu/installer/final.scm:\n 222:13 10 (_)\nIn
gnu/build/install.scm:\n290:5 9 (unmount-cow-store \"/mnt\"
\"/tmp/guix-inst\")\nIn guix/build/syscalls.scm:\n 600:10 8 (_ _ _
#:update-mtab? _)\nIn ice-9/boot-9.scm:\n 1685:16 7 (raise-exception _
#:continuable? _)\n 1780:13 6 (_ #<&compound-exception components:
(#<&external-error> #<&origin origin: \"umount\"> #<&message message: \"~S:
~A\"> #<&irritants irritants: (\"/remove\" \"Device or resource busy\")>
#<&ex???>)\nIn ice-9/eval.scm:\n619:8 5 (_ #(#(#(#) system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or
resource busy\") (16))) #>
# ???))\n 626:19 4 (_ #(#(#(#) system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or
resource busy\") (16))) #>
# ???))\nIn ./gnu/installer/dump.scm:\n 58:4 3 (prepare-dump
system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or resource busy\")
(16)) #:result _)\nIn ice-9/ports.scm:\n 433:17 2 (call-with-output-file _ _
#:binary _ #:encoding _)\nIn ./gnu/installer/dump.scm:\n60:27 1 (_
#)\nIn unknown file:\n 0 (make-stack
#t)\n./gnu/installer/dump.scm:62:36: In procedure umount: \"/remove\": Device
or resource busy\n"))
Dec 7 12:14:01 localhost installer[198]: unmounting "/mnt/"
Backtrace:
2 (primitive-load "/gnu/store/s6a8v2l4387bgsp0w0pcbg4wjsy?")
In ice-9/eval.scm:
191:35 1 (_ #f)
619:8 0 (_ #(# #))
ice-9/eval.scm:619:8: Throw to key `marionette-eval-failure' with args `((quote
(complete-installation installer-socket)))'.
builder for `/gnu/store/wgw64jfyqrrg27afqmlj70a22d1mr5mv-installation.drv'
failed with exit code 1
@ build-failed /gnu/store/wgw64jfyqrrg27afqmlj70a22d1mr5mv-installation.drv - 1
builder for `/gnu/store/wgw64jfyqrrg27afqmlj70a22d1mr5mv-installation.drv'
failed with exit code 1
cannot build derivation
`/gnu/store/dr20sisps9rlpbq0vfzncdiyymrd5r0i-gui-installed-desktop-os-encrypted.drv':
1 dependencies couldn't be built
--8<---cut here---end--->8---
(From .)
Does that ring a bell, Mathieu?
Thanks,
Ludo’.
bug#48468: substitute server connection timeout
Hello, > /gnu/store/qmzr030rzgikdxv3g9msqv0l8qp5j6y2-btrfs-raid-root-os.drv, > which was marked as failed earlier today due to missing .drv. It’s a > 4KiB file, and the cache-bypass-threshold is ‘guix publish’ is typically > set to something much higher than that. So ‘guix publish’ won’t return > 404 in that case. Yes but that derivation also depends on other derivations, for instance qemu-minimal and if I try: --8<---cut here---start->8--- mathieu@berlin ~$ guix build qemu-minimal ... /gnu/store/lwv2pl0m6dkf6bkzip755w5p71g5akq4-qemu-minimal-7.1.0 --8<---cut here---end--->8--- and then, from my machine. --8<---cut here---start->8--- curl https://ci.guix.gnu.org/lwv2pl0m6dkf6bkzip755w5p71g5akq4.narinfo We're baking it: /lwv2pl0m6dkf6bkzip755w5p71g5akq4.narinfo --8<---cut here---end--->8--- wget exhibits the same behaviour and returns 404. So any build that requires a heavy substitute, heavier than the cache bypass threshold at least, will fail on the workers, as it would fail locally. That's not really a surprise as baking substitutes takes time and there is a time window between the moment Cuirass triggers NAR baking and the moment the NAR is baked, where every user will get a 404. Mathieu
bug#59823: an installer dump was sent
Hallo Mathieu, Thank you so much for your effort. I already managed the installation by burning the iso directly to my usb drive and not via Ventoy. Everything works fine. I should have try this in the first place. Sometimes the ways of the lord gnu are inscrutable. Big thanks again and a warm regards to you and your team. Typ. Mathieu Othacehe schrieb am Mi. 7. Dez. 2022 um 10:31: > > Hello, > > So I had a closer look and we do have this strange kernel warning: > > --8<---cut here---start->8--- > Dec 4 10:49:05 localhost vmunix: [ 1351.610773] device-mapper: ioctl: > remove_all left 1 open device(s) > --8<---cut here---end--->8--- > > I also noticed that we do not have the following trace: > > --8<---cut here---start->8--- > /dev/sdX is not eligible because it is the installation device. > --8<---cut here---end--->8--- > > which indicates that the "eligible-devices" procedure failed to identify > the installation device. So /dev/sdd could be the installation device > and the "with-delay-device-in-use?" always reports true because it is in > fact always in use. > > My proposed patch probably won't help and the question is, why is the > installation device not detected? > > Would it be possible for you to try the installation with an > instrumented installer that I would provide you with? > > Thanks, > > Mathieu >
bug#44924: guix build u-boot-pinebook --with-git-url failed due to "source" in C_INCLUDE_PATH
Hello, Maxim Cournoyer writes: > Hi again, > > Here's a v2, which guards against a #f native-inputs (when no > cross-compiling). Pushed to core-updates with commit 6454208222. Closing! -- Thanks, Maxim
bug#59823: an installer dump was sent
Hello, It's really good that you managed to install it anyway. Thanks for persevering :) Nevertheless we need to fix the problem. > I already managed the installation by burning the iso directly to my > usb drive and not via Ventoy. Turns out Ventoy was the crux of the issue here. Ventox allows to install multiple iso images just by copying them in a directory of the drive. It then creates a device mapping which look like that: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:00 238.5G 0 disk ├─sda1 8:10 512M 0 part └─sda2 8:20 238G 0 part sdb 8:16 0 14.6G 0 disk ├─sdb1 8:17 0 14.6G 0 part │ └─ventoy 253:00 842.9M 1 dm └─sdb2 8:18 032M 0 part This device mapping defeats our "eligible-devices" procedure. It's because the UUID that is passed as the root=xxx argument of the Linux command line is in fact related to /dev/dm-0 which is different from /dev/sdb. I had a look to the parted sources and it should detect mapped devices but for some reason it doesn't. Figuring it out and fixing it is maybe a bit risky before the release. So I'm trying to figure out a (cheap) way to make the correlation between /dev/dm-0 and /dev/sdb to exclude the latter in the eligible devices procedure. Any idea is welcomed! Thanks, Mathieu
bug#59864: emacs-guix
Hi, Amade Nemes Gmail skribis: > I've updated my guix version today and found that most emacs-guix > interactive commands no longer work. For example, guix-packages-by-name > throws: > > guix-geiser-eval: Error in evaluating guile expression: > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure package-license: Wrong type argument: # gnu/packages/abduco.scm:28 7f45f9d11f20> I think this is caused by an ABI incompatibility: the ‘guix’ package is currently at 1.4.0rc1, which doesn’t have the change made in: https://issues.guix.gnu.org/59390 However, current ‘master’ does have this change. The ‘emacs-guix’ package is built against the ‘guix’ package; it has inlined calls like (package-name p) to something like: --8<---cut here---start->8--- scheme@(guile-user)> ,optimize (package-name p) $8 = (let ((s p)) (if (eq? (struct-vtable s) (@@ (guix packages) )) (struct-ref s 0) (throw 'wrong-type-arg 'package-name "Wrong type argument: ~S" (list s) (list s --8<---cut here---end--->8--- But on ‘master’, is a macro, not a record type descriptor; thus, the (eq? …) expression is always false. I’ll fix this by upgrading the ‘guix’ package and/or merging the (guix records) bit in the ‘version-1.4.0’ branch. Thanks, Ludo’.
bug#59864: emacs-guix
Ludovic Courtès skribis: > I’ll fix this by upgrading the ‘guix’ package and/or merging the (guix > records) bit in the ‘version-1.4.0’ branch. Done in 81191e3410cc00c6438f532599dd0b96d521982f. Ludo’.
bug#59876: Bug.
Ping Pong writes: > Hello, Hello! > > My shell asked me to send this your way: > [...] > ./guix/serialization.scm:80:6: In procedure read-int: > ERROR: > 1. &nar-error: > file: #f > port: # > guix pull: error: You found a bug: the program > '/gnu/store/lzj46vv382in6axngwsjaaa2y96lss04-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "f57fbc2fb1b20823f433781d08047df5d7bc31df"; system: "x86_64-linux"; > host version: "1.3.0"; pull-version: 1). > Please report the COMPLETE output above by email to . Sorry for the failure and not helpful error message... I believe this usually was due to unstable internet connection, does try "guix pull" again fixed it?
bug#59846: "Running Guix in a Virtual Machine" documentation unclear/incomplete/wrong
Ian Eure writes: > I’m trying to explore Guix System by running it in a VM on my computer > which runs Debian. I’m interested in some of the Guix ideas, but not > ready to do a bare-metal install. Hello! > > I found the download page[1] and got a copy of the QEMU image, then > clicked "Installation instructions"[2]. These instructions didn’t > work, because they’re incomplete and/or unclear and/or wrong and/or > not really installation instructions in the way one might assume. > Since I don’t really know anything about Guix (which is why I’m > reading the documentation and test driving it in a VM), I’m not sure > which one-or-more of these it may be. Sorry for the not very helpful documentation, I'd say write good documentation is very hard... > > Specifically: > >> To enable SSH inside a VM you need to add an SSH server like >> openssh-service-type to your VM (see openssh-service-type). > > The documentation doesn’t say *how* to do that. The > openssh-service-type link[3] takes me to a large page of code > documentation for every possible networking service, instead of the > openssh-service-type one specifically. This documentation describes > *what* the service type and its many configuration options is, but is > silent on *how* to make use of it. This openssh-service-type should be added into the system configuration file, it's /run/current-system/configuration.scm in the pre-built qemu image or the file passed to 'guix system vm-image' when built your own image. The configuration file is a scheme (guile) file, the detail is in the section "10.1 Using the configuration System". > > It continues: > >> In addition you need to forward the SSH port, 22 by default, to the >> host. You can do this with >> $(guix system vm config.scm) -nic >> user,model=virtio-net-pci,hostfwd=tcp::10022-:22 > > I’m really not sure what this is supposed to be doing. It can’t run > on my Debian host, since there’s no guix command. It errors inside > the VM, since it can’t find a config.scm file; and I don’t see an > obvious config.scm file anywhere inside the VM that it might be > looking for. > > I *suspect* that this documentation is actually targeted at running a > Guix System VM on an existing Guix host. Which is a chicken-and-egg > problem, if I’ve already installed Guix, I don’t need to follow > instructions to install it. Well this 10.16 target both running a pre-built qcow guix system image and running a 'guix system vm' built one. But it's not self contained, as the service things lacking commands for the former as you reported, and the later case assume you already have guix installed (not the guix system though). Hope it helps!
