Hello, title is only a guess about the possible reason for this problem. Example session showing the problem: hadrien@gentoo-zen5900x> lsblk -o NAME,MODEL,PARTLABEL,FSTYPE,SIZE,MOUNTPOINT NAME MODEL PARTLABEL FSTYPE SIZE MOUNTPOINT sda Samsung SSD 840 PRO Series 476.9G sdb TOSHIBA MG05ACA800E 7.3T └─sdb1 LVM2_member 7.3T └─vg0-lv0 xfs 14.6T /home/hadrien/Data sdc TOSHIBA MG05ACA800E 7.3T └─sdc1 LVM2_member 7.3T └─vg0-lv0 xfs 14.6T /home/hadrien/Data sr0 HL-DT-ST BDDVDRW CH12NS30 1024M nvme0n1 KINGSTON SKC2500M8250G 232.9G ├─nvme0n1p1 grub 2M ├─nvme0n1p2 boot ext2 256M /boot └─nvme0n1p3 root xfs 220G / hadrien@gentoo-zen5900x> xfs_info / /: cannot find mount point.% [1] hadrien@gentoo-zen5900x> xfs_info /dev/nvme0n1p3 /: cannot find mount point.% [1] hadrien@gentoo-zen5900x> xfs_info ~/Data meta-data=/dev/mapper/vg0-lv0 isize=512 agcount=15, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=0 inobtcount=0 nrext64=0 data = bsize=4096 blocks=3907010560, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 hadrien@gentoo-zen5900x> xfs_info /dev/vg0/lv0 meta-data=/dev/mapper/vg0-lv0 isize=512 agcount=15, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=0 inobtcount=0 nrext64=0 data = bsize=4096 blocks=3907010560, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 hadrien@gentoo-zen5900x> dmesg | grep nvme0n1p3 [ 4.384082] XFS (nvme0n1p3): Mounting V5 Filesystem [ 4.391406] XFS (nvme0n1p3): Ending clean mount I'm on a 6.1.50 kernel (with XFS support, of course), right now.
Could you report this upstream please to the linux-xfs mailing list?
Okay, so I did some debugging by myself (with the source code of xfsprogs) and discovered that it uses setmntent on /proc/self/mounts to find mountpoints. Everything fine until I look at said file: $ grep xfs /proc/self/mounts /dev/root / xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0 /dev/mapper/vg0-lv0 /home/hadrien/Data xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0 The device mounted on / is a nonexistent /dev/root; adding a /dev/root -> /dev/nvme0n1p3 symlink makes it work. Not an xfsprogs problem, it seems. Some digging around revealed this Gentoo patch https://lkml.org/lkml/2013/1/31/574 which I thought would be related to my setup using GRUB_DISABLE_LINUX_PARTUUID=false (so that root=PARTUUID is used in the generated grub.cfg), but looking at the gentoo patches and my local source of =sys-kernel/gentoo-sources-6.6.29 shows it's not there (though it seems the kernel does some of what that patch does). Any further idea why /dev/root isn't there? Before I debug the kernel myself to see why...
https://forums.gentoo.org/viewtopic-t-1122224-start-0.html may be related.
Oh my. This is coming back to me now. I remember floppym and I discussing it with someone in #gentoo a while back (possibly you!), and I _think_ we concluded that xfsprogs should really use libblkid.
It was I, most probably. I'm still affected. It is very annoying.
From my point of view, xfsprogs isn't in the wrong here, it's whatever that causes /proc/self/mounts and devtmpfs to be desynchronized. I read https://bugs.gentoo.org/show_bug.cgi?id=175243 and still don't know how this happens. I also see the commented rc_dev_root_symlink="YES" line in /etc/conf.d/udev-trigger but don't end up any wiser.
(In reply to Hadrien Lacour from comment #6) > From my point of view, xfsprogs isn't in the wrong here, it's whatever that > causes /proc/self/mounts and devtmpfs to be desynchronized. I don't quite understand this deficiency of the proc interface either. > > I read https://bugs.gentoo.org/show_bug.cgi?id=175243 and still don't know > how this happens. I also see the commented rc_dev_root_symlink="YES" line in > /etc/conf.d/udev-trigger but don't end up any wiser. I would add that Gentoo has previously been rebuked for doing this sort of thing. https://lists.freedesktop.org/archives/systemd-devel/2014-July/020997.html https://lists.freedesktop.org/archives/systemd-devel/2014-July/020996.html
/dev/root showing up in /proc but not devtmpfs is a kernel issue really. As I recall, it only happens when you boot without using an initrd. The code in the kernel responsible for mounting the root filesystem uses a fake device node (/dev/root).
That makes for a compelling argument to address it in xfsprogs, in my view. That is, even in the event that the kernel behaviour be addressed, there are situations in which which it is not always possible to be running the latest kernel, or even to be able to reboot in a timely fashion for a minor update.
Please work with the kernel and/or xfsprogs upstream to resolve this.
(In reply to Sam James from comment #4) > Oh my. This is coming back to me now. I remember floppym and I discussing it > with someone in #gentoo a while back (possibly you!), and I _think_ we > concluded that xfsprogs should really use libblkid. The mount table parsing code in libmount has a hack to convert /dev/root into a real device node when possible. That would probably be the best userspace workaround.
