Received-SPF: pass (google.com: domain of linux-kernel+bounces-51843-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAKLYgeJ1tUuqLcsquwuFqjDXPSJpEiokrWK2gisPKDZLs8Y2TQ@mail.gmail.com>
 <39e3a4fe-d456-4de4-b481-51aabfa02b8d@leemhuis.info> <20240111155056.GG31555@twin.jikos.cz>
 <20240111170644.GK31555@twin.jikos.cz> <f45e5b7c-4354-87d3-c7f1-d8dd5f4d2abd@oracle.com>
 <7d3cee75-ee74-4348-947a-7e4bce5484b2@leemhuis.info> <CAKLYgeLhcE5+Td9eGKAi0xeXSsom381RxuJgKiQ0+oHDNS_DJA@mail.gmail.com>
In-Reply-To: <CAKLYgeLhcE5+Td9eGKAi0xeXSsom381RxuJgKiQ0+oHDNS_DJA@mail.gmail.com>
From: Alex Romosan <aromosan@gmail.com>
Date: Sun, 4 Feb 2024 19:29:29 +0100
Message-ID: <CAKLYgeKCuDmnuGHuQYPdZZA1_H3s9_9oh+vT_FMpFZqxKSvjzw@mail.gmail.com>
Subject: Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks update-grub
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Anand Jain <anand.jain@oracle.com>, CHECK_1234543212345@protonmail.com, 
	brauner@kernel.org, linux-btrfs <linux-btrfs@vger.kernel.org>, 
	linux-kernel@vger.kernel.org, Chris Mason <clm@fb.com>, 
	Josef Bacik <josef@toxicpanda.com>, David Sterba <dsterba@suse.com>, dsterba@suse.cz
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sorry about the html post (in case somebody actually got it). as i was
saying, just for the record it's still not fixed in 6.8-rc3. thanks.


On Sun, Feb 4, 2024 at 7:27=E2=80=AFPM Alex Romosan <aromosan@gmail.com> wr=
ote:
>
> just for the record it's still not fixed in 6.8-rc3 (obviously, since i'v=
e been looking at the btrfs patches being applied).
>
> On Thu, Feb 1, 2024 at 11:25=E2=80=AFAM Linux regression tracking (Thorst=
en Leemhuis) <regressions@leemhuis.info> wrote:
>>
>> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
>> for once, to make this easily accessible to everyone.
>>
>> Anand, what's the status wrt to below issue (which afaics seems to
>> affect quite a few people)? Things look stalled, but I might be missing
>> something, that's why I ask for a quick update.
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>>
>> #regzbot poke
>>
>> On 12.01.24 00:24, Anand Jain 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:
>> >>>>
>> >>>> On 08.01.24 15:11, Alex Romosan wrote:
>> >>>>>
>> >>>>> Running my own compiled kernel without initramfs on a lenovo think=
pad
>> >>>>> 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?) s=
olid
>> >>>>> state drive
>> >>>>>
>> >>>>> 6.6 was the last version that worked.
>> >>>>>
>> >>>>> Today I did a git-bisect between these two versions which identifi=
ed
>> >>>>> commit bc27d6f0aa0e4de184b617aceeaf25818cc646de btrfs: scan but do=
n't
>> >>>>> register device on single device filesystem as the culprit. revert=
ing
>> >>>>> 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 o=
ther
>> >>>>> kernel options. any help/fixes would be appreciated.
>> >>>>
>> >>>> Thanks for the report. To be sure the issue doesn't fall through th=
e
>> >>>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regres=
sion
>> >>>> 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=3D218353 .
>> >>
>> >> 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 d=
oes
>> >> 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=3Dv2,subvolid=3D5,subvol=3D/
>> >
>> > 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
>> >
>> >