IRC channel logs
2024-08-30.log
back to list of logs
<amano>It seems ARM and RISC-V are a lost cause. None of them supports arbitrary linux distributions. <jaft_r>amano: also worthy of note (in case you don't know), you can check if a package has a substitute available through "guix weather"; I've definitely waited or used "--do-not-upgrade" when I've seen that a sub. wasn't yet available and used "weather" to tell when I didn't need to do that, anymore. <Endless>I have a severe problem that hopefully has a simple fix. I did a `guix system reconfigure` with a breaking change to my xorg, defining a bad command. Now it freezes before it can even load the loginscreen. I can work around this by starting on a previous instance (as I am now), but when I do that, even a fresh system reconfigure without the bad <Endless>line updates THE CURRENT system definition, leaving the main definition (which would be started by default) still broken. <Endless>How can I fix the configuration of the broken (primary) instance? <Endless>I have a hunch that timemachine can somehow help me, but I have never understood how timemachine works <ieure>Endless, `guix system roll-back' will revert to the previous system configuration. <ieure>This has worked for me in cases where I've horked up my system config. <Endless>Can I read whatever my system.scm is for that rolled back thing? <Endless>and do I have to be on the broken branch for that to work? <Endless>(I'm afraid that I did not know about the issue immediately, as I don't restart that often) <amano>I guess I will just avoid ARM and RISC-V until they allow generic OS images. <jaft_r>Does Guix support specifying channel priority, any? <amano>Can a channel depend on another channel? <pfd>Endless, it reads as though you're using Guix System as opposed to Guix on top of GNU/Linux or Linux; correct? <Endless>pfd that is right; I am a long-time GUIX System user <Endless>With a new apparent issue where I tried to add "options" to my xorg config, with disasterous consequences <Endless>I've actually never used `guix home` stuff. I've always done `sudo guix system *`. Is there a significant difference? <pfd>Endless, good for you! I'm envious of those who have hardware that works with GUIX System. <pfd>As for your xorg config adjustment(s), I wonder if you also had any Wayland components installed that <pfd>may have contributed to the mess. <pfd>Obviosly it's non-trivial or near impossible to access your files in this case. <jaft_r>Thanks, amano, but that's not quite what I mean. I mean that, if I add two channels and they both have a package by the same name, can I tell Guix which package to prefer. The channel dependency looks like it just makes sure to require another channel if one channel lists it as a dependency. <jaft_r>Btw amano, tried out the PantherX package manager (just now) and it's a pretty nice view of possibilities. Not thrilled about the UI (though that may be, in part, from it using QT while I prefer GTK) and some icons missing (probably because I don't have one of their icon packages installed or something) but it lists out packages with their icons and a short package description. <amano>jaft_r: You can use gnome on pantherx. <jaft_r>Clicking on a package even offers screenshots of the app. It's even able to parse my system profile's config. and inform me there's an update available for, specifically, nss-certs. <jaft_r>I know but I think the software manager, specifically, uses QT. I didn't see a package version of it without QT inputs. <jaft_r>I've, kind of, wanted to take a whack at writing a GUI package manager for Guix for a while; once I get employed, again. Wasn't sure how to get some of these features working, though. <amano>I think I'm going to forget about ARM and RISC-V until they accommodate arbitrary OS images... <Endless>pfd I don't think I have Wayland involved; I am normally an ExWM user, which doesn't support anything but xwindows. I believe the issue from my system-config.scm was here: https://pastebin.com/xhL2iUJZ <Endless>so it's just one line, and I'm pretty sure I'm working except for that <Endless>but I'm not sure the best way to get rid of that <pfd>Wow! In that case I feel for you. I suppose some infrastructure is risky to adjust or hack in any way; unless everything is backed up; etc. <pfd>I suppose you don't have another system and a way to 'dock' your HDD or SSD to see what you can access to copy. If you do everything in Emacs, email org-mode, then I suppose you'll have to proceed cautiously and methodically; assuming you back everything up and start over. <pfd>Endless at this point I assuem it boots up, and perhaps you can login at another TTY term at the command-line, to access copying or undoing the edit you made, provided that edit didn't trigger a cascasde of changes. <pfd>Endless, I know if it were me I'ld just copy my whole account to an external USB or whatever, wipe and start over. <Endless>No, the system freezes at the login prompt, before I can do anything. Unless I told it to start with an older version, as I have now as I write this. But I need to either make the profile system I've chosen permanent, or figure out how to edit the lead profile. <Endless>(this is demoralizing because the system I'm on was just installed last week, and has some significant data changes) <Endless>it took me an annoying amount of time to get guix installed and working (following the System Crafters installation instructions so my wifi would work) <Endless>I'm explicitly looking for an alternative to reinstalling all of guix. I'll try the rollback if I can get to a TTY <Endless>I'll hopefully see you all on the other side... <amano>pfd: The strength of gnu guix is the single config file. You should have asked Endless to give you the config file. <amano>Then, you can replicate the setup. <amano>Or, you can spot some flaws in the setup by just looking at it. <amano>By the way, does guix have services for managing symlinks or synchronizing directories? <jfred>anyone know a quick way to export a home environment with `guix archive`? I know there's some way to do it since you can pass an expression to it, but I'm having a hard time figuring out the expression I need there <jfred>(I've build a home environment on one machine that I'd like to export to another, much slower machine) <amano>jaft_r: I think it's not a bad idea to start with pantherx if you want an installer that contains proprietary drivers. <mange>jfred: Can you "guix home build" your config, then "guix archive --export --recursive" the resulting store item? <jfred>mange: oh! whoops, yes, I didn't realize 'guix archive' could take paths to store items as arguments and not just package names. thanks! <pfd>Oh so Endless was/is using SystemCrafters' distro which installs and uses both nonguix and guix repos, which I found trecherous treading myself. I tried it but didn't enjoy the experience. I instead am waiting for when I can afford to get either Raptor Engineering to build me a workstation with decently current but correct hardware <pfd>components, or order/find all the parts to built it myself. I don't think a machine with coreboot or a libreboot'ed machine is the best way to go. Even if Guix System (pure) boots that's only part of the battle. For now I'm happy enough using Guix on top of Debian, and here, added to this OpenSuse system. I frankly also have one box <amano>pfd: What's wrong with systemcrafters guix? <pfd>I just seemed like nonguix and guix were in conflict. Maybe I'm wrong, I seem to recall the same updates getting pulled and a lot of time wasted in negotiating which repo gets priority. <amano>You can't set repo priority? <amano>I am going to add multiple channels. <pfd>Maybe I'll give David's most recent build a try. <pfd>amano I haven't tried settig reop priority. I'll educate myself on the subject. Thanks! <amano>pfd: Don't wait for raptor engineering. You have purism now. <pfd>amano, I'm aware of purism, but I want to build a desktop. I don't want it on a mobile or server blade. Maybe a server blade; but if so I can build it myself. <amano>pfd: There's also system76, but buy intel CPU computers from system76. <amano>Their AMD computers have AMD PSP. <pfd>So, Guix System installs OK on System76 coreboot machines? <amano>Coreboot is just UEFI or BIOS. <pfd>I'm asking if you've tried it. <pfd>Yeah, that's why I'm asking. <podiki>please note: non-free is off topic for this channel, please discuss those in their respective places instead <podiki>(re: those other channels earlier) <amano>I haven't heard of any problem with linux on coreboot systems. <pfd>OK Thanks for your perspective and suggestions. I like LXQt so I will give PantherX a whrl amano! <amano>LxQt isn't the only dekstop environment supposrted by PantherX. <pfd>OK. We better stop this discussion as per podiki. <podiki>no one is coming for you! just a gentle reminder :) <podiki>(and you'll probably get people that know more about them there anyway) <amano>pfd: Coreboot comes with either BIOS or UEFI. <amano>If you deviate from BIOS or UEFI, you cannot boot x86 computers. <amano>pfd: And, make a lot of money before you buy computers. <amano>Is there a way to unlock a luks device with a key file during boot? <amano>On gentoo linux, there is an init service for doing that. <jmes>Has anyone attempted to write a build system for npm software? I usually avoid npm, but there's one bit of software I'd really like to use. <mange>Have you seen the npm-binary importer? "guix import npm-binary --help" might tell you more. I haven't used it, and packages it generates won't make it upstream, but it might do in a pinch. <jmes>mange: I have not! I'll look at that now, thanks a bunch. <amano>Or, can I unlock two luks devices with one password? <jmes>ACTION finds the node-build-system in the guix tree <amano>I guess it is not possible now. <robin>ACTION has a talos machine waiting for memory/storage/psu, hasn't decided whether to go with debian or guix yet <robin>i haven't seen any clever tricks to reduce luks password-typing with guix, though they're possible in theory, of course <robin>could be interesting to do it with a solo key or similar <amano>keyfile for luks-device-mapping-with-options has to come from somewhere. I don't know how to provide keyfile. <amano>Okay, keyfile can come from root file system mounted on initial ram disk. <apteryx>Rutherther: hm, I think I meant to try 'guix system reconfigure' rather than 'init', as init nukes /var/guix and also errors attempting to write to /gnu, which is ro <apteryx>perhaps it'd had completed by taking care to stop the gnu-store.unit or something to make it rw first, but reconfigure is probably what I want <apteryx>luckily I took a btrfs snapshot of the whole / prior trying, so I'll reboot on it and try anew <apteryx>ACTION is attempting the 'mutate a live foreign distribution into Guix System' trick <apteryx>nckx: dear IRC topic updater, I think the segfault was fixed by civodul ^^ <amano>Does guix support root filesystem on btrfs raid1 on two luks devices? <amano>I guess that's going to require a custom initial RAM disk unless I modify gnu guix. <robin>amano, will it? i thought you could just mount one btrfs device and it'd detect the other with btrfs raid <robin>(but i haven't used btrfs raid myself) <amano>robin: You have to unlock two luks devices first. <amano>That requires a custom initial RAM disk. <amano>I want to unlock two luks devices with one password. guix doesn't support this. <robin>oic. yes, that'll require tinkering <robin>which would probably be much appreciated by other users <amano>Would you put root filesystem on btrfs raid1 or plain btrfs? <robin>(another boot-time thing i haven't seen work on: supporting secure boot via "shim" or similar) <Endless>well, on the plus side, mission successful! I booted into a virtual terminal before it came up and did a `guix system reconfigure` and got the xorg line out of there and fixed by xorg display. <Endless>new show-stopping issue: during my debugging and the false thought that it was the kernel, I switched to the default kernel -- which meant that my non-free wifi driver went away. Without wifi, I cannot be productive even after a successful boot. Any hints as to how I can get my wifi working again on my latest branch? I feel caught in a <Endless>catch-22 where I can't reconfigure to fix my wifi because I have no wifi. <amano>robin: secure boot is a waste of time. Just protect your machine from physical access. <robin>amano, i use plain btrfs but my main machine is simply a workstation that could be easily restored... <Endless>amano I learned that the hard way. Secure Boot made my life tough. Hard Agree! <robin>amano, yeah, i worked on it a bit but gave up after i realized the scope, no evil maids in my apartment :) <amano>I actually set up secure boot, but I felt it was an overkill for very little benefit.... <Endless>me too. And un-setting it up was scary <amano>Unless you put your machine in a public environment, no one is going to fiddle with it. <amano>On the other hand, full-disk encryption protects you from police confistication. <amano>They might charge you with having pirated movies on your storage devices. <amano>If you are really worried about someone changing /boot, you should verify the contents of /boot during boot. <amano>Verifying /boot is better than secure boot. <amano>Perhaps, I should just use plain btrfs on luks for root filesystem. <amano>Does guix support encrypted bcachefs? <amano>I guess I will just write a custom initial ram disk for unlocking bcachefs file systems. <robin>amano, wouldn't you just need the kernel module compiled in/loaded early enough? and a bcachefs filesystem "type" if one doesn't exist? <antlers>i happen to have been up late working on my own configs file-system records and decl partitioning scheme, but having re-approached FDE and Secure Boot on Guix a dozen times, it's no surprise <antlers>also eyeing a custom ramdisk, but was able to monkeypatch the exiting one well enough for now <antlers>exited to see the boot-loader rework someone's been cooking up on the mailing-list c: <antlers>looked it up in my public config, but i was working with plymouth at the time (on top of FDE/SB) and it's frankly a lot -- hence still working on it 😬 <antlers>dm'd links for full context (could be off-topic?), but would be glad to field related q's or hear about pursuits in this area any time ^u^ <kaij>have there been thoughts into adding a kind of update check to packages, where they could report being out of date from the source? Seems like quite a lot of packages are just git + v prefix + version number. should be trivial to check with a tiny amount of extra def per package. Something like `(latest-version (latest-git-tag-prefix "v"))` <Rutherther>apteryx ah, I see. Since the init is made to write other disk drive that has not yet touched guix it makes sense that it errors on writing to /gnu. I don't think it can stop or that you could stop the guix daemon since it's using that for the build... :/ I would be afraid reconfigure also won't work if your system is not guix in the first place <civodul>kaij: hi! ‘guix refresh’ and ‘guix lint -c refresh’ do that <Rutherther>also if you want latest without updating source there is transformation --with-latest <kaij>just read the docs, that is awesome! thank you! I keep discovering awesome new features like this :) <civodul>cbaines: hey, any thoughts on the ‘core-updates’ merge? <nckx>I restarted mumi on berlin. I kept getting 500s. <nckx>I still regularly get the Fortigate injection, too. <fnat>I don't seem to be able to convince 'xdg-open' and 'xdg-email' to use 'emacsclient' (instead of a new Emacs session) when composing an email message. <fnat>I see I've got some 'emacsclient-mail.desktop' files in the Store, so I thought of using that: <fnat>(home-xdg-mime-applications-configuration (default '((x-scheme-handler/mailto . emacsclient-mail.desktop))) ...) <fnat>But it doesn't seem to be picked up by any of the xdg tools. <fnat>Adding a desktop entry with the same name also didn't seem to help. <nckx>apteryx: I added it after the fix to tell users to roll back && pull. The first part wasn't obvious to everyone, or at least people still reported being 'stuck'. <esnos>Do you know when will be guix 1.5.0? <cbaines>civodul, I'm not quite sure if it's changes pushed to master or core-updates, but it looks like substitute availability is not that great at the moment <cbaines>I also haven't looked in to QA complaining that the merge base is an unknown commit <civodul>cbaines: oh, it was very good yesterday <cbaines>I've got a change to fix the ungoogled-chromium source, so I can look at pushing that today as well as rebasing <civodul>cbaines: great, let’s wait for this change then <amano>Does anyone know how to put root file system on btrfs raid1 on two LUKS devices? <amano>btrfs raid1 could be loaded by using file system label, but I don't know how to open two LUKS devices with one password during boot. <amano>How can guix unlock LUKS devices with a keyfile on root filesystem on yet another LUKS device? <amano>luks-device-mapping-with-options accepts keyfile, but I don't know how to make a keyfile available for mapped devices. <jadzi>Hi, i want to install a stumpwm module as a guix package, sbcl-stumpwm-screenshot in this case. I'm confused with it's dependencies' installation. This package depends on sbcl-zpng, which depends on sbcl-salza2. When I call load-module in stumpwm (with *load-path* having /home/myuser/.guix-profile/share/common-lisp/sbcl) it failes with an error about missing zpng. Indeed there's no such module in the profile's sbcl directory (tho <jadzi>is present in /gnu/store). So it seems i need to guix install sbcl-zpng manually -- but after that i'm getting an error about next dependency, which is salza2. Is there a way to install all dependencies of a common-lisp package to be loadable altogether? Thanks! <nckx>jadzi: <Iit seems i need to guix install sbcl-zpng manually> That would be strange. I don't know the first thing about CL, but why don't the symlinks in $(guix build sbcl-stumpwm-screenshot)/etc/common-lisp do what they're presumably supposed to? Does installing sbcl into the profile (and removing zpng, salza2, any other cruft) help? <apteryx>Rutherther: haven't succeeded yet, though it came close. Guix System reconfigure would be unhappy about file conflicts such as PAM under /etc, and getting them out of the way proved challenging (locked me out of sudo) <apteryx>perhaps it could have worked from a chroot, but I'm now trying something different: prepare the raw image and unpack it directly to the /dev/sdb from the OVHCloud rescue environment <apteryx>it'd have been nice to use 'guix' directly there, but there's not enough place and 'guix system init' wants to add stuff to its store so it grows up past the storage capacity of that rescue environment (a 1 GB free space at best) <nckx>ACTION deletes some typed stuff. <nckx>[Why] can't you cow-store to the target partition? <Rutherther>the target partition is their root partition they are currently booted in. But I also don't really know why they don't boot into a live iso <nckx>These rescue environments are often a live ISO or equivalent, and I doubt the target partition is the 1 GiB they are talking about. <nckx>I've installed Guix System on a few VPSes this way but I don't remember how I did it on OVH. Frustrating thing is, I have. <nckx>It was quite a while ago and the VPS has been gone for years. <apteryx>nckx: cow-store? sounds good. I'm rusty. <nckx>Zomg are you not RTFM‽‽‽ <apteryx>are the cows available outside of the installation image? <nckx>Rutherther: The joke is that apteryx is a maintainer :) <apteryx>the rescue is some distro I don't know about; I can't boot my own image. <nckx>apteryx: No, but you can emulate it by hand. <nckx>Bind mounts are neat and cool. <nckx>But yeah, not saying it's trivial, but it can be done. <apteryx>I'll try it next if my current idea fails <apteryx>my image, compressed with zstd is 418 MiB, so it'll fit in the rescue, and can be decompressed and dd' to the target device, that's the idea <nckx>Is it really a partition, by the way? If it's tmpfs, you can buy a few gigs with -o remount=SIZE, maybe after swapon. <nckx>apteryx: I see. I always ‘guix system init’ out of habit but images sound like a good replacement. And the kids love 'em. <apteryx>that's the rescue root: /dev/sda1 2.9G 1.8G 953M 65% / <nckx>They give you a real drive partition? Crazy. <apteryx>I had to remove a few dpkg packages to get to that space <nckx>Speaking of feeling old, I finally upgraded bcachefs-tools past the Rust horizon. My first real Rust package, I think. Took a lot longer than it should have because the Makefile does ‘find . -name *.c -compile’ and guess what a lot of crates include. Wild. <fnat>(My mumi+xdg+email configuration was fine. 'mumi compose' opens a web browser when no ticket has been selected with 'mumi current NNNNN'.) <apteryx>this seems tohave done it: zstd -ck ovh.img.zst | dd iflag=fullblock oflag=direct bs=4M of=/dev/sdb <apteryx>will it boot? in the next episode... <apteryx>it doesn't mount, so I guess it won't boot... <apteryx>I mean, I don't see the partitions; perhaps I need to reboot to see them <nckx>Dammit. Rutherther: I failed :( <nckx>kpartx or… the other one. <nckx>Should work if no sdb partitions are ’busy’, but since you just wiped the entire thing, I'd hope they aren't. <amano>Hmm, mapped-devices passed to operating-system is somehow available as mapped-devices symbol for file-systems of operating-system. <apteryx>seabios is for BIOS, not UEFI, right? <amano>All those mapped-devices seem to be loaded by raw-initrd. <nckx>apteryx: AFAIK, unless I missed some big news. The UEFI equivalent is Tianocore. <jadzi>nckx: <Does installing sbcl into the profile (and removing zpng, salza2, any other cruft) help?> <jadzi>Thanks a lot for your help! Installing sbcl into the profile has solved the problem <nckx>Yay! There might be a good reason that it's not the default, I don't know. <nckx>However it's a common pattern in Guix that the consumer of search paths (everything from LIBVA_DRIVERS_PATH to EMACSLOADPATH to MANPATH to… ad nauseam) is what actually ‘activates’ them. Why e.g. ‘guix shell hello -- man hello’ doesn't work, even without --pure, until you also add ‘man-db’, even though your own ‘man’ works just fine. <nckx>Has to be the same profile, too. <jadzi>nckx: thanks i didn't realize such common pattern exists, but yeah, i've faced such man issue and was usually altering MANPATH) <jadzi>Though i see that guile modules have guile as their dependency (mb because there's no guile-build-system) <amano>How does file-systems of operating-system have access to mapped-devices of operating-system? This is not a documented behavior. <amano>What's the exact default initrd? <civodul>cbaines: do you want to take care of rebasing (+ merging)? <apteryx>ah, the mbr-raw image is a single partition at some offset <amano>I am reading guix codebase, and the undocumented behavior for initrd of operating-system boggles my mind. <amano>I read it, but that doesn't explain how mapped-device is a useable symbol for file-systems of operating-system. <amano>The trick is I should not pass mapped-devices as dependencies to the root filesystem because not all mapped-devices are required for mounting root filesystem. <apteryx>not sure why the copied mbr-raw image to a physical disk is not bootable; but its partition can be mounted like: mount -o loop,ro,offset=1048576 ovh-mbr.img /mnt/ <Rutherther>amano so put only the actually required ones to dependencies of the file-system record... <amano>Rutherther: Do you know where mapped-devices symbol is defined? <amano>My best guess is that a record field can access another record field by symbol name, but I haven't learned guile scheme, yet. <Rutherther>mapped-devices is just a field of operating-system <amano>When you set the value of a record field, can you just use another record field by symbol name? <rekado>civodul: libcamera is still broken on aarch64 <Rutherther>there are usually functions exposed to get you the field. Like "type-field". But I don't know how it's useful for your problem <rekado>(I've just tested with commit 013741f4a1d97d150de351ad0094a60e91e49bfa) <amano>That must be mapped-devices record field in operating-system? <Rutherther>right, when you assign record fields you can refer to them in the body of the record initialization later <amano>That's guile scheme? Or, R5RS? <amano>luks-device-mapping-with-options with key file is not in a public release, yet. <amano>Does that mean I have to wait until 1.5 is released if I want to open LUKS devices with a key file? <graywolf`>What you mean public release? Guix is rolling, it is on master, and I am using it for long time <Rutherther>what do you mean by public release? 1.4.0? guix is rolling, so I don't know why that would be important <amano>I thought I was supposed to stay on releases... <graywolf`>Use 1.4.0 to do the initial install and update right away <graywolf`>Releases in guix (afaik) are just somewhat-better-tested commits. There is no further maintaince done on them or something like that. <graywolf`>So use the release for installing Guix system, and guix pull to get the latest master <amano>Is there a way to open two LUKS devices with one password before guix mounts root filesystem on btrfs raid1 on two LUKS devices? <graywolf`>Currently no. FWIW I did not figure it out on Alpine neither and just enter the password twice (to unlock mine RAID1 root). <amano>I just inserted a custom bash script in dracut on gentoo linux. <graywolf`>Sadly having /boot on encrypted RAID1 is somewhat niche it seems :) <amano>My bash script reads one password and opens two ZFS pools. <civodul>rekado: oh, even after the latest commit? <graywolf`>I mean, it *should* be possible in Guix, pretty much anything is. But there is no built-in support and I have no idea what to do it <amano>graywolf`: If your /boot is encrypted with LUKS, then grub can open /boot with a password, and initial RAM disk on /boot can have a keyfile which can be used to unlock all other LUKS devices... <amano>I just don't know how to put a key file in initial RAM disk. <Rutherther>so just put the key to filesystem where you have /boot, then you don't have to put it to initial ram disk <amano>grub reads /boot, but guix doesn't. <amano>Guix starts in initial RAM disk. <graywolf`>amano: For getting the key into ram disk you can use extra-initrd field. There is example in the manual. <graywolf`>In my case the /boot itself is on encrypted RAID1, so to even get to the ramdisk grub asks me for two passwords (one for each drive in raid). <amano>I can't find "extra" in manual. <amano>graywolf`: That's a real pain. I only want to type a password once. <amano>How is encrypted raid1 implemented on your system? <graywolf`>I have two drives. Each has encrypted partition via LUKS, and both partitions (after unlocking) are added into BTRFS in RAID1 profile. That filesystem serves as my /, and it includes /boot (since I do not have separate partition for it). <amano>I don't know how extra-initrd works.... Does it insert a file into initrd? <graywolf`>Yes. There are some limitations, but in practice grub handles it fine. <graywolf`>Search the docs for `cpio -oH newc`. It gives example how to use it. <amano>I guess that's why limine bootloader just doesn't support encrypted /boot. <graywolf`>Yeah it means that bootloader (GRUB in this case) needs to understand both LUKS and BTRFS. I guess there is a reason why it is named GRand Unified Bootloader. It can do a lot. Some even say that it can do too much :) <amano>I wish I could open two LUKS devices with one password for root filesystem on btrfs raid1. <graywolf`>If you can live with /boot not being on raid, is should work I think. <graywolf`>You could put /boot into separate partition (encrypted), unlock it with one password, and then use the extra-initrd and luks-device-mapping-with-options to unlock the raid1 root partition. <graywolf`>Never tried it, but I *think* that should work. <Rutherther>keep in mind guix stores kernel and initrd in /gnu/store <graywolf`>Yeah, that is why extra-initrd is a thing. You build it by hand (cpio) and store in /boot with 000 permissions :) <graywolf`>So the encryption key is never stored in the store <Rutherther>sure. I am just saying that what you are suggesting will work only as far as /gnu/store is somewhere else than on that encrypted raid partition <amano>You said grub supports encrypted btrfs raid1. <graywolf`>Uh, isn't the initrd copied into /boot from the store? <Rutherther>no, it is not, it's taken from /gnu/store upon boot. So /gnu/store has to be mounted for grub to be able to boot <Rutherther>see cat /boot/grub/grub.cfg, every entry of linux an initrd points to /gnu/store <amano>So, /boot and / need to be on the same partition if I want to encrypt /boot on LUKS? <Rutherther>what do you mean exactly by /boot? what do you expect to be on /boot? <graywolf`>Oh interesting. I did not know that. TIL. Thanks. <amano>I don't know what /boot looks like on guix. <amano>I'm on gentoo linux right now. <civodul>rekado: /gnu/store/0bgh4gvjp8x6ikq52ni2w9rsy8jp898p-libcamera-0.3.1.drv builds fine on the overdrive <amano>So, that means there is no point in having a separate /boot partition. <ieure>amano, It's required for the BIOS to boot the OS. <Rutherther>yeah, BIOS won't be able to unlock your root partition where you would have /boot if it's encrypted <ieure>The BIOS has to load the GRUB UEFI payload, that gets stored on /boot. Without that, you cannot boot anything. <ieure>You will simply have to take it on faith when I say that /boot is required. Or you can remove it and find out for yourself why. <amano>Do I need a separate /boot partition? <Rutherther>you need an esp partition that will have grub and efi entry to grub, that's what we call /boot. Where you mount it in your system doesn't really matter as far as you make sure to point to it properly, but most people just use /boot <amano>UEFI payload is actually stored in /boot/efi on my gentoo linux system. I have a separate partition for /boot/efi. <ieure>You are confusing the generic term "BIOS" (meaning the primary system firmware) with "legacy BIOS," which is a boot method. The BIOS has both legacy BIOS and UEFI boot support. <amano>I also have a separate /boot partition. <amano>You guys were talking about EFI partition. <ieure>I know what we're talking about. <amano>So, I need an EFI partition. I know. <Rutherther>so what do you have in /boot that you want to know about? I've asked you and you just said you don't know what is on guix in /boot... <amano>Can grub read /boot/grub/grub.cfg if it's on encrypted LUKS partition? <amano>Or, grub reads /boot/grub/grub.cfg after I type a password? <graywolf`>Grub asks you for a password, decrypts the partition and read the grub.cfg <amano>Can I force ESP on /boot/efi? <Rutherther>graywolf` oh, so it can be on different partition? sorry for the misinformation then. <freakingpenguin>Anyone know if there's a plain-text english dictionary packaged in Guix? ispell-complete-word can't use the Aspell one since that isn't plain-text. <Rutherther>you can use whatever you want, just don't forget to change it under operating-system record <amano>graywolf`: You can type a grub password only once and unlock any number of LUKS devices with a keyfile. <graywolf`>Yes and no. GRUB asks for passwords for all partitions that are needed to get to the config file. So if, in my case, the /boot/grub/grub.cfg is on raid1 where both drives are encrypted, it asks for two password, one for each drive. <graywolf`>I am sure that can be solved, I just never got to it. I reboot rarely, so meh. <Rutherther>but I think if you stored the key on the drive, it could get taken from there <Rutherther>you unlock it once with password, get access to the keyfile, and the second then can be unlocked with keyfile <graywolf`>In theory yes. In practice I did not really manage to do that in the amount of time I was willing to spend on it. <amano>If you just make /boot EFI partition, then you can just type a password once. <graywolf`>EFI partition needs to be non-encrypted. So you cannot store the keyfile there. <amano>The keyfile can be in /root or / <Rutherther>you will need to get these partitions: the one with grub.cfg, and the one that has /gnu/store. So depending on where you keep these that's how many passwords will be needed <amano>The key file will be in initrd. <Rutherther>that's something else, that's after grub is able to find those files and actually boot <amano>initrd will be in root filesystem. <Rutherther>it will be in /gnu/store, that can be in root filesystem, but doesn't have to be <amano>Grub knows how to open initrd in an encrypted btrfs raid1 on two LUKS devices with one password? <graywolf`>You will actually need two initrds, the one in store cannot have the keyfile :) <graywolf`>`Grub knows how to open initrd in an encrypted btrfs raid1 on two LUKS devices with one password?` no, with two passwords, as I said originally <amano>I guess root filesystem on btrfs raid1 on two LUKS devices is difficult. <Rutherther>you could just keep /gnu/store somewhere unencrypted, it's not supposed to have any secrets anyway <graywolf`>You probably could have a "vault" encrypted partition to store just the keyfile and write custom grub entry to unlock using keyfile from there <amano>I will think about it later.... <graywolf`>`it's not supposed to have any secrets anyway` true, but I have to say I still sleep better at night when as much is encrypted as possible <graywolf`>Well this was interesting, I should probably get back to work :/ <graywolf`>Looking forward to the core-updates merge :) <Rutherther>yeah. I also keep it on encrypted partition, and I will try to make guix bootloader install script copy kernel and initrd to /boot which I will not keep encrypted so I won't have to put in any passwords to grub <amano>What's the simplest way to have encrypted root filesystem on one LUKS device and two LUKS devices? <amano>I will come back to check the log. <Rutherther>yay, got arm-none-eabi toolchain with gcc-12.3 finally working, able to compile qmk. Though I am still struggling with including libstdc++ <ekaitz>Rutherther: how did you make it work? <rekado>sneek: later tell civodul oh, good to know that libcamara (aarch64) built on the build farm. Perhaps these two test failures are due to me building via the binfmt qemu thing. <pjals>Hello, I have a generation in my generations list with the bootloader label #f. Guix attempts to generate the bootloader menu but it cannot because #f is not a string. I try a rollback but it still considers the generation existant, how do I resolve this? <pjals>The generation with label #f is the current booted generation so I don't think I can safely delete it. <Rutherther>remove the generation with guix gc, and then reconfigure <pjals>Wouldn't the booted generation be a busy GC root? I can try though <pjals>I can't restart the system because the main sysadmin is sleeping or something <pjals>(i can restart, but can't choose boot option) <Rutherther>hmm, but was boot option created for it? I would expect not since the label is #f and that errors on "not a string" <pjals>Is there some sort of "super expert i know what i'm doing" mode for guix gc? <Rutherther>the problem is that the generation is actually used, so you cannot gc it <pjals>Rutherther: Don't ask me how I did it. When it succeeded sudo started segfaulting so I needed to ask the main sysadmin before they went to restar tthe system <pjals>I don't think guix checks the label before it's too late.. <ekaitz>Rutherther: yes I was meaning about the toolchain... just made a package with QMK or you were working on a shell with it? <pjals>There needs to be an ohshitgit.com -style website for Guix ;) <Rutherther>pjals have you tried guix system switch-generation to a previous one? if that won't work. What about --no-bootloader option, maybe then it won't fail? the docs mention guix reconfigure supports this option. So you could switch to a new generation, and then gc the broken one <pjals>switch-generation still tries to serialise the current generation, and I'm pretty sure --no-bootloader still tries to make a boot-parameters from the system.. let me try <Rutherther>but I am not really sure either of these would work. If the problem is the sysadmin is not available so cannot switch which entry to boot to you could also use something else than guix commands to change default boot entry in grub. Though of course if you mess something up it will be unbootable :/ <pjals>Are you sure I'll be able to boot if I use --no-bootloader? <Rutherther>that just means to not touch the bootloader. So it won't create new entry <pjals>The problem is that includes the current booted system: It also adds a bootloader menu entry for the new OS configuration, —unless --no-bootloader is passed. For GRUB, it moves entries for older configurations to a submenu, allowing you to choose an older system generation at boot time should you need it. <Rutherther>the point is to just switch to generation without unbroken boot-parameter, and gc the old one <Rutherther>okay, then I am out of ideas except for the one with manual grub entry changes <pjals>Guix doesn't read the current GRUB configs, it goes through each system profile (i think that's what its called? the code says that) and tries to make boot-parameters again. <Rutherther>pjals that's not what I meant. I mean that by changing the boot entries yourself you will be able to boot into earlier generation without the sysadmin, and fix it from there - gc the new one and reconfigure without it <pjals>The last time I messed with grub on Guix I couldn't find my way back into a sane system so I'll probably just wait for them to come back. <pjals>I do wish Guix had more support for worst-case scenarios like this.. oh well <Rutherther>btw what did the reconfigure with --no-bootloader error on? <pjals>Oh, the same as without it with (string-append #f " (" ...) where #f is the label. <pjals>Huh, grub-reboot exists, I might be able to use that <Rutherther>ekaitz let me know if you get into any problems with using it for qmk <pjals>Seems like grub-reboot is only in Debian-flavored grub utilities, shame. I might be able to build it on Guix though. <pjals>Debian's grub has a monorepo-style build system so I unfortunately cannot use grub-reboot :/ <pjals>Huh, nevermind, it errored late enough to still be able to build the grub-reboot program, nice. <pjals>I probably shouldn't have assumed that was part of the system packages.. <pjals>Yea, grub-reboot didn't do anything. Still in the #f generation.. <rynn>I just installed the Jetbrains mono font. Do I simply need to point fc-cache at the gnu store location for the package, or is there something else? <pjals>I've messed with fonts before on Guix, I think you needed to reboot or something like that. Though I assume you installed it through a way that it will be visible to fontconfig such as guix package, guix home, or guix system? <pjals>(don't use guix package!! it's the devil!!) <rynn>I installed it via guix install, yes.... <rynn>Yep, rebooted, but still don't see them showing up in gnome fonts. <rynn>Yeah. I installed Spleen via the same method and it worked just fine. <pjals>Ah, guix package doesn't add fonts to fontconfig, add it with home. System might work too? <Rutherther>there is no "adds to fontconfig", the only thing is to have fontconfig search dir point to ~/.guix-profile/share/fonts. I am trying to find if it by default points to XDG_DATA_DIRS as I remembered, but I can't really find it. If it doesn't, then it would be just adding config for fontconfig to add this directory there. No need to install it with home or system <pjals>What's .config/fontconfig/fonts.conf referring to my ~/.guix-home/profile/share/fonts then? ;) <Rutherther>that's exactly what I meant with adding the dir to config <rynn>Thanks for checking that Rutherther, I'll see if I can fix it. <h4>I `shell`ed a package in old generation and in a new generation though I only want the new version now. How to `gc` that old version only? <h4>Rutherther: Thanks! It was to test if disconnection would happens upon message send <Rutherther>make a gc root for the new one, then it won't be collected by gc, can be done with -r argument, it will make a link to the shell in store <h4>I have tooooooooo many packages not rooted (all of them). I only want to delete a specific package at specific version (and its deps btw) <dariqq>is savannah having troubles? i am getting 502 errors <tobtoht_>If I have a fresh install of Guix 1.4 on a foreign distro (apt-get install guix) and I time-machine to a commit in the future with --no-substitutes, why does it start off building versions of packages that do not exist in that future version of Guix? E.g. at one point it's building Guile 3.0.7, while the version at the time-machine commit is 3.0.9. <tobtoht_>Is it using current package definitions to build the inputs for the future guix-daemon? <Rutherther>@h4 then I think guix gc -D accepts paths to remove <tobtoht_>The problem is I'm running into a test failure while building Guile 3.0.7 and so I'm unable to proceed from this Guix 1.4 starting point. Is the only alternative to build Guix from source at a later commit if I don't want to use substitutes? <h4>Rutherther: So I have to define for example /gnu/store/hash-package-version and that for all its dependencies? <Rutherther>tobtoht_ there is no future guix-daemon, only future guix. Though I understand this doesn't answer your question, I am also not sure why it would build 3.0.7 <dariqq>tried again and it is working again <Rutherther>h4 I am not sure if it's the only solution, but I know nothing better, yeah... I know it's inconvenient, though if you just sticked to gc rooting what you want to keep, you can always run gc for everything. I don't think there has been much work on direnv for guix, but for example nix-direnv has automatic gc-root creation. So you just cd to projects with .envrc, they create the env, and it stays gc rooted. Then you can just run gc and keep all your... <h4>Missed while disconnected <Rutherther>resend: h4 I am not sure if it's the only solution, but I know nothing better, yeah... I know it's inconvenient, though if you just sticked to gc rooting what you want to keep, you can always run gc for everything. I don't think there has been much work on direnv for guix, but for example nix-direnv has automatic gc-root creation. So you just cd to projects with .envrc, they create the env, and it stays gc rooted. Then you can just run gc and keep... <Rutherther>it should be quite easy to implement, I may look into it at one point if no one else will <h4>Rutherther: I should have written in config.scm directly. It's just that `shell` is so convenient for temporary things, and well, there is nothing more permanent than a temporary thing <h4>If Nix GC root everything it fails the purpose of `shell`. The user should choose what to GC Root, or better, should write in config.scm what he wants forever <Rutherther>nix-direnv is a third party tool, it's exactly for cases where you want to keep it for the projects, ie. dev tools for procts <lilyp>I really wish mumi search results were more usable <h4>I think I will peel thorougtly /gnu/store, or if I find a convenient guix command that only shows what I asked without all the dependencies, and I will write into config.scm everything I want and run gc for good <Rutherther>I just mentioned nix-direnv as a convenient thing to keep the gc roots automatically without having to care about them much yourself, something similar could be done for guix with direnv <h4>Oh yeah I remember now, Nix was about bottles, like Wine and Python, that creates environments that you can fix or not, I remember. I'm not a developer so I don't have such specific problem, but yeah <h4>I don't have much space left so I should anyway collect garbage (at least old ones, if not possible all of them) and throw away generations I'm sure I won't ever need (particularly having a package that I would need offline that I don't have yet in new generations) <h4>But there is difficult things that I search for, like a command that list what is installed in a specific generation and a command that list what was temporarly downloaded for a specific generation <Rutherther>I did not mean to make it about Nix(/nix-direnv), it was just an example we can take inspiration from for Guix. It's not only about what you mentioned, Nix is very similar to Guix <h4>Yeah I said nothing about that I was discussing about my case and my needs now <Rutherther>command to list what is installed in specific generation could be "guix size" executed on the file of the system (can be seen in guix system list-generations, or by reading where symlink goes in /var/guix/profiles). Though the raw input is probably too much for you, would need some parsing <Rutherther>as for "temporarily downloaded for a specific generation", there exists no such information I am afraid. The derivation outputs don't store where they came from unless they are made so like the system generations or home generations (storing channels.scm). And due to the nature of gnu store, there are no proper known creation dates <ekaitz>Rutherther: did you try to use the arm toolchain with raspberry pi pico toolchain? or only with QMK? <Rutherther>I've tried only with qmk. What issues are you having with it? <ekaitz>Rutherther: none yet, i'll try now (it's building) i just wanted to know <ekaitz>there are many issues related with cross-compilation <Rutherther>yeah, the arm toolchains actually already have native search paths added, and I copied it to my one as well from those. I actually asked yesterday why the native-search-paths are even there, and then upon trying to remove them I stumbled upon the same issue described here :). But I haven't found this one on issues.guix.gnu.org, so thanks for pointing this out <ekaitz>Rutherther: I reported some others about riscv. It's just cross-compilation using gcc is broken because it searches in the incorrect places... :S <ekaitz>we should come up with some way to fix this in every single cross-compilation toolchain <Rutherther>the issue you linked basically aims to do that, since cross-gcc is used as a base among different cross compilation targets <ekaitz>i should pressure my friend efraim to make this happen :) <ekaitz>Rutherther: i'm finding some issues <ekaitz>/tmp/guix-build-newlib-nano-3.0.0-0.4c7d0df.drv-0/build/arm-none-eabi/newlib/../../../source/newlib/libc/reent/sbrkr.c:51: undefined reference to `_sbrk' <Rutherther>I don't think that's wrong, the toolchain is arm-none-eabi, and sbrk is a syscall, I don't think it should be expected from none toolchain to do sys calls <ekaitz>but why is it trying to do this? <Rutherther>how are you compiling? you should probably pass in -lnosys option <ekaitz>/gnu/store/4zw94h3w0b04ys27wb4plsazrrp9sj2b-profile/arm-none-eabi/lib/libc.a <--- it's this who asks <ekaitz>i'm using the pico-sdk and just running cmake inside <Rutherther>sorry, it's not just -lnano, but "-lc_nano -lnosys", or even better to use --specs=nano.specs. The newlib I exposed is just the newlib-nano, since that is the one qmk uses <ekaitz>hmm maybe something is missing then in pico sdk <ekaitz>ooh probably, i started over and now I have a missing lstdc++, which is fine <ekaitz>because you didn't add it to the package <Rutherther>the libstdc++ is missing, because I was unable to get it to compile <ekaitz>in any case i'm very happy this is getting there... i have many projects to do with the pico and i gave up because of this <Rutherther>I will try to contribute it to guix channel as soon as I get familiar with the git send-email, and such <ekaitz>Rutherther: i can help with that if you need <ngz>weary-traveler: I'm looking at it. <Rutherther>ekaitz thanks for the link, seems it's going to be a breeze with that <amano>Is it possible to install kernel and initrd in /boot? <amano>If I type a password once only during boot, I have to put btrfs root filesystem on one LUKS device. Two LUKS device will require two passwords.