<wednesday>Does anyone here have experience of having /gnu and /var/guix on btrfs subvolumes? having /var/guix on one causes guix system init to crash, but getting past that error, when I boot I get grub complaining about missing /store/stuff-linux-libre/bzImage
<roptat>wednesday, I don't think it's supported yet :/
<roptat>the kernel is in /gnu/store, so on the btrfs partition. Does grub support that?
<wednesday>roptat: well I used to have separate boot subvolumes on gentoo I believe(some years ago), don't entirely remember, but I think in some mailing lists I think I saw someone with a separate /gnu subvolume
<nckx>I can't afford to break a machine right now, but I'm pretty sure GRUB still sees /gnu/store. In which case having a symlink /store → /gnu/store would allow you to have /gnu on a subvolume, but it's ugly as hell. Also just an assumption that nothing else is broken too :-)
<wednesday>putting /gnu and /var/guix in the root subvolume doesn't seem to fix anything, get same error about needing to load the kernel first, would I need to put my store on an ext partition or something nckx?
<kmicu>wednesday: there is an issue about that on bugtracker. Currently Guix generates wrong paths for btrfs subvolumes.
<nckx>Stilll guessing: store-mount-point in bootloader/grub.scm is probably "/gnu" when in the case of btrfs subvols it should be "/". Probably an easy fix™.
<wednesday>kmicu: I can get partway through booting with /gnu on my root subvolume, by adding the subvolume name to the start of the paths in the grub menu options. I also have to add insmod all_video to get graphics, but I end up with a kernel panic it seems
<nckx>The (wrong) path is probably also used in early user space. I wonder how. Is it… trying to mount subvolumes?
<kmicu>wednesday: iirc there are more places to fix than only grub config. For example mounting logic is also incorrect. I recommend installing stock config and then play in a VM to fix btrfs subvolumes otherwise installing Guix System is very frustrating process with a long feedback loop after each adjustment.
<kmicu>wednesday: in Guix land expect Guile/Shephard stuff.
<nckx>wednesday: Oh. You were gone (or so my client said) so I left a message.
<wednesday>yea last thing i saw is what i said about is root meant to be in the fstab ha
<kmicu>The best way to figure out what really happens is to diff filesystem after config changes or to read Guix source code. (Both are painful on live half-booted OS).
<nckx>Anyway. No need for / in fstab. That's for ‘mount -a’, and guess what Guix doesn't use.
<wednesday>kmicu: well right now I got no system to boot into ha, so it's either try fix this or give up and use ext for now, which will be a pain for me later on
<kmicu>wednesday: regular btrfs also works. But I understand. Only want to point out that fixing the issue is not trivial and will take days when performed on half-booted OS. So you can have a less frustrating path with installing a working config, fixing subvolumes on it (in a VM) and then reinstalling the system. (Personally, I’m doing exactly that cuz I also have a NixOS box with subvolumes setup similar to yours and wanted to recreate it on Guix System.).
<kmicu>In other words: I was in the same place, I gave up after 2 days xP
<wednesday>so your saying just have it with btrfs without the subvolumes? i'll probably end up doing that, but that makes me sad inside, maybe one day I can fix it ha
<wednesday>yea he seems to be doing what kmicu suggested, doesn't look like he is using subvolumes
<kmicu>wednesday: With a delcarative configuration we can reinstall OS in 5 minutes. That’s my plan - fix subvolumes and then reinstall OS in my desired file system layout.
<efraim>I didn't bother with subvolumes, I just wanted the compression and checksumming
<wednesday>it's been about a year since i've been on linux, been on bsds for a while, but back when I was on gentoo for several years I had a setup like this, so I thought it shouldnt be too hard to redo heh
<nckx>I can confirm that Guix System on btrfs without (early-mounted) subvolumes is a breeze :-)
<nckx>I've never had a compressed and heavily used btrfs last more than a year before panicking, but that's not Guix's doing.
*jonsger is happy that Guix doesn't use btrfs as default file system :P
<nckx>The checksums help me sleep slightly better than their history keeps me awake. It's a trade-off ;-)
<wednesday>I remember having one issue with btrfs some years ago but btrfs restore and such saved the dat
<nckx>jonsger: Using NAME there is just parametrisation for the sake of it, it serves no useful purpose (and I was as guilty of it in the past as anyone :-). I remove it when I find it. IIRC there was also some consensus on the ML but my duckduckfoo sucks.
<jonsger>oke, I understand. Though I wouldn't mass change it...
<nckx><kmicu> it’s not too difficult just core devs don’t use subvolumes → exactly.
<nckx>jonsger: I ‘fix’ it when I come across it, hence the pairing with updates (and if they're on their own it just means the update broke). I agree that we shouldn't mass-sed anything.
<bob20190227131>Pretty much thinking of using it because Guile and Lisp library management is a mess.
<jackhill>bob20190227131: Hi! What do you mean by safe?
<bob20190227131>jackhill: Have there so far been instances of malicious definitions or inserts like have happened with say... npm.
<jackhill>bob20190227131: I don't know, but a difference between Guix (and other GNU/Linux distributions like Parabola and Trisquel) and self-upload repositories like npm, rubygems, pypi is that changes to Guix go through a review process.
<nckx>bob20190227131: Not that we know of. And people do pay attention to commit logs, although we don't have a formal process for reviewing commits direct to master (as opposed to those posted to the ML first).
<nckx>ebrasca: Updating is as easy as: guix pull && sudo -E guix system reconfigure
<ng0>new packages are added to the packages section, or you install them to the user profile. I only ever added window managers and things like that to the system packages
<nckx>This is exactly like in the other distributions you mentioned (apt-get update && apt something).
<apteryx>ebrasca: adding new packages is done per user with 'guix package --install'
<ebrasca>If I like to install my system in other PC with all packages
<ng0>for example in netbsd one way I can update I do a cvs update of the sources, run build.sh, do the manual upgrade steps after the build,.. this is "reconfigure + guix pull".. and the user package updates via pkgsrc are "guix pull (as user) and guix package -u"
<ebrasca>How to make it if I don't have updated my config.scm
<ng0>wasn't solved by installing some fonts and fc-cache -vfi?
<ng0>i mean on other systems you can combine this.. i have C locale and german keyboard layout
<nckx>ebrasca: Sure. You'd set (locale "en_US.utf8") in your system configuration. I guess you have it set to Spanish now? It has no effect on the keyboard. But let's not try that before you can reconfigure without downgrading...
*nckx has (locale "en_GB.utf8") and (console-keymap-service "dvorak-programmer"), for example. Same for X.
<ng0>what are the permissions and ownerships on your .guix folders?
<nckx>ebrasca: It probably will if you use the full path (but no sudo!) again.
<kmicu>ebrasca: if you want to update system to the latest version you run ‘guix pull’ to pull latest changes and then ‘sudo -E guix system reconfigure /path/to/your/config.scm’. To install a font you use ‘guix package -i font-sil-charis’ and restart IceCat.
<kmicu>ebrasca: Could you show what ‘guix pull’ gives you?
<nckx>kmicu: The issue is that ‘guix pull’ doesn't work.
<nckx>ebrasca: If you have a working system configuration file you're almost there. You can add a ‘packages’ field to your operating-system declaration and those packages will be available system-wide.