All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Alex Romosan <aromosan@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem
Date: Wed, 9 Sep 2026 02:25:06 +0200	[thread overview]
Message-ID: <20260909002506.GF9053@twin.jikos.cz> (raw)
In-Reply-To: <CAKLYgeL7nrA4nXcewdv9Fqg_s=3GS=vmoypnEiZBKQ7rySZFuQ@mail.gmail.com>

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.

  parent reply	other threads:[~2026-09-09  0:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 21:59 commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem Alex Romosan
2026-09-08 22:22 ` Hanabishi
2026-09-09  0:25 ` David Sterba [this message]
2026-09-09  1:13   ` Qu Wenruo
2026-09-10 10:39     ` Thorsten Leemhuis
2026-09-09 14:18   ` Hanabishi
2026-09-09 21:58     ` Qu Wenruo
2026-09-09 23:35       ` Hanabishi
2026-09-10  0:02         ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260909002506.GF9053@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=aromosan@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.