Code change:
NixOS on boot loops waiting for devices with wrong names. According to device paths are split by ":", but for some persistent block device names we have ":" in valid paths. The boot is stuck trying to load: Steps to reproduce the behavior: NixOS using /dev/disk/by-path devices boot waiting loop Boot without waiting for nonexistant devices ! Please run and paste the result.
This is a recent phenomenon I've experienced a few times, on bcachefs. I'm not entirely sure why this happens, but since Linux 6.4.8 I believe, I haven't had this issue. There are two reasons why this could happen AFAIK: is messed up between the linux kernel and stage-1. needs to have all the devices loaded before trying to mount multiple. That's the best I have ATM. Current nix-info for reference: system: host os: multi-user?: sandbox: version: channels(mado): channels(root): nixpkgs:
I should also clarify in my case that it was a breaking bug, where I would have to reboot because one of the devices never loaded and would drop me into an error, until it worked.
it seems like you're describing a different issue with bcachefs and multiple devices separated by . This bug, as far as I understand, is about non-bcachefs block device paths that contain incidentally (not as a multi-device delimiter). I'd suggest filing a separate issue for your problem.
(But as the author of the change that introduced that behavior - - I suspect you might want to be involved here regardless :P)
My bad, the usual bad reading comprehension and I didn't look at the paths that were listed closely enough. I would suggest, if possible, using something like instead until this is fixed. As for the fix, while it would break the use-case of colon-separated if it is the aforementioned path.
This should be considered a bug. There are a lot of paths in that have colons in their name (including RAID UUID devices). Requiring users to know that devices with colons in their name are treated special is unreasonable, especially if it's not documented. If bcachefs requires this then I think we need a new configuration option or the stage 1 function needs to be extended so it considers the file system type before setting .
IMO, we should get rid of it for bcachefs (it's only use) and just use the new ` mechanism.
I don't use bcachefs so I don't know what the mechanism is. Is it safe to simply revert your patch to ?
Unfortunately no, because many people's auto-generated configs still use the ':' separator. It's something I think we'll have to do at some point though. I think the better option may be to omit a warning if it's being used (i.e: using bcachefs) until 24.05, backport that to 23.11, and remove it in 24.05.
I would suggest that we change the function to take an optional second argument, the file system type. If that argument is set and it is set to "" then (and only then) do we set . Of course, this only works if the auto-generated configs correctly set the file system type. Can you point me to the commit where you changed the auto-generation process?
Should be fixed in

Related discussion:
text: ''; linux_latest_hardened = linuxPackages_latest_hardened; <del> # Added 2023-11-18 linuxPackages_testing_bcachefs = throw "'linuxPackages_testing_bcachefs' has been removed, please use 'linuxPackages_testing', or any other linux kernel with bcachefs support"; linux_testing_bcachefs = throw "'linux_testing_bcachefs' has been removed, please use 'linux_testing', or any other linux kernel with bcachefs support"; </del> <ins> # Added 2023-11-18, modified 2024-01-09 linuxPackages_testing_bcachefs = throw "'linuxPackages_testing_bcachefs' has been removed, please use 'linuxPackages_latest', any kernel version at least 6.7, or any other linux kernel with bcachefs support"; linux_testing_bcachefs = throw "'linux_testing_bcachefs' has been removed, please use 'linux_latest', any kernel version at least 6.7, or any other linux kernel with bcachefs support"; </ins> lld_6 = throw "lld_6 has been removed from nixpkgs"; # Added 2024-01-08 lld_7 = throw "lld_7 has been removed from nixpkgs"; # Added 2023-11-19