Harrowing NixOS Hangup: An Exercise in AI Assistance and (my transient lack of) Critical Thinking

It all started when I stepped away from my PC for a few minutes to drink water or eat food or something, I can’t even remember at this point. I know I was working on something before and was planning on coming back and continuing so I just locked GNOME and walked away. When I come back, I find that the system has hibernated so I attempt to wake it but this fails. This isn’t new—whenever my system has hibernated, I haven’t been able to wake it. My CPU cooler will spin up, my monitor light will go from orange to blue, and I will eventually be greeted with a dreaded “No Signal” message. Fine whatever. I do a hard shutdown just by holding the power button down. I’ve done this before, but this is probably the point of failure. It shuts down without complaint, so I boot it again, mildly annoyed but unworried. Up till now I have dealt with all this—I had been meaning to disable hibernation for a while and just didn’t get to it.

On the boot sequence I’m greeted with a very scary error:

kernel panic - not syncing VFS: Unable to mount root fs on "" or unknown-block(0,0)

This is new. As an IT expert, I employ my one and only trick⁠.

kernel panic - not syncing VFS: Unable to mount root fs on "" or unknown-block(0,0)

As I’m out of options, I start to panic slightly.

Yeah yeah atomic distribution, whatever—that’s only helpful when the previous generations can load too. This is a kernel error and the only gens I have access to are on the same version of Linux. I figure that I should read the scary error message to see if there’s any information I can parse. It’s complaining about not having space on /boot. Hm. I have a laptop, so I get to searching and LLMing (Gemini 2.5 Pro via AI Studio).

So this specific kernel error doesn’t seem too deadly, in that I find a decent amount of articles and nobody opens with “Oop it’s over you might as well wipe it” so yay? Still stressed, I start perusing them but can’t fully parse it and so can’t directly apply insights to my situation. Gemini has some strange ideas but I might as well do as it suggests I think. What could go wrong?

Gemini tells me that I should live boot into my NixOS system installer. I don’t understand why I need the installer itself and not just a working Linux installation from a USB, but whatever. I happen to still have my NixOS installer which I’ve been borrowing from Jin forever now, and it’s running Plasma. I boot off that and see what else Gemini says I should do.

All this happened just 45 or so minutes ago but I’ve already forgotten most/blocked it out—I mess around for a while following Gemini. In my state of anxiety, I write a terrible prompt and don’t inform Gemini of my setup at all: I’m dual booting Windows and NixOS off UEFI, and my NixOS bootloader is systemd. My Nix drive is also encrypted, and I fail to mention that. I spend a little time figuring out how to decrypt and mount my device. It takes me a lot more time to realize that I’m looking for a boot partition on my second drive when it is calmly sitting on my first drive.

GEMINI:
Your system has a completely valid, albeit less common, two-drive setup:
- Drive 1 (/dev/nvme0n1): Contains the EFI System Partition (ESP). This is the "ignition switch" for your entire computer. All bootloaders (Windows and NixOS) live here.
- Drive 2 (/dev/nvme1n1): Contains the actual operating systems, including your encrypted NixOS root on nvme1n1p3.
The reason every previous attempt failed is that we were looking for the boot partition on the same drive as the OS. The efiSysMountPoint error was correct all along: there was no mounted EFI partition at /boot because we hadn't mounted it from the other drive.

Duh. That was painful, but I muddle around a bit and finally manage to get into a bare version of my NixOS via chroot. “I’m in”, as they say. I don’t know who, but they say it. On to deal with this full boot partition business.

I clean out some old configs using the typical

nix-env --delete-generations +5
nix-collect-garbage -d

and rebuild my configuration. No errors is a good thing right? No complaints about the boot partition being full or all that. But Gemini said that I should expect output saying something about updating the bootloader, and I didn’t see that. Hm.

Gemini then suggests that I check the bootloader to see if it has updated. It tells me to check /boo/EFI/NixOS/ and see when the files were modified. I fix its command and…

They are from 3 hours ago.
GEMINI:
Okay, that is the definitive proof. Thank you for checking so carefully.
**This means the `nixos-rebuild boot` command is NOT working correctly.**
Let's analyze what this tells us:
1.  The command _is_ successfully building a new system generation in the main Nix store (which is on your `/mnt` partition).
2.  However, at the very final step, it is **failing to copy the new kernel and initrd files** into the `/boot/EFI/NixOS/` directory.
3.  The files you are seeing are from when you first started this recovery session, not from the command you just ran.
There is only one common reason for this specific failure: **Your `/boot` partition is still critically full.**

Gemini is right, and gives useless advice which I naively follow for another ~45 minutes or so. In short it says I should:

Manually Run the Bootloader Installer via `nixos-install-bootloader --flake .#`.

nixos-install-bootloader doesn’t exist.

I’m growing to get more annoyed at Gemini than worried about bricking my NixOS install, so I decide to venture off the beaten path and actually think. I definitely suffer from Gell-Mann amnesia when working with LLMs, but I will maintain that most frontier models can do certain things better than I could—and these are usually things I don’t want to learn, like HTML/CSS/JS. So I’ve been appealing to the authority of an LLM here because I know nothing about NixOS and less than nothing about Linux, and those first pages I found were nigh-on impossible to understand. But now Gemini is fully hallucinating deus ex machina commands which is usually a good sign that your problem is too difficult for these things to solve so I finally decide to turn on my brain and debug.

The first thing I do is find the NixOS wiki and see its entry on bootloaders, and find that they seem to have pertinent instructions. I follow one to remove old generations (adapted to run in chroot), and then follow the instructions for reinstalling the bootloader. They even have a section “From an installation media” which makes things mighty convenient. I can follow instructions…

Nothing happens. No errors, but more importantly no successes.

Ok so that was also useless and somehow my boot partition is still full. I don’t know how to deal with this elegantly.

A closer inspection of this directory reveals an /EFI which is large. Hm. There’s some Windows stuff (icky), the NixOS stuff I’ve been dealing with, a systemd dir, and lastly some other random stuff that I get the feeling I shouldn’t delete. I copy the dir to ~ and start thinking.

As I dropped at the start, I had been using systemd. It was doing fine, well until now, so I hadn’t thought about it at all. Now, though, moving away from systemd seems quite nice. So I delete the systemd directory, change my configuration.nix to use Grub as the wiki details and build a new generation. After a little tweaking of the exact commands required to enable GRUB, it looks like I’m good to go. The space issue has been dealt with by applying direct force by way of rm -rf (which hurt, but I had a copy so it hurt less?) and now I was on a new bootloader so there’s no way anything couldn’t work, right? A quick reboot later and I’m staring at GRUB.

It doesn’t have my Windows install. Hm. Shelving that thought, I try to boot into NixOS—success! I’m asked for the password for my drive instead of the scary kernel failure, finally.

At this point I’m so glad to be done with this. It’s about 1AM and I’ve finally fixed this. Hip hip hooray for GRUB amiright?

But back to Windows. I have data in Windows that I need and I am not in the mood to go and fix another bootloader issue. I suspect that my installation of GRUB was incorrect and I didn’t tell it to respect Window in UEFI so it just wiped it.

A quick ls later, I find that my suspicions are confirmed. No Microsoft directory anymore, so no Windows in GRUB. Different problem for a different day? Nah.

Smugly, I copy over the required Windows folder from my backup of /EFI I made just before swapping to GRUB. Minor configuration and a little nixos-rebuild should set up GRUB to recognize Windows and respect that folder.

I’ve never been happier to be able to boot into Windows.

Moral of the story: Use GRUB? Also maybe think and learn a bit, even if its unfamiliar and difficult and it would be ridiculously convenient if the LLM could obviate the problem like it does for some things (Regex, Google Sheets ARRAYFORMULAs, other foul machinations). But now I know the tiniest bit more about Linux and my specific Windows/NixOS setup and their interplay, and so on. Sure the knowledge is probably brittle and transient, but hopefully I should be able to remember a little bit if I ever have to do something like this again, and that little knowledge could hopefully bootstrap a solution. In 2025 I’ve been keeping up with LLMs and have been trying to use them more, ‘cause it doesn’t seem like they’re going anywhere so I might as well learn what I can do with ‘em. I’m sure a critique someone will level is that I was using a “bad” model. I have access to ChatGPT Edu (~ Plus), and I did try 5 Thinking. Surprise surprise, it said basically the same things as Gemini. Once you’re out of distribution of one of the top models, I’ve found that usually none of them can help. So yeah, think for yourself—a truism, truly, but necessary. I find it so easy to slip out of the habit, which is scary—but I haven’t built a proper habit or dependency yet. I’m more expecting too much and underestimating my own capabilities in these regards.

Anyway, use GRUB.