Re: Do we actually support LUKS 2?
Hilton Chain writes: > On Tue, 25 Mar 2025 20:12:25 +0800, > 45mg wrote: >> >> "Thomas Ieong" writes: >> >> > I remember that some years ago we could not use LUKS 2, has the situation >> > improved? >> >> I'm writing this from Guix System installed on an LUKS 2 volume. So, >> yes, it works now. GRUB also supports `--pbkdf argon2id` now, so you >> don't have to worry about that insecurity [1] anymore. > > GRUB doesn't support Argon2 at the moment. Not really sure how I'm booting then. I see '# PBKDF argon2id, ...' in the output of `sudo cryptsetup status --debug myrootvolname`. IIRC, the issue was that libgcrypt didn't support argon2*. A quick search of the commit logs seems to suggest this has changed since 2022: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git&a=search&h=HEAD&st=commit&s=argon2 >> The problem is that you still need GRUB to decrypt the volume before you >> can boot, and GRUB's decryption is really slow (takes over a minute, >> versus a few seconds after booting the kernel). >> >> What most distributions do is use something like `ukify` to generate a >> bootable UEFI image that has includes the required crypto modules. There >> is an open patch series that would add this to Guix [2], but it hasn't >> been touched in a long time (it was split off from a larger rewrite of >> the bootloader subsystem [3], which also hasn't been touched in a >> while). > > UKI bootloader doesn't suits the multiple generation model well, the > implementation depends on the reliablity of EFI firmware too much. Could you elaborate, or link to a resource/past message/whatever explaining this? If I understand correctly, the main issue here is that the initrd doesn't know how to mount encrypted partitions. There are solutions to this other than UKIs, such as Arch's mkinitcpio: https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio
Re: adding Samba to config.scm
Hi, thanks 1. If there is something wrong with the server you can find the logs in /var/log and/or with “sudo herd status ”. with sudo herd status it starts 3 samba services, it seems to be ok. 2. Lastly, maybe try connecting using smbclient from the samba package to see if everything is fine. I don´t know how to do that. 3. in Guix I see that /home/gfp/public folder has no restrictions. Everybody can change the content etc. It seems to be ok from the side of Guix, but in the VM, in Trisquel it can´t find a shared folder. I added in Guix a .txt file In Trisquel it does not appear. Kind regards Gottfried Am 24.03.25 um 21:16 schrieb Noé Lopez: gfp writes: Hi Noé, thanks very much for the hint, now I managed to run: sudo guix system reconfigure /etc/config.scm in my config.scm I changed the folder: into: path = /home/gfp/public (service samba-service-type (samba-configuration (enable-smbd? #t) (config-file (plain-file "smb.conf" "\ [global] map to guest = Bad User logging = syslog@1 [public] browsable = yes path = /home/gfp/public read only = no guest ok = yes guest only = yes\n") I don´t know if that is ok. In opening my virtual machine, and looking for the shared folder in Trisquel it can´t find a shared folder. network smb:tuxedo.local Tuxedo Tuxedo: that is the name of my laptop no shared folders found My question: what else do I have to do in Guix? Or do I have to do something in the VM, in Trisquel ? Hi, I don’t run my own samba server so I can’t provide very specific answers, but I suppose this is a configuration issue not linked with guix. You can probably check the final look of your config in /etc, see if its what you wanted. If there is something wrong with the server you can find the logs in /var/log and/or with “sudo herd status ”. Lastly, maybe try connecting using smbclient from the samba package to see if everything is fine. Good evening, Noé OpenPGP_0xD9E413C6C4BB32CE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
gc rooting operating-system-derivation via gc-root-service-type
Hello all, I would like to gc root my operating system derivation to keep all inputs necessary to build the system in store even on gc colleting, preferably also the ungrafted versions. One way would be to make multiple calls to the guix system build and gc root them out of the store myself, but I would rather not use that option, I would like this to be in the operating-system itself. I went through NixOS code to see how they do something like that, because they have an option to gc root the build inputs. They just gc root the system derivation similarly to what gc-root-service-type does in Guix, this should keep all the build inputs of the operating system as the drv references them. I started figuring out how to get a .drv file in the gc root service type, for now I have this procedure that will take an os and make a new os from it that will have the original system derivation gc rooted. --- (define (operating-system-with-build-inputs os) (operating-system (inherit os) (services (operating-system-user-services os)) (services (cons* (simple-service 'gc-root-system-derivation gc-root-service-type (list (derivation-file-name (with-store %store (run-with-store %store (operating-system-derivation os (with-store %store (run-with-store %store (without-grafting (operating-system-derivation os (derivation-file-name (with-store %store (run-with-store %store (without-grafting (operating-system-derivation os))) (operating-system-user-services os) --- This somewhat works, but it seems to me like this slows down the evaluation and build because there are actually multiple consequent builds through the daemon happening rather than doing all the builds at one because of the multiple run-with-store calls. I can't seem to figure out a way to reference derivation file without doing something like this - is there a different way to reference drv of a package/operating system instead? It seems to me like everything in gexps operates with the outputs of derivations rather than the derivations themselves, but maybe I am just missing a procedure to reference derivation or something? Apart from that I was trying to also gc root the ungrafted operating system output and derivation, but that doesn't seem to work well - or at least the derivation and output gc rooted is different than one obtained with --no-grafts of the original system. I suppose that could be because it is being grafted afterwards? But still, it's not the same path as the grafted one, so something strange is going on. Regards, Rutherther
Re: How to (actually) get a perfect setup?
It was the good old "shit behind the levers". I had a channel.scm in a parent directory and that broke compilation. However, in my defense, the error message was quite cryptic. It looked like there was an error in the module (icm-9 boot). When I switched to guile-next, I got a much better error message with a back trace. That helped me solve the problem. (I'm a guile scheme noob). Anyway, Thanks! On 3/24/25 08:41, 45mg wrote: Snikta writes: I'm using Emacs with Geiser Guile on Guix System, and I've tried to add both /run//guile/site/3.0 and (built) ~/src/guix to the %load-path (and they are there). Still, I never get a functional development environment. I.e. I'm not able to load any Guix config file without an error, not able to see any code documentation and I'm not able to follow symbols. Emacs is able to find the files of different imported modules (using M-.), but nothing else. I have a related issue: Geiser dies if packages are defined in submodules of the current project. For example, I have package 'foo' defined in ./packages/foo.scm, and I have `(define-module (config) #:use-module (packages foo))` in ./config.scm. When I try to start Geiser, it gives me 'error: foo: unknown package' and the REPL exits. OpenPGP_0x8CF8982C455FAB05.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: chez scheme can't load system shared library
Hello Sebastian Based on your suggestion, now I figure out that I have to install guix openssl, even though I already I have openssl libraries installed in "/usr/lib". The following works for me now: $ guix install openssl $ LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Thanks Pan On 3/25/25 6:25 PM, Sebastian Dümcke wrote: Not sure how to answer to a particular meesage from the digest emals I am receiving. Hope this finds the right person and thus not upset anyone. Hi Pan, you need to set LD_LIBRARY_PATH to your profile library path (and then load without absolute path in chez). The following works for me: > guix shell -CP coreutils-minimal chez-scheme openssl > ls ~/.guix-profile/lib csv10.1.0 engines-3 libcrypto.so libcrypto.so.3 libssl.so libssl.so.3 ossl-modules pkgconfig > LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Best Sebastian
Re: Do we actually support LUKS 2?
Hilton Chain writes: >> Not really sure how I'm booting then. I see '# PBKDF argon2id, ...' in >> the output of `sudo cryptsetup status --debug myrootvolname`. > > Which GRUB variant are you using? There exists an unlikely to be merged patch > series for Argon2 support. I'm using `grub-efi-bootloader` in Guix System. GRUB version 2.12. I haven't explicitly configured a patched variant, nor do I have any memory of ever using one. >> If I understand correctly, the main issue here is that the initrd >> doesn't know how to mount encrypted partitions. There are solutions to >> this other than UKIs, such as Arch's mkinitcpio: >> https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio > > Our initrd knows how to decrypt. It's GRUB that needs to decrypt then find > its > configuration and kernel + initrd first. Right, I got confused back there. So the main issue is GRUB needing to decrypt in the first place, which wouldn't happen if we could have the kernel+initramfs on a separate unencrypted partition, like I mentioned in my other message.
Re: Do we actually support LUKS 2?
45mg <45mg.wri...@gmail.com> writes: >>> What most distributions do is use something like `ukify` to generate a >>> bootable UEFI image that has includes the required crypto modules. Please disregard this, I don't actually know how prevalent UKIs are. What I was going for was - usually the kernel and initramfs images are written to eg. `/boot`, which can be unencrypted. And the initramfs is able to mount the encrypted volume. (To fully secure this setup you'd need Secure Boot, which is addressed in the bootloader rewrite I think...)
Re: Do we actually support LUKS 2?
On Tue, 25 Mar 2025 23:01:02 +0800, 45mg wrote: > > Hilton Chain writes: > > > On Tue, 25 Mar 2025 20:12:25 +0800, > > 45mg wrote: > >> > >> "Thomas Ieong" writes: > >> > >> > I remember that some years ago we could not use LUKS 2, has the situation > >> > improved? > >> > >> I'm writing this from Guix System installed on an LUKS 2 volume. So, > >> yes, it works now. GRUB also supports `--pbkdf argon2id` now, so you > >> don't have to worry about that insecurity [1] anymore. > > > > GRUB doesn't support Argon2 at the moment. > > Not really sure how I'm booting then. I see '# PBKDF argon2id, ...' in > the output of `sudo cryptsetup status --debug myrootvolname`. Which GRUB variant are you using? There exists an unlikely to be merged patch series for Argon2 support. > IIRC, the issue was that libgcrypt didn't support argon2*. A quick > search of the commit logs seems to suggest this has changed since 2022: > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git&a=search&h=HEAD&st=commit&s=argon2 GRUB uses a vendored version of libgcrypt[1]. > >> The problem is that you still need GRUB to decrypt the volume before you > >> can boot, and GRUB's decryption is really slow (takes over a minute, > >> versus a few seconds after booting the kernel). > >> > >> What most distributions do is use something like `ukify` to generate a > >> bootable UEFI image that has includes the required crypto modules. There > >> is an open patch series that would add this to Guix [2], but it hasn't > >> been touched in a long time (it was split off from a larger rewrite of > >> the bootloader subsystem [3], which also hasn't been touched in a > >> while). > > > > UKI bootloader doesn't suits the multiple generation model well, the > > implementation depends on the reliablity of EFI firmware too much. > > Could you elaborate, or link to a resource/past message/whatever > explaining this? I once used UKI, but at one point the updated boot entries didn't persist in a subsequent reboot. Then I changed my mind to not expect much from the firmware implementation and switched to grub-efi-removable-bootloader instead. > If I understand correctly, the main issue here is that the initrd > doesn't know how to mount encrypted partitions. There are solutions to > this other than UKIs, such as Arch's mkinitcpio: > https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio Our initrd knows how to decrypt. It's GRUB that needs to decrypt then find its configuration and kernel + initrd first. --- [1]: https://git.savannah.gnu.org/cgit/grub.git/log/grub-core/lib/libgcrypt
Re: Do we actually support LUKS 2?
"Thomas Ieong" writes: > I remember that some years ago we could not use LUKS 2, has the situation > improved? I'm writing this from Guix System installed on an LUKS 2 volume. So, yes, it works now. GRUB also supports `--pbkdf argon2id` now, so you don't have to worry about that insecurity [1] anymore. The problem is that you still need GRUB to decrypt the volume before you can boot, and GRUB's decryption is really slow (takes over a minute, versus a few seconds after booting the kernel). What most distributions do is use something like `ukify` to generate a bootable UEFI image that has includes the required crypto modules. There is an open patch series that would add this to Guix [2], but it hasn't been touched in a long time (it was split off from a larger rewrite of the bootloader subsystem [3], which also hasn't been touched in a while). Which is a shame, because this issue was brought up multiple times in the Guix Survey. [1] https://yhetil.org/guix/87edoftd1x.fsf@wireframe/ [2] https://yhetil.org/guix/cover.1705465384.git.lilah@lunabee.space/ [3] https://yhetil.org/guix/cover.1727201267.git.her...@rimm.ee/
Re: adding Samba to config.scm
Hi, This error means that the module containing “samba-service-type” is not included in your configuration file (in use-modules or use-service-modules). The samba-service-type variable is declared in “gnu/services/samba.scm”, you can know this in the output of “guix system search samba” for example. It would look like either (at the top of your file): (use-modules ... (gnu services samba)) Or: (use-service-modules ... samba) Have a nice day, Noé signature.asc Description: PGP signature
Re: Do we actually support LUKS 2?
On Tue, 25 Mar 2025 20:12:25 +0800, 45mg wrote: > > "Thomas Ieong" writes: > > > I remember that some years ago we could not use LUKS 2, has the situation > > improved? > > I'm writing this from Guix System installed on an LUKS 2 volume. So, > yes, it works now. GRUB also supports `--pbkdf argon2id` now, so you > don't have to worry about that insecurity [1] anymore. GRUB doesn't support Argon2 at the moment. > The problem is that you still need GRUB to decrypt the volume before you > can boot, and GRUB's decryption is really slow (takes over a minute, > versus a few seconds after booting the kernel). > > What most distributions do is use something like `ukify` to generate a > bootable UEFI image that has includes the required crypto modules. There > is an open patch series that would add this to Guix [2], but it hasn't > been touched in a long time (it was split off from a larger rewrite of > the bootloader subsystem [3], which also hasn't been touched in a > while). UKI bootloader doesn't suits the multiple generation model well, the implementation depends on the reliablity of EFI firmware too much.
Re: adding Samba to config.scm
gfp writes: > Hi Noé, > > thanks very much for the hint, > > now I managed to run: sudo guix system reconfigure /etc/config.scm > > > in my config.scm I changed the folder: > into: path = /home/gfp/public > > > (service samba-service-type (samba-configuration > (enable-smbd? #t) > (config-file (plain-file "smb.conf" "\ > [global] > map to guest = Bad User > logging = syslog@1 > > [public] > browsable = yes > path = /home/gfp/public > read only = no > guest ok = yes > guest only = yes\n") > > I don´t know if that is ok. > > In opening my virtual machine, and looking for the shared folder in > Trisquel it can´t find a shared folder. > > network > smb:tuxedo.local > Tuxedo Tuxedo: that is the name of my laptop > no shared folders found > > My question: what else do I have to do in Guix? > Or do I have to do something in the VM, in Trisquel ? > Hi, I don’t run my own samba server so I can’t provide very specific answers, but I suppose this is a configuration issue not linked with guix. You can probably check the final look of your config in /etc, see if its what you wanted. If there is something wrong with the server you can find the logs in /var/log and/or with “sudo herd status ”. Lastly, maybe try connecting using smbclient from the samba package to see if everything is fine. Good evening, Noé signature.asc Description: PGP signature
Re: Gnome "oh no something has gone wrong..."
Hi Giacomo, On lun, mar 24, 2025 at 07:09 paul via wrote: > Hi all, > > I'm having the same problem since a month or so, same symptoms and > logs. The only certain thing I know is that > 3dc8026d58f9480547a595450a6483e0f13c1ba4 works. I suppose this is due > to the recent GNOME update but I didn't have the time to bisect the > right commit. > > I deleted ~/.cache and > > rm -rfv ~/.local/share/*gnome* > removed '/home/paul/.local/share/gnome-photos/tracker3/private/meta.db' > removed > '/home/paul/.local/share/gnome-photos/tracker3/private/ontologies.gvdb' > removed directory '/home/paul/.local/share/gnome-photos/tracker3/private' > removed directory '/home/paul/.local/share/gnome-photos/tracker3' > removed directory '/home/paul/.local/share/gnome-photos' > removed > '/home/paul/.local/share/gnome-settings-daemon/input-sources-converted' > removed directory '/home/paul/.local/share/gnome-settings-daemon' > removed '/home/paul/.local/share/gnome-shell/update-check-46' > removed '/home/paul/.local/share/gnome-shell/application_state' > removed directory '/home/paul/.local/share/gnome-shell' > removed directory '/home/paul/.local/share/org.gnome.TextEditor/drafts' > removed '/home/paul/.local/share/org.gnome.TextEditor/session.gvariant' > removed '/home/paul/.local/share/org.gnome.TextEditor/recently-used.xbel' > removed directory '/home/paul/.local/share/org.gnome.TextEditor' > > > > If anyone found a way to successfully delete the right cache it'd be > pretty useful :) Other wise I may end up reinstalling but I don't feel > like it is a nice option . On a previus similar error of Gnome i resolved generating a new home folder Which was usefull only before a new reconfigure. Just saying it could be a bad option but less time consuming than a reinstall Matteo > > > Thank you all for your help, > > cheers > > giacomo
Re: setting MTU for guix pull only
On Wed, 19 Mar 2025 11:19:13 -0700 Andy Tai wrote: > when I do guix pull, I run into this error: > > guix substitute: error: TLS error in procedure > 'write_to_session_record_port': Error in the push function. As far as I understand, this error message indicates a network issue resulting in a connection failure. It is not possible to deduce the cause of such failure from this message along. On Wed, 19 Mar 2025 12:05:48 -0700 Andy Tai wrote: > More context: I am not on any VPN or such, if this detail may be of > value for the problem at hand. > > On Wed, Mar 19, 2025 at 11:58 AM Andy Tai wrote: > > > > Yes, the relevant message commenting on the MTU size was > > > > https://issues.guix.gnu.org/71238#7 I am not particularly knowledgeable in the topic. I was forced to investigate it when using the tunnel. However, the same issue with MTU might happen without a tunnel as well. Some router in the route may have a lower MTU set for some reason. To identify whether MTU was an issue, I tested manually by pinging the address with packets of different sizes. I do not know whether there is a better way to do that. I described that in the linked post. "MSS clamping" is a technique to probe and adjust the size of MTU automatically. However, I didn't look into it aside of configuring a tunnel. I suspect that it may be possible to set it up somehow for ordinary connections. But I do not know. Roman pgp8Shqd8eZ5C.pgp Description: PGP signature
