On Mon, Apr 20, 2015 at 3:21 PM, walt <w41...@gmail.com> wrote: > On 04/19/2015 05:45 PM, Mike Gilbert wrote: >> On Sun, Apr 19, 2015 at 6:18 PM, walt <w41...@gmail.com> wrote: > >>> As a quick-and-dirty way of testing your idea I moved /etc/fstab out of the >>> way. >>> >>> I was surprised to learn that "mount" doesn't care about fstab, and doesn't >>> even >>> bother to look for it (when invoked with no arguments). >>> >> >> It reads information from /etc/mtab primarily, as well as >> /run/mount/utab. Also, if /etc/mtab is a symlink, it reads from >> /proc/self/mountinfo instead of /etc/mtab. >> >> It seems like there is probably some difference in the data it is >> reading from those files on your system. Maybe post them so we can all >> have a look? > > I really appreciate your help, thanks. Sorry there's so much to read through. > > I avoided the possible caching problem Francisco mentioned by booting the > machine > without an /etc/fstab, so it wound up with only / and swap partitions actually > mounted. > > Here are the files that "mount" opened (running with no arguments) that it > normally would not open: > > #cat /proc/cmdline > BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz > root=PARTUUID=345FD3C4-9E1C-49EB-859C-E3A3034325B3 rootwait > init=/usr/lib64/systemd/systemd > > #cat /proc/self/mountinfo > 12 0 8:21 / / rw,relatime shared:1 - ext4 /dev/root rw,data=ordered
I think this may be related to having /dev/root appear in /proc/self/moutinfo. In this case, mount will look for your root filesystem in /proc/cmdline, and resolve it from there. Since your kernel command line has a PARTUUID tag, it probably needs to scan the partition tables to resolve that. This is mostly a SWAG; I didn't trace the code to this point.
