Hello Guix, I obtained a latest dev ISO for guix system and tried installing it just now. With the graphical installer, I received the error below for two times. Perhaps it's a bug? In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _#:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `match-error' with args `("match" "no matching pattern" #<package polkit@0.120 gnu/packages/polkit.scm: 54 7f6e64aa7b00>)'. Command failed with exit code 1. Press Enter to continue. Thank you for all your work! Best Regards, Jin
Hey,
Thanks for the report.
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `match-error' with args `("match" "no matching
> pattern" #<package polkit@0.120 gnu/packages/polkit.scm: 54
> 7f6e64aa7b00>)'.
I had the exact same issue while trying to build an installer
image. Running `make clean-go` and retrying fixed the error. Did you
build the installation image or downloaded it from the Guix website?
Thanks,
Mathieu
I downloaded it form the Guix website. If memory served me right, it was from https://guix.gnu.org/en/download/latest/ Jin
Hello everyone, Someone reported the exact same issue today on IRC [1], with polkit being the culprit. With a bigger backtrace, the match error happens at line 901 in guix/gexp.scm, in the match inside the return part of lower-inputs. This suggests that lower-object doesn't manage to return a derivation but only the polkit package. I suspect that this has to do with the complex polkit package interactions that we have, with polkit being an identifier syntax for either polkit-mozjs or polkit-duktape, with duktape package/inherit'ing polkit-mozjs with is itself replaced by polkit-mozjs/fixed. Maybe there's an interaction with the caching as well, while grafting and looping? I've tried to reproduce this locally by building a gexp that has either polkit, polkit-duktape or polkit-mozjs as an input, enabling or disabling fallback or grafting, to no avail. Maybe someone else has another idea? [1] https://logs.guix.gnu.org/guix/2022-04-22.log#154402 Best, -- Josselin Poiret
Hi! I hit this as well while running `guix system reconfigure' (unfortunately I didn't capture the stack trace). Re-running `guix system reconfigure' right after it had failed worked... So my guess is that it's a stateful issue, having to do with grafts: if polkit is not in the store, then we build/download it and fail right after that, which is why it succeeds the second time. To be continued... Ludo'.
Hello, The failing code is at gexp.scm:901:23, which corresponds to this: (mlet %store-monad ((obj (lower-object thing system #:target (and (not native?) target)))) 901: (return (match obj ((? derivation? drv) (derivation-input drv (list output))) ((? store-item? item) item) ((? self-quoting?) ;; Some inputs such as <system-binding> can lower to ;; a self-quoting object that FILTERM will filter ;; out. #f)))) That means (lower-object polkit) returned polkit (the package object) instead of a derivation, hence ‘match-error’. This is normally impossible: ‘lower-object’ calls ‘package->derivation’, which returns a derivation. But maybe something weird is happening when ‘build-derivations’ aborts to the build-handler prompt, or when the continuation is eventually resumed; maybe the object cache gets “poisoned” with an incorrect value during that process. So far the only reproducer we have seems to be along the lines of: grab the ISO, run ‘guix pull’ (if it’s the 1.3.0 ISO; if it’s a fresh ISO, that’s not necessary), run ‘guix system init’, watch it crash. Does anyone have a simpler reproducer? To be continued… Ludo’.
Hi! I did a complete install in a VM with an image built from commit 44f087fcc7b6ab48ff1381651ef3ea5e560f5216, and I cannot reproduce the error mentioned at the beginning of this thread: https://issues.guix.gnu.org/53594 The installation tests don't appear to hit it either: https://ci.guix.gnu.org/eval/832966/dashboard If we cannot reproduce this bug, I propose that we remove it from the list of release blockers at <https://issues.guix.gnu.org/53214>. Thoughts? Ludo’.
Hey Ludo,
> If we cannot reproduce this bug, I propose that we remove it from the
> list of release blockers at <https://issues.guix.gnu.org/53214>.
I haven't had this issue for a long time, seems fair to unblock the
release issue.
Thanks,
Mathieu