Re: [gentoo-user] Re: Strange new behavior from the "mount" command

[Mike Gilbert]

On Mon, Apr 20, 2015 at 3:21 PM, walt <w41ter@×××××.com> wrote:
> On 04/19/2015 05:45 PM, Mike Gilbert wrote:
>> On Sun, Apr 19, 2015 at 6:18 PM, walt <w41ter@×××××.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.