IRC channel logs
2026-08-12.log
back to list of logs
<abbe__>i straced guix system reconfigure and before it was 755, and after it was 700. and no where in 'guix system reconfigure' it happened. <abbe__>I'm wondering if it's broken for others too. for me it's started happening recently on all the hosts. <abbe__>at least it was not present on 3b98aa3889888dd1a69d30bed2a5f1a8519fd06c <abbe__>not sure, why it's manifesting now :( <ampinga>hello everyone, I need help. I try to install Guix System i686 but the installer has issue: when it boot there's a problem related to "waiting for partition '31393730-...' to appear" taking a long time and it start a guile REPL. How to resolve it please? <cnx>sneek, tell ampinga to check if there is a typo in the partition's uuid in /etc/config.scm <sneek>ampinga, cnx says: to check if there is a typo in the partition's uuid in /etc/config.scm <cnx>hmmm need i add a later <cnx>sneek, later tell ampinga check if there is a typo in the partition's uuid in /etc/config.scm <adanska>woah.. sneek doesnt want the snack.. <adanska>snubbed by sneek, refusing my snack, i sneer... <czan>Why does the function to say something to someone immediately even exist? Does it achieve anything meaningful over just mentioning them yourself (as your message has to anyway, to give the instruction...)? <cnx>for passive aggression i guess <sneek>Welcome back cnx, you have 1 message! <cnx>oh no it isn't scoped <qzdl>i think we need to add `-E no_copy_xattr' to the mke2fs call in `(@ (gnu build image) make-ext-image)' <qzdl>selinux xattrs can prevent builds of partition.img.drv, just like https://bugs.gnu.org/40043 / 53c594cb3f1f783fea18be6da23a863b00c14f5f; and genimage has this specced since 2f61b27d367d16cf9fd3f022cba27cf2c7c2a251 <folaht>sham1, I tried your suggestion, but I get another error from it. <sham1>You don't apply the result of calling service <sham1>folaht: try (list my-home-bash-service) <folaht>sham1, Oh right! I see it now. Thanks sham1. <abbe>by any chance, do other Guix users here have their /var/log chmod-ed to 700 recently ? <qzdl>abbe: my /var/log is 0755 (root root) on guix-sd <Deltafire>0755 here, by coincidence i was looking at the source code last night, these temporary directories are recursively deleted and recreated at boot with the specified permissions <Deltafire>so if it's not 0755 something weird is going on, or it's not guix system <Deltafire>heh, just checked - this is done for /tmp, /var/run, and /run, but not /var/tmp <Deltafire>think i was looking on the wrong computer.. on my linux box the permission for /var/tmp, /tmp etc is 01777 - which is what the installer sets it to <qzdl>possible to override guix's modules with only `--load-path'? i.e. `guix time-machine ... -- system image --load-path="${GUIX_CHECKOUT}/gnu.scm:${GUIX_CHECKOUT}/gnu" ...' <qzdl>(life is great with ./pre-inst-env, but am trying to fix build failures for another channel, with patched guix-checkout) <ggero>Hi, I'm trying to add fwupd-service-type to my system configuration, but with it included, reconfiguring fails with some sort of dbus error. I'm on commit 4c6ee97. The error is at https://paste.debian.net/hidden/48f95f16 but I'm not sure what help it would be. <ggero>If I remove the (service fwupd-service-type) line, the reconfigure works fine. <qzdl>does the `system build` succeed? <ggero>Do you mean the other derivations? <qzdl>as in, instead of running `guix system reconfigure' <ggero>No, it fails with the same error. <qzdl>i would try `guix gc --verify' to check the integrity of the store <qzdl>& are you on guix-system or a foreign distro? <ggero>Should I run that with sudo? <ggero>It output 2 lines and then exited with 0, I assume that means the verification passed. <abbe>qzdl: thanks for the reply. it used to be 755 for me, but i only recently here it started becoming 700, everytime i reboot. I noticed because one of the daemons failed to restart having no access to write its log files. <qzdl>ggero: yeah maybe try a `guix pull' and `reboot' for good measure; sorry idk more <ggero>A plain update hasn't done anything either, let me try to reboot. <abbe>I'm not sure why it's suddenly started happening now :/ <qzdl>abbe: did you see any 'activate' stuff in the strace? off the top of my head idk if those are even reachable from `--follow-forks' <abbe>nope, it's not in 'guix system reconfigure' strace <abbe>there it's only mkdir(...) = EEXIST <abbe>no {,f}chmod* of any kind <qzdl>maybe poor-man's bisect? if it's only occurring within last n days, do you have clean system generation to baseline against? <abbe>yes, i'll have to do that ultimately, if I can't find evidence from other folks. I was hoping if somebody else noticed it in their recent 'guix system reconfigure' <abbe>Deltafire: thanks. missed your response. <opalvault>New GUIX install. All data to one drive, encrypted partition. The boot process hangs after selecting kernel. Is this a known issue with encrypted installs? <opalvault>The automated non-encrypted option works fine. <ieure>opalvault, Do you have nVidia or other exotic video on this box? <ieure>I've heard of some folks with video issues that cause this. <opalvault>ieure hello! No, t440p with all libre-compatible firmware hardware. <ieure>opalvault, I'm not sure, then. I installed Guix on a T440p maybe 6 months ago, but it's running OEM firmware (with patches to disable the WiFi allowlist), not an alternate FW. <opalvault>ieure All good. I've read that it encrypts boot, so I'm going to try to enter the second encryption password again after the GRUB handoff. I have a suspicion that another prompt is hiding behind the GRUB overlay... <ieure>opalvault, What installer image did you use? You no longer have to enter the disk password twice, but that change landed after the 1.5.0 release. So if you used the 1.5.0 installer, you will have to enter it twice until you pull and reconfigure. <opalvault>That appears to be the version I grabbed from the Guix website. Thanks for the heads up! Is the pull and reconfigure something I would do post-install? Or do I need to do it during the installation process via another TTY? <ieure>opalvault, Yes, it's a post-install task. <opalvault>ieure Excellent! Thank you for your help. My suspicion was correct - the second password prompt was hiding behind the GRUB overlay after kernel select. I will pull and reconfigure ASAP. Cheers! <ieure>It'll take you a minute on that hardware. I love my T440p, but it's definitely showing its age these days. Particularly the 16gb max RAM. <opalvault>You are right, this is going to take awhile lol. I have 16GB and the i5 version so it's not the fastest but I think it's one of the higher spec'ed libre laptops you can configure to be libre-compatible. <ieure>opalvault, You can Libreboot a T480 these days. <ieure>opalvault, I've built two T440ps, max RAM, IPS LP-FHD panel, glass trackpad, etc. <ieure>First one I put an i7 quad in, but it ran hot as hell. Ended up selling it (not for that reason, just thinning things out). <ieure>Second one, I kept the i5 dual-core. But I have a top spec i7 quad sitting around if I ever want to scald my lap, I guess. <opalvault>ieure oh wow, I didn't realize they expanded the lineup of thinkpads you can libreboot. I might have to look into that, as I think the charging/battery mechanism in this t440p is toast. I did a similar operation to my t440p as you did sans the i7. I've been reading if the framework can take an atheros/libre wifi card. If so when my main laptop <opalvault>breaks I hope that can be an option. It wouldn't be librebootable but at least I could have a libre wifi card that would work with GUIX or Trisquel. <ieure>opalvault, The most common issue around what you mention is the battery suiciding because it discharged to 0%. There's a battery management system (BMS) IC inside it which will refuse to charge the pack if it completely discharges. Real hassle if you're into vintage machines, since the batteries discharge sitting on the shelf, unplugged. <ieure>opalvault, I've bought new old stock OEM batteries sealed in the original box, which didn't work because they discharged. Very annoying. <ieure>They're not really repairable, either. <ieure>Some people have done it, but it's dicey. You have to cut the pack open, charge the cells, replace the BMS, and glue it all back together. <opalvault>ieure TIL. Blegh. I've had that same issue as you - purchasing new OEM batteries that don't work. I didn't know the cause. That sounds like a giant pain but explains why I can't keep my batteries charged anymore. <opalvault>I'm reading they can also do the t580. How far Libreboot has come... <ieure>opalvault, I think most of the xx8x (X280, L480, E480, T480, T580, etc) machines can be LibreBooted now. <tarcv>Hi, all! Is there a way to download a file needed for a package when that file doesn't have a stable hash? It only has a stable hash if I remove some lines from it. (The file is GitHub diff, but I'm interested in a general case too). <vagrantc>not for something to incorporate into guix properly ... <vagrantc>but for a one-off project it might be possible ... <vagrantc>(for integratting into guix you would probably just want to download it once and register a patch if there wasn't a better way to solve the issue) <tarcv>well, yes, I want to incorporate the package into guix, into the main package set even. In this specific case the file is stable for a few days, then few lines change (though these line are not needed for the build) - diff files are generated with shortened git hashes and those change :( <bdju>Will guix be getting the 7.1.8 kernel in the near future? <vagrantc>tarcv: like i said, download it once and apply it as a patch... <bdju>Nice, glad to see work is started on it. <vagrantc>bdju: if you want to test it, substitutes are available for x86_64-linux already ... <vagrantc>bdju: i always appreciate more than my minimal boot testing :) <tarcv>vagrantc: you mean letting it go into a substitutor cache? But then it will not be reproducible without substitutors. <vagrantc>tarcv: no, i mean adding to gnu/packages/patches/ <ieure>tarcv, A computed-origin can do this. <tarcv>what I want to achieve is to download a PR from GitHub (so reviewers don't need to download and check for mistakes on my side when copying), then apply a backporting patch to it, and finally use the result to patch the package. I open to an idea that this whole approach is bad. <ieure>tarcv, I think your approach is bad. Instead of patching a base package, I would transform it so its origin points at the HEAD of the PR branch you want to build. <tarcv>you mean building the PR? Unfortunately it won't build as is - it depends on libraries not packaged in guix, including hard things like kotlin. So I take an earlier version of the package that mostly can be built and backport some PRs (they add support for newer dependencies in guix). <vagrantc>it's one thing to compute the origin from a known state ... <abbe>qzdl, ieure: found the culprit. it's the auditd service, not shepherd. restarting the `auditd` service resets the mode of /var/log to 700 :/ <tarcv>ACTION looking around the uses of computed-origin-method. `(sha256 #f)` - wait, you can do this? <sham1>Hum, apparently `nix` didn't have a substitute available. Interesting <sham1>Oh, nvm. Apparently it's just my channels that are out of date <ieure>tarcv, That's what it's for. <ieure>You can do it with a computed-origin, I don't believe you can do it with a normal one. <tarcv>ieure: thank you. It's an interesting tool, didn't know about it. Though, if understand it right, for my case it will require something that can download a file without checking a hash, while running in a sandbox. I don't think a PR doing this can be approved. This might be even a security bug if it is possible. <tarcv>I think I'll just download the diffs for now like vagrantc suggested. <vagrantc>if it is a ridiculous number of them, maybe that's not a great way ... <tarcv>vagrantc: ~17 of them, might have been worse :) And thank you for the suggestion, I tunnel-visioned into ignoring this way. <vagrantc>tarcv: ask someone else, probably get a different answer :) <vagrantc>i had a hair-pulling excercise trying to update ncurses, which distributes patch files for updates <vagrantc>they were at least a roughly systematic approach for the patch file names ... but i needed a bit of hand-holding from a freind to work out looping through them