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

[Alex Romosan]

i agree it's a regression. one question (and i am not very familiar
with the underlying principles), how do the other filesystems deal
with this? shouldn't the registering of devices be abstracted out
since i would assume every fs does it or is this something btrfs
specific?

On Fri, Sep 11, 2026 at 8:21 PM David Sterba <dsterba@xxxxxxx> wrote:
>
> On Thu, Sep 10, 2026 at 12:39:25PM +0200, Thorsten Leemhuis wrote:
> > 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@xxxxxxxxx/
> > https://lore.kernel.org/linux-btrfs/018a9738-1d4a-43a0-9352-a56d1e541364@xxxxxxxxx/
> > Plus a repost of the latter here:
> > https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@xxxxxxxxx/
>
> I'm going to treat this as a regression. And for the record Qu and me
> are in disagreement on that. My target is to make the systems boot again
> first, the fix may leave some problematic case (like mentioned, devices
> in namespaces), but that is probably a lesser problem.