From: Dave Chinner <david@fromorbit.com>
To: Wu Guanghao <wuguanghao3@huawei.com>
Cc: aalbersh@kernel.org, "Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, yangyun50@huawei.com
Subject: Re: [PATCH] libfrog: obtain the actual available device when the root device is /dev/root
Date: Wed, 10 Sep 2025 10:06:07 +1000 [thread overview]
Message-ID: <aMDA7wJ5pO91Fewx@dread.disaster.area> (raw)
In-Reply-To: <6fb6fa53-a1e4-19f0-87e9-443975d2961c@huawei.com>
On Tue, Sep 09, 2025 at 07:29:02PM +0800, Wu Guanghao wrote:
> When starting a Fedora virtual machine using QEMU, if the device corresponding
> to the root directory is the entire disk or a disk partition, the device
> recorded in /proc/self/mounts will be /dev/root instead of the true device.
How does this /dev/root situation occur? My fedora VMs
show the real root device and not /dev/root in /proc/self/mounts,
so it's not clear to me why /dev/root is being reported here?
This smells of a custom boot sequence that is mounting the root
filesystem on a temporary initramfs /dev/root node (which then gets
removed once the initramfs is done) rather than using pivot_root to
move the real root fs into place once the real device nodes have
been initialised and the root fs mounted using them...
> This can lead to the failure of executing commands such as xfs_growfs/xfs_info.
>
> $ cat /proc/self/mounts
> /dev/root / xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
> devtmpfs /dev devtmpfs rw,seclabel,relatime,size=4065432k,nr_inodes=1016358,mode=755 0 0
> ...
>
> $ mount
> /dev/sda3 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
> devtmpfs on /dev type devtmpfs (rw,relatime,seclabel,size=4065432k,nr_inodes=1016358,mode=755)
> ...
>
> $ xfs_growfs /
> xfs_growfs: / is not a mounted XFS filesystem
>
> $ xfs_growfs /dev/sda3
> xfs_growfs: /dev/sda3 is not a mounted XFS filesystem
>
> $ xfs_info /
> /: cannot find mount point.#
>
> So, if the root device is found to be /dev/root, we need to obtain the
> corresponding real device first.
IMO, having a bogus device in /proc/self/mounts output is the
problem that needs to be fixed here. Working around a broken
/dev/root device in every userspace utility that reads
/proc/self/mounts does not feel like the right way to address this
problem.
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-09-10 0:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 11:29 [PATCH] libfrog: obtain the actual available device when the root device is /dev/root Wu Guanghao
2025-09-10 0:06 ` Dave Chinner [this message]
2025-09-10 1:42 ` Wu Guanghao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMDA7wJ5pO91Fewx@dread.disaster.area \
--to=david@fromorbit.com \
--cc=aalbersh@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=wuguanghao3@huawei.com \
--cc=yangyun50@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.