Summary: | sys-fs/xfsprogs-6.4.0: xfs_info doesn't necessarily work in the absence of /dev/root | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hadrien Lacour <hadrien.lacour> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | floppym, hadrien.lacour, kernel, kfm, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=931236 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 438380 |
Description
Hadrien Lacour
2023-09-01 14:14:39 UTC
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. |