<fusion809>Howdy folks after a 12 hour installation process I was able to install GuixSD to a VM. The problem is booting it. grub-install --target=i386-pc /dev/sdb (which was run by the installer) returned: `grub-install: error: failed to get canonical path of `unionfs`.` I've DuckDuckGo searched this error but all the results seem to pertain to Windows. I have only a root partition on my GuixSD installation is that problematic?
<fusion809>Using the live USB .img file per the VM installation guide
<db48x>hrm. I used that the other day and it worked fine :)
<fusion809>Would my configuration file (i.e. the one used by guix system init to build the system) help? wgetpaste doesn't seem to want to work for me. Ran mount | wgetpaste and it gave "Apparently nothing was received. Perhaps the connection failed..." Then wrote mount output to output.log file and then ran cat output.log | wgetpaste and it gave the same error. My net is working fine as I managed to install wgetpaste without a problem
<fusion809>Oh rofl wget command wasn't found. Ran with --verbose and that's apparently the cause of the problem. Odd that wgetpaste doesn't draw wget in as a dependency or so it seems
<fusion809>That's odd I installed wget and still wgetpaste is failing... Trying to diagnose the problem with the --verbose option
<fusion809>Certificate of paste.pound-python.org is not trusted.
<fusion809>A BIOS boot partition can be at the end of a disk right? I've only ever had them at the start of the disk but in order for me to keep my existing data I'm going to have to reduce the size of the existing root partition and place the BIOS boot partition at the end of the disk
<brendyn>looks like it uses this thing 'native-search-paths' somehow but there isn't much documentation on it
***urbain1 is now known as numerobis
<fusion809>Due to my bootloader issues last time I reinstalled Guix with a BIOS boot partition this time and while the installer runs with no errors reported (including the GRUB install at the end) GuixSD won't boot. The GRUB dialog where it says "Booting from hard disk... GRUB Loading" does appear for a second before it disappears at that point nothing happens the system doesn't start.
<fusion809>Any ideas what to do? I'm kinda stuck here. Got no "error message" to report and search DuckDuckGo with
<thomassgn>fusion809: just wild guesses, but check the arguments and whether the root= and such point to correct FSs. I had some trouble with that when I installed guix ca. a year ago.
<thomassgn>mm, right. Then I don't know. Like, check your pointing at the right device in config. But you already did that, probably. Don't think it should be a problem but you could use one of the stable paths instead of the numbered paths that might change. e.g. /dev/disk/by-id/ instead of /dev/sda
<fusion809>The grub config refers to the root filesystem by its label not its location (i.e. /dev/sdb)
<fusion809>How do I check if I set the label on my /dev/sdb1 partition right?
<fusion809>I think I set it to my-label per the guide but I could be wrong
<fusion809>Well if anyone has any epiphanies on how to fix I'll be here and eager to try 'em
<xelxebar>fusion809: Here's my mental checklist when debugging boot issues, in order boot order: Is my bios/uefi pointing at the device where grub resides? Is grub correctly installed on said device? Is the grub menu failing to display? Can grub see the device that the kernel and initramfs are on? Is grub.cfg pointing at the correct device? Is the root=<device> kernel cmdline parameter correctly set? Is the initramfs screwed up?
<xelxebar>You seem to be stuck somewhere in between "is grub installed correctly?" and "is the grub menu failing to display?" questions
<fusion809>Ya it's failing to display. But it displays fine when booting from USB image so it's not like a graphics issue. GRUB is giving no errors when I run grub-install.
<fusion809>From what I can tell I can't chroot into my GuixSD system from the live USB image can I? To chroot I mount up the file systems (root, proc, dev, sys) and then chroot in. But proc, dev and sys file systems do not exist, by default, in the GuixSD root partition.
<xelxebar>Well, if you're really wanting to work in a chroot environment, you'll have to bind mount proc dev and sys from the host system
<xelxebar>I would check your grub.cfg to make sure you haven't disabled the menu by accident
<xelxebar>If that checks out, then you really should make sure that the correct grub got installed to the correct location
<fusion809>Ya I know that's how I do so on other distros but when I mount my root partition on /mnt, /mnt/proc doesn't exist, it does for other distros though, likewise /mnt/dev and /mnt/sys don't exist.
<fusion809>No UEFI. Ya it's installed to the correct location /boot/grub I noticed that earlier when I was checking where to look for grub.cfg
<xelxebar>On my system, for example, I used to have grub installed, but nuked it in favor of a different boot method. However, if my bios tries to boot my drive, it'll still show "Loading GRUB" or something and just hang there
<fusion809>Oh goodie protective MBR does exist according to gdisk
<xelxebar>Okay. And how'd you go about installing grub? What command did you issue?
<fusion809>Well at first I just let guix system init do it. But after that I tried to ensure it was installed so I had the BIOS partition mounted to /boot and I ran grub-install --target=i386-pc --root-directory=/mnt /dev/sdb
<xelxebar>Hmmm... Are you sure your bios knows about GPT?
<xelxebar>Then use the 'r' command to access the "recovery and transformation options"
<xelxebar>From there the 'g' command will convert your gpt to mbr
<xelxebar>And then 'w' will write those changes to disk
<xelxebar>You might want to save a backup of the partition table before doing that, just in case
<fusion809>Thanks, I actually found the answer using DuckDuckGo and it matched yours so that's a good sign, the thing about search engines is they've got no brains and sometimes they give you wrong results
<fusion809>Just goes to show that persistence pays off. I honestly thought it was doomed to failure. Btw when GuixSD 1.0 comes out (I know that's probably a decade or so away) do yas plan to have a graphical installer or do yas want it to always be an advanced OS, including in its install like Gentoo is.
<castilma>fusion809: using kvm instead of qemu in the cli should work too.
<xelxebar>Yeah. Advice I would give is to read the man pages for all the cli tools you use
<xelxebar>You don't have to read them all at once and probably won't understand everything, but if you take the time to futz around with the tools, you'll learn stuff pretty fast
<xelxebar>There are all kinds of cool man pages. You can search through them with man -k <something>
<fusion809>Thanks. Ya that's usually what I do, but yeah a lot of the times some of it I don't quite get, the phrasing of man pages isn't always all that clear, to me at least.
<xelxebar>There's even man boot which gives a high level overview of the boot process
<xelxebar>Yeah, the man pages can be really dense. They're not immediately useful, so don't worry about not understanding everything (none of us do :P). Just try to understand what you can and dig into the things that you don't but are curious about.
<xelxebar>The nice think about man pages is that you will pick up a lot of the lingo quickly which makes searching for answers to problems a lot easier
<rama_dan_>i noticed guix has a lot of packages for Java libs like Apache Commons .. and i can't see how it would be a good idea for Guix maintainers to work on that stuff too
<shiranaihito>i noticed guix has a lot of packages for Java libs like Apache Commons .. and i can't see how it would be a good idea for Guix maintainers to work on that stuff too
<shiranaihito>considering people use Maven to manage Java dependencies, and it's a big ole mess anyway
<rekado_>shiranaihito: is there another way to obtain reproducibly built Java packages?
<rekado_>we’re treating Java sources like any other packages.
<fusion809>Hey is there a command to make guix perform tasks (e.g. download tasks) in parallel therefore speeding it up? At the moment even installing icecat takes a matter of hours, mostly due low download speeds. This is despite my network being perfectly capable of >3 MiB/s download rates. If Guix allowed download jobs to run in parallel this wouldn't be quite so problematic.
<fusion809>I've checked guix package's man page of course.
<fusion809>Under GNOME whenever I press the down button Totem opens and I haven't changed its keyboard shortcuts or anything. Likewise when I press the up arrow screenshots are taken. Is this normal? I know under GNOME on other platforms it doesn't happen but does GuixSD have a customized version of GNOME?
<fusion809>Might be keyboard related it seems, I'll see how to fix.
<kai_w>The install docs suggest setting the password with 'passwd' for install via ssh, but 'passwd' does not seem to be present in the install image. Is this correct, or am I missing something?
<fusion809>Hi, I've spent the last 20 mins trying to fix this problem myself, but I have this config file https://paste2.org/9jpLs9IB and whenever I run guix system reconfigure /etc/config.scm --max-jobs=5 --cores=5 I get the error: "/etc/config.scm:46:2: error: invalid field specifier". I've tried checking that all brackets are matched and it seems logical to me.
<bavier>fusion809: "define" is not a valid operating-system field.
<bavier>fusion809: I'd suggest replacing the %desktop-services on line 44 with the "(modify-services %desktop-services ...)"
<fusion809>Since my system update Guix doesn't seem to want to work for me, when I run `guix package -i onboard` I get: "guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused"
<fusion809>I did have to do an abrupt reboot (due to my since freezing) since I noticed this error too if it helps.
<fusion809>Running guix-daemon as root fixes it. Is there a way to remove the requirement to run guix-daemon manually?
<fusion809>Rebooted a few times now to check if this is true, even tried moving /var/guix/daemon-socket/socket to ~/ (moving it instead of deleting it in case I needed it again) in case it was meant to be removed before I shutdown when I had to reboot due to the freeze and it didn't fix it either
<bavier>fusion809: it sounds like you're guix-daemon service is failing to start
<fusion809>Hmm twas occurring to me too so I ran dmesg (as I'm used to systemd and I haven't a clue what the equivalent to journalctl -xe is for shepherd
<fusion809>and grepped it through "daemon" and "guix" (separately) and it returned no results
<fusion809>I know there's a herd status command but `herd status guix-daemon` returns an error (complaining it's doesn't exist) as does `herd status guix` and `herd status daemon`
<fusion809>Oddly since this guix-daemon error has arisen I haven't had a problem with the keyboard. Before the freeze forced shutdown the keyboard problem was there now it's not.
<bavier>fusion809: so the console-keymap-service is working :)
<bavier>fusion809: sorry, I'm not at a guixsd system atm
<fusion809>Ya at least that's something. That's fine, you've been very helpful so far. Frankly if it weren't for ya help I probably would have given up on GuixSD, at least for a few months until I get very bored again.
<bavier>fusion809: double-check your /etc/config.scm and read the shepherd manual to help debug
<fusion809>Whenever I reboot, even if I delete /var/guix/daemon-socket/socket, the socket is re-made. Is that relevant? To me it suggests something is running that is re-generating it but whether it's the Guix daemon is to be seen, my guess is no.
<fusion809>I checked my config.scm file and it seems to be in order from what I can tell, but given that Guile isn't a language I'm strong in I could be completely wrong. If you want to look at it it's much the same as when you saw it the last time except for the last few lines. Here it is: https://paste2.org/L8Hk41vv
<fusion809>Might reconfiguring with guix system reconfigure be worthwhile? Maybe that might fix the issue, at least that's my guess.