| 1 |
On Mon, Apr 20, 2015 at 4:01 PM, Mike Gilbert <floppym@g.o> wrote: |
| 2 |
> On Mon, Apr 20, 2015 at 3:21 PM, walt <w41ter@×××××.com> wrote: |
| 3 |
>> On 04/19/2015 05:45 PM, Mike Gilbert wrote: |
| 4 |
>>> On Sun, Apr 19, 2015 at 6:18 PM, walt <w41ter@×××××.com> wrote: |
| 5 |
>> |
| 6 |
>>>> As a quick-and-dirty way of testing your idea I moved /etc/fstab out of the way. |
| 7 |
>>>> |
| 8 |
>>>> I was surprised to learn that "mount" doesn't care about fstab, and doesn't even |
| 9 |
>>>> bother to look for it (when invoked with no arguments). |
| 10 |
>>>> |
| 11 |
>>> |
| 12 |
>>> It reads information from /etc/mtab primarily, as well as |
| 13 |
>>> /run/mount/utab. Also, if /etc/mtab is a symlink, it reads from |
| 14 |
>>> /proc/self/mountinfo instead of /etc/mtab. |
| 15 |
>>> |
| 16 |
>>> It seems like there is probably some difference in the data it is |
| 17 |
>>> reading from those files on your system. Maybe post them so we can all |
| 18 |
>>> have a look? |
| 19 |
>> |
| 20 |
>> I really appreciate your help, thanks. Sorry there's so much to read through. |
| 21 |
>> |
| 22 |
>> I avoided the possible caching problem Francisco mentioned by booting the machine |
| 23 |
>> without an /etc/fstab, so it wound up with only / and swap partitions actually |
| 24 |
>> mounted. |
| 25 |
>> |
| 26 |
>> Here are the files that "mount" opened (running with no arguments) that it |
| 27 |
>> normally would not open: |
| 28 |
>> |
| 29 |
>> #cat /proc/cmdline |
| 30 |
>> BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz root=PARTUUID=345FD3C4-9E1C-49EB-859C-E3A3034325B3 rootwait init=/usr/lib64/systemd/systemd |
| 31 |
>> |
| 32 |
>> #cat /proc/self/mountinfo |
| 33 |
>> 12 0 8:21 / / rw,relatime shared:1 - ext4 /dev/root rw,data=ordered |
| 34 |
> |
| 35 |
> I think this may be related to having /dev/root appear in |
| 36 |
> /proc/self/moutinfo. In this case, mount will look for your root |
| 37 |
> filesystem in /proc/cmdline, and resolve it from there. |
| 38 |
> |
| 39 |
> Since your kernel command line has a PARTUUID tag, it probably needs |
| 40 |
> to scan the partition tables to resolve that. This is mostly a SWAG; I |
| 41 |
> didn't trace the code to this point. |
| 42 |
|
| 43 |
Also, there was a recent patch changed in gentoo-sources to prevent |
| 44 |
PARTUUID from appearing in /proc/self/mountinfo. This would explain |
| 45 |
why this is a "new" behavior for you. |
| 46 |
|
| 47 |
https://bugs.gentoo.org/show_bug.cgi?id=467266 |
Archives