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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox