From: Wu Guanghao <wuguanghao3@huawei.com>
To: Dave Chinner <david@fromorbit.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 09:42:37 +0800 [thread overview]
Message-ID: <90dfbc39-c0f2-72b5-d0e2-ba1d4bf80ff8@huawei.com> (raw)
In-Reply-To: <aMDA7wJ5pO91Fewx@dread.disaster.area>
在 2025/9/10 8:06, Dave Chinner 写道:
> 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?
>
I am using a Fedora 42 Server qcow2 image, and then I convert the image to partitions
and LVM devices using qemu-nbd. Afterwards, I pass through the partition devices and
LVM devices using qemu.
$ lsblk
...
nbd0 43:0 0 10G 0 disk
├─nbd0p1 43:1 0 500M 0 part
├─nbd0p2 43:2 0 1000M 0 part
└─nbd0p3 43:3 0 8.5G 0 part
└─systemVG-LVRoot 253:7 0 8.5G 0 lvm
qemu start scripts:
qemu-system-aarch64 \
... \
-drive id=root,if=virtio,media=disk,format=raw,file=/dev/systemVG/LVRoot \
-drive id=boot,if=virtio,media=disk,format=raw,file=/dev/nbd0p2 \
-drive id=efi,if=virtio,media=disk,format=raw,file=/dev/nbd0p1 \
> 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.
>
I have reviewed the source code of the util-linux mount command and the e2fsprogs resize2fs command,
and both of these have logic for checking and handling /dev/root.
> -Dave.
prev parent reply other threads:[~2025-09-10 1:42 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
2025-09-10 1:42 ` Wu Guanghao [this message]
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=90dfbc39-c0f2-72b5-d0e2-ba1d4bf80ff8@huawei.com \
--to=wuguanghao3@huawei.com \
--cc=aalbersh@kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--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