commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Alex Romosan]

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.  The linux disk is the only disk on the system. Since
version 7.3-rc1 i haven't been able to to a grub-update, instead i get
this error:

/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

7.2 is fine. a git-bisect identified commit
108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
reverting this commit from 7.3-rc2 allowed me to run grub-update
again.

this is not the first time i reported grub-update being broken on
btrfs. i reported exactly the same problem on jan 8, 2024
(https://lkml.iu.edu/hypermail/linux/kernel/2401.1/00596.html). maybe
the discussion that followed would help come up with a fix that will
make everybody happy.

thank you.

--alex--

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Hanabishi]

> Running my own compiled kernel without initramfs

> a git-bisect identified commit
> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
Looks like another consequence of the problem described in
https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[David Sterba]

On Tue, Sep 08, 2026 at 11:59:43PM +0200, 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.  The linux disk is the only disk on the system. Since
> version 7.3-rc1 i haven't been able to to a grub-update, instead i get
> this error:
> 
> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
> 
> 7.2 is fine. a git-bisect identified commit
> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
> reverting this commit from 7.3-rc2 allowed me to run grub-update
> again.
> 
> this is not the first time i reported grub-update being broken on
> btrfs. i reported exactly the same problem on jan 8, 2024
> (https://lkml.iu.edu/hypermail/linux/kernel/2401.1/00596.html). maybe
> the discussion that followed would help come up with a fix that will
> make everybody happy.

I remember debugging that one, https://bugzilla.kernel.org/show_bug.cgi?id=218353
Reverting 108cc8733989 ("btrfs: fix a lockdep caused by path resolution
during device scan") would bring back the lockdep warning and there is a
locking problem.

The commit says it's fixing 2e8b6bc0ab41 ("btrfs: avoid unnecessary
device path update for the same device"), the difference is in lines

(https://bugzilla.suse.com/show_bug.cgi?id=1230641)

-       } else if (!device->name || strcmp(device->name->str, path)) {
+	} else if (!device->name || !is_same_device(device, path)) {

Which gets changed to (by 108cc8733989):

-       } else if (!device->name || !is_same_device(device, path)) {
+       } else if (!device->name || device->devt != path_devt) {

Each change is reaction to a bug, I don't see a clear fix which will
make it work in all cases.

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Qu Wenruo]

在 2026/9/9 09:55, David Sterba 写道:
> On Tue, Sep 08, 2026 at 11:59:43PM +0200, 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.  The linux disk is the only disk on the system. Since
>> version 7.3-rc1 i haven't been able to to a grub-update, instead i get
>> this error:
>>
>> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
>>
>> 7.2 is fine. a git-bisect identified commit
>> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
>> reverting this commit from 7.3-rc2 allowed me to run grub-update
>> again.
>>
>> this is not the first time i reported grub-update being broken on
>> btrfs. i reported exactly the same problem on jan 8, 2024
>> (https://lkml.iu.edu/hypermail/linux/kernel/2401.1/00596.html). maybe
>> the discussion that followed would help come up with a fix that will
>> make everybody happy.
> 
> I remember debugging that one, https://bugzilla.kernel.org/show_bug.cgi?id=218353
> Reverting 108cc8733989 ("btrfs: fix a lockdep caused by path resolution
> during device scan") would bring back the lockdep warning and there is a
> locking problem.
> 
> The commit says it's fixing 2e8b6bc0ab41 ("btrfs: avoid unnecessary
> device path update for the same device"), the difference is in lines
> 
> (https://bugzilla.suse.com/show_bug.cgi?id=1230641)
> 
> -       } else if (!device->name || strcmp(device->name->str, path)) {
> +	} else if (!device->name || !is_same_device(device, path)) {
> 
> Which gets changed to (by 108cc8733989):
> 
> -       } else if (!device->name || !is_same_device(device, path)) {
> +       } else if (!device->name || device->devt != path_devt) {
> 
> Each change is reaction to a bug, I don't see a clear fix which will
> make it work in all cases.

And I want to add that, the previous path based comparison is also 
problematic for namespaces/weird block device names.

Although not common, it's definitely possible to map weird block file 
name into a namespace.

Thus the path based comparison is not reliable in the first place, no to 
mention the later lockdep problems.

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Hanabishi]

Hello.

May I ask why you guys keep ignoring me completely?
This is clearly a regression for userspace (see my previous reports).
If your answer is "won't fix", state it explicitly please.

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Qu Wenruo]

在 2026/9/9 23:48, Hanabishi 写道:
> Hello.
> 
> May I ask why you guys keep ignoring me completely?

If you think we have time to reply every report, then just check how 
many syzbot reports are not addressed.

> This is clearly a regression for userspace (see my previous reports).

Unfortunately it's not.

The problem is there no matter if you have that patch.

There are a lot of ways to make btrfs to report a weird device path even 
before that commit.
> If your answer is "won't fix", state it explicitly please.

Won't fix.

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Hanabishi]

I think human reporters deserve more attention than bots. But anyway, thanks for responding.

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Qu Wenruo]

在 2026/9/10 09:05, Hanabishi 写道:
> I think human reporters deserve more attention than bots. But anyway, 
> thanks for responding.

BTW, I may consider a different flag/cmd for btrfs device scan ioctl.

So that one can force a device rename, and I can finally put all the 
responsibility to the end user.

But that will not be landed anytime soon.

Meanwhile I would suggest just to use a initramfs to workaround it, so 
that btrfs can be mounted with proper device name (initialized by 
initramfs).

Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Thorsten Leemhuis]

On 9/9/26 03:13, Qu Wenruo wrote:
> 在 2026/9/9 09:55, David Sterba 写道:
>> On Tue, Sep 08, 2026 at 11:59:43PM +0200, Alex Romosan wrote:
>>>
>>> [...] Since version 7.3-rc1 i haven't been able to to a grub-update, 
>>> instead i get this error:
>>>
>>> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev
>>> mounted?).
>>>
>>> 7.2 is fine. a git-bisect identified commit
>>> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
>>> reverting this commit from 7.3-rc2 allowed me to run grub-update
>>> again.
>>>
>>> this is not the first time i reported grub-update being broken on
>>> btrfs. i reported exactly the same problem on jan 8, 2024
>>> (https://lkml.iu.edu/hypermail/linux/kernel/2401.1/00596.html). maybe
>>> the discussion that followed would help come up with a fix that will
>>> make everybody happy.
>>
>> I remember debugging that one, https://bugzilla.kernel.org/
>> show_bug.cgi?id=218353
>> Reverting 108cc8733989 ("btrfs: fix a lockdep caused by path resolution
>> during device scan") would bring back the lockdep warning and there is a
>> locking problem.
>>
>> The commit says it's fixing 2e8b6bc0ab41 ("btrfs: avoid unnecessary
>> device path update for the same device"), the difference is in lines
>>
>> (https://bugzilla.suse.com/show_bug.cgi?id=1230641)
>>
>> -       } else if (!device->name || strcmp(device->name->str, path)) {
>> +    } else if (!device->name || !is_same_device(device, path)) {
>>
>> Which gets changed to (by 108cc8733989):
>>
>> -       } else if (!device->name || !is_same_device(device, path)) {
>> +       } else if (!device->name || device->devt != path_devt) {
>>
>> Each change is reaction to a bug, I don't see a clear fix which will
>> make it work in all cases.
> 
> And I want to add that, the previous path based comparison is also
> problematic for namespaces/weird block device names.
> 
> Although not common, it's definitely possible to map weird block file
> name into a namespace.
> 
> Thus the path based comparison is not reliable in the first place, no to
> mention the later lockdep problems.

Well, but our #1 is "no regressions". And the recent change while fixing
bugs clearly causes one, as Alex's report is afaics at least the third
about it; the two earlier ones can be found here:

https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/
https://lore.kernel.org/linux-btrfs/018a9738-1d4a-43a0-9352-a56d1e541364@gmail.com/
Plus a repost of the latter here:
https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/

Exceptions to our #1 rule are rare. They, for example, are made when we
had to fix a vulnerability and tried hard to do so without breaking
something but in the end had to bite the bullet. Is this such a case?

Because if not, it looks more like a situation where Linus would prefer
to live with known problems, as earlier statements from him show:
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-back-and-forth

But it's easy to misunderstand things from my outside position, which is
why I'm asking.

Ciao, Thorsten