perhaps @ivanbrennan can validate this?

perhaps @ivanbrennan can validate this?

@worldofpeace I'm happy to, but do you know how I could test it without risking locking myself out of my system?

You can probably test this with nixos-rebuild build-vm -I nixpkgs=/path/to/this/pr/checked/out and starting the VM afterwards.

@worldofpeace @Emantor I tested using build-vm as suggested, and as far as I can tell it looks good! The FATAL warning is gone, the build succeeded, and I was able to run the vm. That doesn't test the drive decryption, but it certainly sounds like that should work.

Again, since I only have access to one machine (and need it for work), I'm hesitant to try it for real (not in a vm, actually rebuild and reboot), but I'm probably being too cautious.

For reference, my test involved:

1. checking out the PR branch,

git clone git@github.com:Emantor/nixpkgs.git -b fix/boot_kernel_module ./test-nixpkgs

2. building against that checkout,

sudo nixos-rebuild build-vm -I nixpkgs=./test-nixpkgs --max-jobs 1

3. running the resulting vm,

./result/bin/run-nixosbox-vm

The full build logs are in this gist: https://gist.github.com/ivanbrennan/e006577dd65d26d6a6f20435e9912f57#file-nixos-build-vm-log

The kernel modules section can also be seen here:
https://gist.github.com/ivanbrennan/e006577dd65d26d6a6f20435e9912f57#file-kernel-modules-log

I noticed a bunch of warnings related to udev rules, like:

substituteStream(): WARNING: pattern '"/sbin/modprobe' doesn't match anything in file '/nix/store/0l4g1v3jj653psy5db80qajii7ql40s2-udev-rules/00-path.rules'

The relevant section of the build logs can be seen here: https://gist.github.com/ivanbrennan/e006577dd65d26d6a6f20435e9912f57#file-udev-rules-log

I don't think the udev rules warnings are related, nor do they look problematic -- just something I noticed when searching the logs for "fatal", "error", and "warning"

@ivanbrennan

Again, since I only have access to one machine (and need it for work), I'm hesitant to try it for real (not in a vm, actually rebuild and reboot), but I'm probably being too cautious.

Since this is NixOS, even if the new system doesn't boot you can still start an older generation from the boot menu which will include the old generated initramfs with the module. The only thing which could remove the generation would be automatic run of nix-collect-garbage -d, ensure that this is not enabled in your configuration.

@Emantor

Since this is NixOS, even if the new system doesn't boot you can still start an older generation from the boot menu which will include the old generated initramfs with the module. The only thing which could remove the generation would be automatic run of nix-collect-garbage -d, ensure that this is not enabled in your configuration.

When I boot up, I'm prompted for the passphrase to decrypt the root drive before arriving at the boot menu (where generations are listed). This is why I'm not sure I'd be able to rollback if it went wrong.

When I boot up, I'm prompted for the passphrase to decrypt the root drive before arriving at the boot menu (where generations are listed). This is why I'm not sure I'd be able to rollback if it went wrong.

Hm, than support for decryption should be in the used bootloader, which from your description should be grub. Since this initial decryption to access the boot partition does not use the kernel at all, the grub decryption shouldn't break even if we remove the kernel module. Please confirm this from your configuration, it should contain something like:

    boot.loader.grub = {
      enable = true;
      version = 2;
      device = "nodev";
      efiSupport = true;
      enableCryptodisk = true;
    };

(copied from the NixOS wiki here). This would mean that it should also be safe to test this PR on your system. Of course I understand if you are still reluctant to test the change on your production system, no pressure 😃. It would be helpful to have a minimal reproducible configuration, than I could test this against a local VM.

@Emantor I'm using the systemd-boot EFI boot loader in this case:

boot.loader.systemd-boot.enable = true;

(I'm no expert, but on this machine, a Dell XPS 13 9360, I had to go with EFI rather than grub to get things working.)

Nonetheless, it sounds like your main point -- that the drive decryption doesn't use the kernel -- still applies.

I'll put a minimal reproducible configuration together and post it here. Thanks for all your help, by the way!

@Emantor I was mistaken - on bootup, I'm not prompted to decrypt the drive until after choosing a generation. It had been a while since I did a full reboot. Sorry for the confusion.

@Emantor I was mistaken - on bootup, I'm not prompted to decrypt the drive until after choosing a generation. It had been a while since I did a full reboot. Sorry for the confusion.

Than a test on your primary machine shouldn't block on anything 👍

@worldofpeace @Emantor Is there anything else I can do to help this along?

@worldofpeace @Emantor Is there anything else I can do to help this along?

You could test this on your main machine, alternatively post a minimal configuration to reproduce your bug, than I can test this fix. Testing on your machine can be done with:
nixos-rebuild switch -I nixpkgs=/path/to/this/pr/checked/out and a reboot, if it doesn't work just choose an older generation. Make sure you don't have automatic garbage collection enabled.

I don't currently have the time to come up with a reproducing configuration myself, unfortunately 😞

@Emantor Here's my attempt at a minimal reproducible config:
https://github.com/ivanbrennan/nixbox/tree/19730f0ad57531451093ae2dea4dde694b30a31e

I built a vm with it and was able to get to the login prompt. I imagine hardware-configuration.nix would require some changes to run on a different machine (e.g. device ids).

@worldofpeace @Emantor I tested this on my machine and rebooted. It all worked correctly 👍

As suggested, I rebuilt with

nixos-rebuild switch -I nixpkgs=/path/to/this/pr/checked/out

rebooted, and was able to decrypt the drive and log into the system without incident.

@worldofpeace Is there anything else I can do to help this get merged?

@fpletz Thanks! The delay was mostly because I was afraid to test this change (with a rebuild and full reboot) on my one (and currently only) machine. I finally did, however, and it worked out fine.