This is to document some related annoyances in the Gales environment that I've noticed afresh but still aren't quite enough to preempt my other work right now.
First, the root filesystem device shows up as the generic "/dev/root" rather than the real device path (perhaps "/dev/sda1") when queried through any of the typical commands: df, mount, or even cat /proc/mounts. This is despite having a correct entry with the real device path in /etc/fstab. It's a pain because sometimes I need to check on what the real device is. True, I could look at the bootloader configuration, but this strikes me as a workaround at best because for one thing it's an obscure place to look and for another it's just a hollow declaration - basically a statement of what the device "should" be, assuming the config hasn't meanwhile changed and that you're even looking at the correct file, rather than looking at the current state of the system in a reliable way. I suppose if the relevant messages haven't been cycled out of the ring buffer yet there's also dmesg | grep 'Mounted root' which shows the low-level major/minor device numbers which you can then look up in /proc/partitions. (Edit: a more reliable way would be stat / and see the "Device:" number, though you have to unpack it and convert from hex.)
Note that there is no actual /dev/root node in the filesystem, though some distributions apparently create one dynamically. There's also this thing called "rootfs" which may or may not be equivalent.
A woodsman of the Slackware bent noticed this phenomenon appearing in 2008, eliciting some chatter (complete with admonitions that "it's better that way!") but no satisfactory answer as to what was causing it. My guess is that it's the default early userspace boot code in the Linux kernel that handles the "root=" and similar kernel command-line options to do the initial mount of the root filesystem (which obviously can't refer to any config files stored in that filesystem such as /etc/fstab). If you use a custom initramfs, its own /init script becomes responsible for such tasks, typically ending with a pivot_root switch_rootinit program, after which the /dev/root business is not observed.
The second annoyance was previously noted as a comment in the Gales /etc/rc ("run commands", /etc/examples/rc as created by skeleton.sh, coming from conf/rc in the repository), the shell script executed by the init binary which directs the remainder of the boot process. Namely:
msg Mounting filesystems mount -o remount,rw / # FIXME this doesn't pick up options from fstab. (maybe just busybox mount?) mount -a -n swapon -a
I typically add the "noatime" option onto the defaults for all my disk-backed filesystems, as I've never had any use for that atime field (time of last file access) and keeping track of it comes with a cost. Now that I'm building a fresh server, I find the problem has of course not resolved itself and the option has not been applied. But meanwhile somebody else noticed; the problem is indeed with the busybox mount implementation and still hasn't been fixed upstream.
For now I'll probably just edit /etc/rc to set any desired options directly. I don't like it because that script is intended to be generic, with any custom startup commands going in /etc/rc.local and options otherwise loaded from the appropriate config file (fstab in this case).
This might then raise the question of why the root filesystem even needs to be defined in fstab at all; for now I'd say that it does, to ensure it's covered by the automatic filesystem check that needs to be performed at boot time before it gets remounted read-write.