Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks update-grub

[Anand Jain]

On 22/01/2024 08:07, Alex Romosan wrote:
> update-grub still doesn't work 6.8-rc1
>
> so i did:
>
> # cat /proc/self/mountinfo | grep btrfs
> 21 1 0:19 / / rw,relatime shared:1 - btrfs /dev/root
> rw,ssd,discard=async,space_cache,subvolid=5,subvol=/

The latest Btrfs kernel expect one MAJ:MIN for a block device,
but multiple nodes here point to the same root device:

  /dev/root MAJ1:MIN1 \___ root-device
  /dev/sda1 MAJ2:MIN2 /

To fix, I'm exploring communication through block-device nodes
with a temporary signature tag on the superblock for identification.
Community feedback is pending, and potentially synchronization issues
maybe a concer.

> the difference from your test case is that it doesn't reference
> the disk device but /dev/root which on my system doesn't exist. could this
> be the problem?

How are you reproducing this? I tried with Oracle Linux (OL), Fedora,
and Arch Linux, but they didn't show /dev/root as the root device.

Thanks, Anand

> --alex--
>
>
> On Fri, Jan 12, 2024 at 12:24 AM Anand Jain <anand.jain@xxxxxxxxxx> wrote:
> > On 11/01/2024 22:36, David Sterba wrote:
> > > On Thu, Jan 11, 2024 at 04:50:56PM +0100, David Sterba wrote:
> > > > On Thu, Jan 11, 2024 at 12:45:50PM +0100, Thorsten Leemhuis wrote:
> > > > > [Adding Anand Jain, the author of the culprit to the list of recipients;
> > > > > furthermore CCing the the Btrfs maintainers and the btrfs list; also
> > > > > CCing regression list, as it should be in the loop for regressions:
> > > > > https://docs.kernel.org/admin-guide/reporting-regressions.html]
> > > > >
> > > > > On 08.01.24 15:11, Alex Romosan wrote:
> > > > > > Please Cc me as I am not subscribed to the list.
> > > > > >
> > > > > > Running my own compiled kernel without initramfs on a lenovo thinkpad
> > > > > > x1 carbon gen 7.
> > > > > >
> > > > > > Since version 6.7-rc1 i haven't been able to to a grub-update,
> > > > > >
> > > > > > instead i get this error:
> > > > > >
> > > > > > grub-probe: error: cannot find a device for / (is /dev mounted?) solid
> > > > > > state drive
> > > > > >
> > > > > > 6.6 was the last version that worked.
> > > > > >
> > > > > > Today I did a git-bisect between these two versions which identified
> > > > > > commit bc27d6f0aa0e4de184b617aceeaf25818cc646de btrfs: scan but don't
> > > > > > register device on single device filesystem as the culprit. reverting
> > > > > > this commit from 6.7 final allowed me to run update-grub again.
> > > > > >
> > > > > > not sure if this is the intended behavior or if i'm missing some other
> > > > > > kernel options. any help/fixes would be appreciated.
> > > > > >
> > > > > > thank you.
> > > > >
> > > > > Thanks for the report. To be sure the issue doesn't fall through the
> > > > > cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> > > > > tracking bot:
> > > > >
> > > > > #regzbot ^introduced bc27d6f0aa0e4de184b617aceeaf25818cc646de
> > > > > #regzbot title btrfs: update-grub broken (cannot find a device for / (is
> > > > > /dev mounted?))
> > > > > #regzbot ignore-activity
> > > >
> > > > The bug is also tracked at https://bugzilla.kernel.org/show_bug.cgi?id=218353 .
> > >
> > > About the fix: we can't simply revert the patch because the temp_fsid
> > > depends on that. A workaround could be to check if the device path is
> > > "/dev/root" and still register the device. But I'm not sure if this does
> > > not break the use case that Steamdeck needs, as it's for the root
> > > partition.
> >
> >
> > Thank you for the report.
> >
> > The issue seems more complex than a simple scenario, as the following
> > test-case works well:
> >
> >     $ mount /dev/sdb1 /btrfs
> >     $ cat /proc/self/mountinfo | grep btrfs
> > 345 63 0:34 / /btrfs rw,relatime shared:179 - btrfs /dev/sdb1
> > rw,space_cache=v2,subvolid=5,subvol=/
> >
> > However, the relevant part of the commit
> > bc27d6f0aa0e4de184b617aceeaf25818cc646de that may be failing could
> > be in identifying a device, whether it is the same or different
> > For this, we use:
> >
> >        lookup_bdev(path, &path_devt);
> >
> > and match with the devt(MAJ:MIN) saved in the btrfs_device;
> > would this work during initrd? I need to dig more. Trying
> > to figure out how can I reproduce this.
> >
> > Thanks, Anand