From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DCA3F138CA2 for ; Mon, 20 Apr 2015 20:01:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7943FE085E; Mon, 20 Apr 2015 20:01:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 325AEE07B3 for ; Mon, 20 Apr 2015 20:01:31 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 29DE1340940 for ; Mon, 20 Apr 2015 20:01:30 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so141607588ied.1 for ; Mon, 20 Apr 2015 13:01:27 -0700 (PDT) X-Received: by 10.42.23.17 with SMTP id q17mr20540826icb.4.1429560087920; Mon, 20 Apr 2015 13:01:27 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.64.124.229 with HTTP; Mon, 20 Apr 2015 13:01:07 -0700 (PDT) In-Reply-To: References: <1737884.HMIx8dUkP1@bluering> <3398594.KigUUE6dli@navi> From: Mike Gilbert Date: Mon, 20 Apr 2015 16:01:07 -0400 Message-ID: Subject: Re: [gentoo-user] Re: Strange new behavior from the "mount" command To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: ccee98fa-251c-45f9-8ae9-bac9b771aba5 X-Archives-Hash: 95dcf633af66bc4421859f0206f66162 On Mon, Apr 20, 2015 at 3:21 PM, walt wrote: > On 04/19/2015 05:45 PM, Mike Gilbert wrote: >> On Sun, Apr 19, 2015 at 6:18 PM, walt 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.