Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks update-grub

[Anand Jain <anand.jain@oracle.com>]

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