Hi all, Since jmcneill's commit of src/lib/libutil/getfsspecname.c 1.5, NetBSD supports the special string "ROOT." as an alias for the root device in /etc/fstab. This can be used to avoid hard-coding the device name of the root disk on bootable disk images, allowing a single image to be booted from disks having different device names.
This feature is currently used by the ARM images, but not by the images for other architectures. I would like to change this. My immediate motivation for this is to fix PR 51503, "7.0.1/amd64 USB install image root mount fails when sd present", but I belive it would also be useful on live images as well as install images, and on other architectures. Note that I am not proposing changing the fstab that gets written to the target disk when installing a system using sysinst, only that of pre-built disk images such as those from "build.sh install-image" or "build.sh live-image". The question is, is there any reason to keep the existing machinery for specifying a fixed device name via the BOOTDISK make variable? Or in other words, can anyone think of an architecture or type of disk image where the "ROOT." reference might not work, or where a hard-coded root disk device in /etc/fstab might otherwise be desirable? If not, the change I'm proposing would basically amount to changing "/dev/@@BOOTDISK@@" to "ROOT." in src/distrib/common/bootimage/fstab.in and fstab.install.in, followed by a bunch of cleanup work to remove things that are no longer used or needed, such as all references to BOOTDISK in the Makefiles. The "build.sh live-image" target currently builds two live images each for i386 and amd64, with names containing "-wd0root" and "-sd0root", respectively. With the proposed change, these would become almost identical, differing only in size and the OMIT_SWAPIMG setting, and probably ought to be merged into one. Other architectures only have at most a single live image each, but their names also contain strings like "-sd0root" or "-ra0root" that would now be meaningless and should be removed. Comments? Objections? -- Andreas Gustafsson, g...@gson.org
