You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a Btrfs filesystem, the perl code below does not understand the difference between a mounted subvolume, and a regular directory that has been bind mounted.
Having a bind mounted /nix or /boot directory causes rebuild to fail.
Do you manually bind mount /nix or /boot in the installer? If so, why?
(When I started using NixOS there was this idea that nixos-generate-config should/could be re-run to update after hardware changes, but IME that never worked; it generated fileSystems config that I didn't want in hardware-configuration.nix. So I never run it outside of the installer environment. And in the installer environment the mounts are much simpler / well known.)
Do you manually bind mount /nix or /boot in the installer? If so, why?
The main issue here isn't so much to do with the specific mounts, but rather that any bind mount you'd like to configure cannot come from a btrfs source, or else nixos-generate-config is going to get something wrong. It'll either yell that it isn't a (sub)volume, or it'll create a bad bind mount if it's actually incidentally a bind mount.
TL;DR: We're not really handling bind mounts right here at all.
Describe the bug
On a Btrfs filesystem, the perl code below does not understand the difference between a mounted subvolume, and a regular directory that has been bind mounted.
nixpkgs/nixos/modules/installer/tools/nixos-generate-config.pl
Line 440 in f199d57
Steps To Reproduce
Having a bind mounted /nix or /boot directory causes rebuild to fail.
Expected behavior
Recognize that directory is bind mounted, and not a subvolume.
Related
Possibly related bugs. #53177 #341481
Notify maintainers
@bjornfor @anthonyroussel @Atemu @Mic92 @lheckemann @roberth @mberndt123 @ajs124 @name-snrl @lukegb @RaitoBezarius @SuperSandro2000 @Luflosi @catap @Ma27 @Artturin @worldofpeace @edolstra @prusnak
The text was updated successfully, but these errors were encountered: