Gregory's ServerI moved to a new drive, built and installed system with guix system init. Aaand it stucks during the boot. Any ideas why?
 13 comments
@JayLittle what you mean? I updated UUIDs in the configuration for both Luks and efi partitions.  @abcdw My guess was that you had cloned your partitions, gotten new UUIDs and hadn't updated /etc/fstab with the new UUIDs. Or maybe your bootloader is pointing to a specific partition UUID and your boot parameters need to be updated? It's hard to tell given such a small portion of the total dmesg output. @JayLittle I didn't clone them, partitioned from scratch. Updated my current config according to be UUIDs. This is all output I get. I'm also able to boot into gnu.repl, but didn't find anything useful with it yet.  @abcdw I ran into this when I was learning Guix, but I blamed it on my inexperience and it eventually went away with more config changes/system inits. I doubt inexperience is your issue, though :blobfoxlaughsweat:, and now I'm wishing I'd taken better notes. As I recall, I reduced my config down to simply what was needed to boot and login, then built back from there and didn't encounter it again. @dpflug hehe, that's right :) @blasfisq I tried both fresh kernel and the one I used before. Also, my USB stick boots with a fresh kernel. @blasfisq @dpflug My bet that the problem is in /var being on a separate partition (subvolume), updated the configuration and will check it when it finishes to build. @abcdw I suspect that's the spot where execution is supposed to pass from the initrd to the real root. Looks like it's governed by gnu/build/linux-boot.scm, line 443. It doesn't output any messages unless /home exists or /init doesn't. It does disconnect/reconnect the console. Maybe there's a race condition or something there? It's also possible, down at line 660, that to-load isn't defined, so all of that is being skipped. |
@abcdw Partition UUIDs changed so fstab is out of date?