<KarlJoad>The partitions are fine, everything is still there, and I can confirm that if I boot a USB. But I need to perform either a guix system init or a guix system reconfigure to make the disk listed in the EFI boot options again.
<KarlJoad>The odd thing is, this problem does not happen on my laptop.
<nckx>One guess the first machine somehow invalidates boot variables that it (questionably) considers ‘stale’, because the drive/file to which it points is ‘gone’, so that when you plug your Guix SSD back in the firmware has forgot that there was an entry for Guix, and where to find the boot loader. You could verify this hypothesis by running ‘efibootmgr’ right after reconfiguring Guix, then remove the Guix SSD and run it again (from a different d
<nckx>istro). If anything changes, well, your firmware is being [even more than usually] stupid.
<nckx>(Why are you swapping out your SSD that much?)
<nckx>If that hypothesis doesn't work out I'm sure we can come up with 3 others, because the world of UEFI firmware is a world of bizarre bugs.
<nckx>Although Guix hardly cooperates; for example, it doesn't handle removable drives in the way it should (by installing \EFI\BOOT\BOOTX64.EFI instead of GRUBX64.EFI).
<nckx>Simply renaming the latter to the former is likely to fix your boot problems in this case, IME. I had a desktop like that once.
<KarlJoad>nckx: I switch them out for boot reasons. On the last computer it was easier to switch disks than work with the UEFI.
<KarlJoad>It might be important that this is a server motherboard too, not a desktop one. A SuperMicro H12.
<nckx>Is Guix still offered as a boot option when you've removed & reattached the Guix drive?
<KarlJoad>The disk has completely disappeared. It does not show up in the boot list at all. Only the boot-over-ethernet devices and the UEFI shell.
<nckx>‘Disks’ aren't bootable, though. Files are. If it forgot to look for grubx64.efi and there's no ‘standard’ bootx64.efi there, it won't be able to boot. I'm curious if renaming (or copying) grubx64.efi to bootx64.efi before pulling it out helps any.
<KarlJoad>I just finished a reconfigure. I'll check the efibootmgr and see what's up. I'll also check for the grubx64.efi file too.
<patched[m]>What's the best way for finding what to import to refer to a specific package I can find with guix search? E.g., I want to know what I need to import to get gcc-toolchain.
<nckx>patched[m]: guix show gcc-toolchain, the ‘location’ field is the name of the module.
<KarlJoad>nckx: After a reconfigure, Guix shows up as boot option 0000*, and is the first in the boot order. The grubx64.efi is located at /boot/efi/EFI/Guix, where /boot/efi is partition /dev/sdb1.
<nckx>It should be persistent for you to be able to boot Guix next. If it's gone, the firmware will look *only* for \EFI\BOOT\BOOTX64.EFI (the UEFI spec default) on any new drive. It does not recursively search EFI or anything. It will never see \EFI\Guix\GRUBX64.EFI, and will not be able to boot Guix.
<nckx>So you could mkdir /boot/efi/EFI/BOOT && cp /boot/efi/EFI/Guix/GRUBX64.EFI /boot/efi/EFI/BOOT/BOOTX64.EFI as a hack. Drawback is that the copy will never be updated. I can say only that it worked for me in practice.
<nckx>Interesting that NixOS just claims the default name, doesn't try to play nice with other OSes.
<nckx>But then they don't use GRUB anymore, do they?
<nckx>I'm rambling, because it's past my bed time. Good night all.
<KarlJoad>Back on the Guix installer, boot entry 0000* is still not there, but the USB key is first in the boot order. But the EFI file is still in the same spot. So I will try the copy you mentioned.
<nckx>Right, the EFI file won't go anywhere, but it seems the firmware is amnesiac and loses the pointer (in NVRAM) to it after each drive swap, so it becomes invisible.
<KarlJoad>That is... odd... The NixOS entry 0009 has been replaced by USB KEY, so something must be remembered somewhere. I guess this leads into the question, why does Guix put its EFI file in a non-specification location?
<KarlJoad>nckx: Your solution of copying the boot EFI file to /boot/efi/EFI/BOOT/BOOTX64.EFI worked. Now I guess, why does Guix put the EFI file in a non-standard location?
<nckx>sneek: later ask KarlJoad: If this is because of me saying \EFI\BOOT\BOOTX64.EFI is the *default* earlier: if every OS used the same location, what would be the point? You could never multi-boot that way.
<nckx>sneek: later tell KarlJoad: This treats the drive like removable storage (as you do), by (1) not bothering with the current machine's NVRAM and (2) instead installing GRUB to BOOTX64.EFI (overwriting any previous OS there, which is why it must be opt-in).
<KarlJoad>sneek: later ask nckx I think see what you mean by that preventing multi-boot. I am going to try the grub-efi-netboot-bootloader, to see if that works.
<sneek>Welcome back KarlJoad, you have 4 messages!
<sneek>KarlJoad, nckx says: Why do you say ‘Guix puts the EFI file in a non-standard location’?
<sneek>KarlJoad, nckx says: If this is because of me saying \EFI\BOOT\BOOTX64.EFI is the *default* earlier: if every OS used the same location, what would be the point? You could never multi-boot that way.
<sneek>KarlJoad, nckx says: What could help in your unusual situation would be to add ‘--removable’ support to Guix's grub-efi-bootloader.
<sneek>KarlJoad, nckx says: This treats the drive like removable storage (as you do), by (1) not bothering with the current machine's NVRAM and (2) instead installing GRUB to BOOTX64.EFI (overwriting any previous OS there, which is why it must be opt-in).
<apteryx>is anyone having the "55444 - elogind startup race between shepherd and dbus-daemon" bug?
***roptat is now known as Guest8848
***toluene5 is now known as toluene
<apteryx>or better, does someone have a repro to trigger it?
<fcw>In package definitions, am I allowed to use `system` instead of `invoke` to run scripts? `invoke` uses `system*` which ignores SIGINT and SIGQUIT. Apparently, the package I am building (smlnj) behaves differently if SIGINT is ignored during the build.
<jpoiret>sneek, later tell KarlJoad: There's no way to directly access the --removable option of grub right now unfortunately, but you could use --no-bootloader and manually install grub (easy but annoying), or just code up a new bootloader that would be the same as grub-efi but its install-grub-efi procedure would use --removable
<attila_lendvai>bovid_19, thanks for the feedback! since then i have moved a duplicate of it into my channel and testing it now. this way i can publish my code while the Guix maintainers catch up with that patchset.
<aadcg>hi guix. why does M-x guix-hidden-packages show xorg-server as a hidden package?
<bovid_19>attila_lendvai: Is it possible that I know your name from around Common Lisp? It seems to ring a bell.
<aadcg>I ask, since xorg-server doesn't seem to be define as a hidden-package, in the way that gcc, for instance. is
<attila_lendvai>bovid_19, yep, i'm one of the dwim.hu guys. but i'm not too active in CL nowadays...
<bovid_19>aadcg: maybe because of `xorg-server-for-tests'? It uses a hidden package that inherits `xorg-server'
<bovid_19>What's the logic behind the module being public and the package hidden? Is it so you can refer to it as a dependency without e.g. it appearing in package searches?
<sneek>nckx, KarlJoad says: I think see what you mean by that preventing multi-boot. I am going to try the grub-efi-netboot-bootloader, to see if that works.
<sneek>nckx, KarlJoad says: In this case, overwriting previous OS's GRUB by using removable is OK, because there is no other OS on this disk. That was kind of the point. Change OS by changing disk, prevents other OSs (Windows) from tampering with my Linux.
<sneek>nckx, KarlJoad says: Ok, so I misunderstood the netboot variant. How would I go about making a removable version then? I don't see any easy way to add the --removable flag.
<aadcg>nckx: emacs-guix does give location information, it's very helpful
<nckx>aadcg: I'm still installing it, but if it deals with package names (rather than variable names), the -for-tests one might be ‘masking’ the regular one. They both have the same package name, xorg-server.
<bovid_19>aadcg: couldn't the one you find as hidden be the `xorg-server' from `xorg-server-for-tests'?
<nckx>aadcg: Aha! And where does it think ‘xorg-server’ is defined? 5251-ish or 5376-ish?
<aadcg>nckx: makes sense. I find it a bit undesirable that xorg-server is hidden since I can't read its manpages for instance
<nckx>bovid_19: The default (well, convention) in Guix is to include documentation in the main output. So you shouldn't need to install it separately. A few packages that have particularly chonky docs split them out into :doc outputs, but that's more for HTML and stuff, not info/man, and very rare.
<nckx>If you mean ‘install only manpages without the rest of the output’: no.
<nckx>It's nothing unique to deploy.scm, if I remove the #~ and friend there I get: guix/scripts/home.scm:279:10: Unknown # object: "#~"
<bovid_19>nckx: Allright. Having missed aadcg's correction from "I have installed elogind
<bovid_19>explicitly and I can read its manpages" to "[I] haven't [...]" and seeing your
<bovid_19>reply "Ideally, you wouldn't" had me a bit confused. The documentation I've been missing is probably part of other packages that are not installed. For example, I expected to have the docs for xorg available since it is part of my system, but it seems like I need to explicitly install `xorg-server'. There might also be buggy definitions, but
<bovid_19>I'm glad to know now that they should be installed.
<civodul>nckx: re Geiser, if you start by doing C-c C-k in (guix gexp), it prolly works
<civodul>that should happen automatically though, since files that use gexps imports (guix gexp)
<nckx>That is literally the same commit I'm on now.
<foobarxyz>sorry, this is slightly different from a request to include extras in clang@14; my old guix installation which was 20 days old and I've just pulled now does not list clang@14 as version i can install
<nckx>guix show clang@14 — I don't know how to break this to you — shows clang@14
<nckx>Then run ‘hash guix’ and ‘command -v guix’ again. It should point to .config/guix/current.
<nckx>Using guix to install a (potentially very old) version of itself never ends well, and should really be warned about. You shouldn't have been expected to know this. (Although I always wonder what drives people to install guix using guix…)
<civodul>nckx: hmm not sure; M-x guix works for me, except for service lookup (i haven't investigated)
<nckx>foobarxyz: Another weird thing: you should make sure that /home/xyz/.config/guix/current/bin is in your $PATH, before /home/xyz/.guix-profile/bin, but Guix System should do this automatically.
<foobarxyz>I can also see clangd installed, so all good, thank you so much for your help!
<nckx>I don't have much experience with that. If you know where PATH is set up, you should try correcting that, but I can't say more.
<nckx>foobarxyz: Happy to (finally) be of service.
<efraim>civodul: it's been a while since I looked deeply into it, but there is the possibility of 32-bit armv8 chips. Also, by having armv8 in armhf it allows us to have armhf binaries that are optimized to run on aarch64 machines (like i686 -> x86_64).
<efraim>but mostly I got it by looking at the GCC code, and it also lists the armv8 options there for optimizations
<bjc>nckx: if you do end up figuring out how to get geiser to deal with #~, let me know. drives me craze
<patched[m]>If a software provides a .tar.gz with vendored dependencies, should I use this or is it better to create packages for all dependencies individually? Many of the deps seem to be forks that the developer has created of other libraries for some reason.
<aadcg>bjc: why does exwm make tramp less ussable?
<bjc>it's not that, it's that tramp makes everything less usable
<bjc>and i can't have my window manager hanging indefinitely or crashing
<nckx>patched[m]: And this is why bundling is always bad ☹ Does the package really need the weird NIH forks? In Guix, we oppose bundling and prefer using separate packages whenever possible.
<mothacehe>jpoiret: thanks for the platform patchset :). i tried "make as-derivation", guix build & guix system image commands, everything seems fine. OK for you if i proceed?
<patched[m]><nckx> "patched: And this is why..." <- What is NIH?
<patched[m]>I don't know if it really requires the forked version as dependencies, I can ask the creator. It's a go package and I don't have much experience with those or why somebody would maintain their own forks of deps.
*nckx urges jpoiret to say yes. :) Can't be worse than the current situation.
<nckx>I'm running check-system and ‘guile \ /home/nckx/guix/scripts/guix build -m ./etc/system-tests.scm -K’ has used 20 CPU-minutes so far. Is that fishy? This process alone is running @ 200%; it has no children.
<nckx>strace is just endless newfstatat calls that look (at first glance) like a big repeating loop.
<qzdlns[m]>wow TIL one may launch R sessions under guix shell in org-mode
<apteryx>OK, I'll look if something simple can be done, thanks
<apteryx>it was also mentioned somewhere whether Shepherd should always do waitpid in the stop action
<apteryx>as otherwise it goes on to restart a new process which may while the previous one is still running, causing problems
<apteryx>I'm doing this as a custom stop action for Jami, but it seems it should be handled by Shepherd itself
<civodul>apteryx: shepherd calls waitpid by itself upon SIGCHLD (fortunately :-))
<civodul>but maybe there's an issue i'm unaware of?
<civodul>in general, the 'stop' action should just terminate processes
<apteryx>(kill pid SIGKILL) would also have the parent sent a SIGCHLD, I suppose?
<apteryx>(i.e., SIGKILL vs SIGTERM doesn't matter here?)
<apteryx>Seems it should just work... hm. I'll need a new round of investigation to determine whether there's still a problem if I don't manually invoke waitpid :-). Thanks.
<apteryx>I think I can query D-Bus instead of Shepherd as a workaround, using the already available dbus-service-available?
<attila_lendvai>apteryx, FWIW, i remember coming to the conclusion about half a year ago that herd restart some-service was broken because it invoked the start action while the stop did not finish yet, and the daemon binary complained
<sneek>KarlJoad, jpoiret says: There's no way to directly access the --removable option of grub right now unfortunately, but you could use --no-bootloader and manually install grub (easy but annoying), or just code up a new bootloader that would be the same as grub-efi but its install-grub-efi procedure would use --removable
***stikonas_ is now known as stikonas
<attila_lendvai>what is printing "error in finalization thread: Success" at boot? looks weird...
<jpoiret>unmatched-paren, attila_lendvai, vagrantc: basically, there's a separate thread for all guile processes that's in charge of the gc, which communicates with the other threads, and when we do a raw exec (which happens when early userspace hands off to the shepherd after pivoting root) the gc thread doesn't really understand
<jpoiret>it thinks it has got an error from reading the pipe because it read 0 bytes, but the read call itself doesn't error, that's why you get "error in finalization thread: Success"
<nckx>lechner: (1) if it really must be in that specific directory: by adding nyacc to your system package list and reconfiguring; (2) find $(guix build linux-pam) -name \*.pc → nope. If it's included in the sources, we should install it, and a patch to that effect would be welcome!
<lechner>dirtcastle: Hi, do you use the fish shell?
<jts>I'm still getting the error "guix system: erreur : #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2"> : entrée G-expression invalide". I double-checked to make sure there were no changes in my guix config.scm since the last successful reconfigure, and there were not. Anyone know what might be the issue?
<unmatched-paren>lechner: i use fish. is there an issue you're having? (back btw, i'll help you now `:)`)
<unmatched-paren>What you want to do is modify it to add a new phase that installs the .pc file
<unmatched-paren>So, inside the arguments list, add: #:phases (modify-phases %standard-phases)
<unmatched-paren>(modify-phases) takes some phases and modifies them according to the specification you give it. e.g. (delete 'phase), (add-before 'phase 'new-phase (lambda* (...) ...)), (add-after [same as before]), etc
<unmatched-paren>so you'll want to do (modify-phases %standard-phases (add-after 'install 'install-pkg-config)).
<lechner>unmatched-paren: thanks, but isn't pam.pc part of make install?
<jts>in the last five months I've been using Guix, breakage seems to be a mensual occurrence. it might be worthwhile to consider stricter testing before a commit is made, and probably just having stricter requirements for patches in general
<risu>i wish i could but I can't get the live usb to boot with my laptop from ancient times .-.
<unmatched-paren>once, guix pull broke, which would probably have been avoided by even a brief testing session. There should be a standard procedure for testing your changes, and perhaps some scripts to Automate(TM) the whole process..
<apteryx>civodul: was the commit that allowed reusing inferiors connections critical? (e.g., more critical than a working CI? :-)) if not, perhaps the best thing to do would be to revert it until we have a multi-threaded scenario test that works
<bjc>dominicm: conceptually, guix is a source distro, and the ci system that makes the binaries is only loosely coupled with it. as soon as someone pushes, there's a new release, and the ci has to catch up to verify it. theoretically, you could wait for the ci to finish before minting a new stable, but given how long the ci takes (and that sometimes, like now, it has trouble completing at all), that's not really feasible
<risu>lechner: no, i've only usb 2.0 ports on this machine
<civodul>unmatched-paren: there's been a series of bugs and issues as of late...
<lechner>risu: can you boot from other ISOs on USB?
<dominicm>bjc: yeah I totally agree with building packages that aren't ready yet. I mean scenarios when big software like ungoogled-chromium is currently in a failed state (not in-progress), and instead of assuming that the build is borked it tries to build it locally.
<unmatched-paren>but it does seem to me (someone who has never administrated a server, btw) like there might be some deeper issue than "uh oh, boot hung!". Of course, everyone who runs the CI does excellent work, and I'm not suggesting they're incompetent or anything.
<unmatched-paren>s/boot hung/(boot hung!|services failed!|file system is corrupted!)/
<dominicm>(I name ungoogled-chromium only because it's what I've experienced the most breakage with)
<jts>dominicm: I managed to build ungoogled-chromium and ungoogled-chromium/wayland just fine the other day; might be worth a shot if you use it often (I just need to test webpages in it from time to time)
<risu>lechner: yes, syslinux-based isos are fine. all the ones i tried with grub failed.
<lechner>The current complaints are a sign that Guix is ready for prime time. It is no longer experimental. Congratulations, everyone!
<apteryx>unmatched-paren: I'm mostly responsible for the boot issues, having bet that a Btrfs RAID10 6x drives array would work alright. And it does in a virtualized environment (QEMU -- we have a system test for it) but for some reasons the boot is flaky on the the Dell PowerEdge server equipped with a PERC730p RAID/HBA card; the drives appear unready by the time 'btrfs device scan' runs, and it fails to
<KarlJoad>My guix system seems to be hanging on both a system reconfigure and a home reconfigure after updating substitutes. No CPU cycles used, but they did do something for a while. Has anyone seen this before?
<apteryx>to be clear; *running* the returned procedure as done in the start of the jami-service *would* block, right, pre or post Shepherd 0.9.0? I
<attila_lendvai>linux has a tendency to thrash even with zero swap enabled. when low on memory, it can start swapping the read-only mmapped files (e.g. code blocks in binaries!). i had to power cycles my swapless linux installs way too many times because of this... the alternative is to wait indefinitely for the OOM, and it often ends up killing the gnome session...
<lechner>Hi, is there a Hoogle type search for unbound variables in Guix? Maybe Guigle, or Giggle?
<civodul>apteryx: the one in telephony.scm:525, right?
<risu>lechner: thanks, i was not aware of that! i don't have win7 anymore though but at least it seems there is a better firmware for my pc.
<civodul>apteryx: with-retries uses (@ (guile) sleep), which blocks
<risu>i kind of think that the safest is simply to install guix by using `guix system reconfigure` at some point.
<civodul>(gnu build secret-service) has a trick, but i don't recommend copying it
<apteryx>FWIW, I'm in the VM created with "./pre-inst-env guix system vm --no-graphic -e '(@@ (gnu tests telephony) %jami-os)' --no-offload --no-substitutes" an launched with /gnu/store/5a0cy5i1g9bnvx840an0x7j7gwm65iwb-run-vm.sh -m 512 -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22, and I see: