mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Alex Romosan <aromosan@gmail.com>
Cc: CHECK_1234543212345@protonmail.com, brauner@kernel.org,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Linux kernel regressions list <regressions@lists.linux.dev>,
	linux-kernel@vger.kernel.org, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	dsterba@suse.cz
Subject: Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks update-grub
Date: Mon, 22 Jan 2024 09:35:22 +0800	[thread overview]
Message-ID: <7d28b18c-3477-83ec-ef89-cdaf6ca7ebee@oracle.com> (raw)
In-Reply-To: <CAKLYge+x9kxLBaJGyk_gTMK2kQ=+Lhg00jgXe=P=jmBUq=cmfA@mail.gmail.com>



On 22/01/2024 08:07, Alex Romosan wrote:
> update-grub still doesn't work 6.8-rc1
> 
> so i did:
> 
> # cat /proc/self/mountinfo | grep btrfs
> 21 1 0:19 / / rw,relatime shared:1 - btrfs /dev/root
> rw,ssd,discard=async,space_cache,subvolid=5,subvol=/
> 

The latest Btrfs kernel expect one MAJ:MIN for a block device,
but multiple nodes here point to the same root device:

   /dev/root MAJ1:MIN1 \___ root-device
   /dev/sda1 MAJ2:MIN2 /

To fix, I'm exploring communication through block-device nodes
with a temporary signature tag on the superblock for identification.
Community feedback is pending, and potentially synchronization issues
maybe a concer.

> the difference from your test case is that it doesn't reference
> the disk device but /dev/root which on my system doesn't exist. could this
> be the problem?
> 

How are you reproducing this? I tried with Oracle Linux (OL), Fedora,
and Arch Linux, but they didn't show /dev/root as the root device.

Thanks, Anand

> --alex--
> 
> 
> On Fri, Jan 12, 2024 at 12:24 AM Anand Jain <anand.jain@oracle.com> 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:
>>>>> [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

  reply	other threads:[~2024-01-22  1:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 14:11 Alex Romosan
2024-01-11 11:45 ` Thorsten Leemhuis
2024-01-11 15:50   ` David Sterba
2024-01-11 17:06     ` David Sterba
2024-01-11 23:24       ` Anand Jain
2024-01-22  0:07         ` Alex Romosan
2024-01-22  1:35           ` Anand Jain [this message]
2024-01-22  1:46             ` Alex Romosan
2024-02-01 10:25         ` Linux regression tracking (Thorsten Leemhuis)
2024-02-03 22:03           ` David Sterba
     [not found]           ` <CAKLYgeLhcE5+Td9eGKAi0xeXSsom381RxuJgKiQ0+oHDNS_DJA@mail.gmail.com>
2024-02-04 18:29             ` Alex Romosan
2024-02-05 11:26               ` David Sterba
2024-02-05 12:38                 ` Alex Romosan

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=7d28b18c-3477-83ec-ef89-cdaf6ca7ebee@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=CHECK_1234543212345@protonmail.com \
    --cc=aromosan@gmail.com \
    --cc=brauner@kernel.org \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®