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.
--alex--
[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
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
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
That page also explains what to do if mails like this annoy you.
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 .
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.
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
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 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?
--alex--
On Fri, Jan 12, 2024 at 12:24 AM Anand Jain <[email protected]> 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
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 <[email protected]> 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
On Mon, Jan 22, 2024 at 2:35 AM Anand Jain <[email protected]> wrote:
>
>
>
> 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.
i'm running debian on a lenovo x1. this is my /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p3 during installation
#UUID=695aa7ac-862a-4de3-ae59-c96f784600a0 / btrfs
defaults 0 0
PARTUUID=43094f42-5f54-4456-9d14-3c41e92326e1 / btrfs
defaults 0 0
# /boot/efi was on /dev/nvme0n1p1 during installation
#UUID=A4A3-9199 /boot/efi vfat umask=0077 0 1
PARTUUID=05e00aed-a6ad-4cdc-9a40-4b775dbf87a9 /boot/efi vfat
umask=0077 0 1
# swap was on /dev/nvme0n1p2 during installation
#UUID=6b9a36ed-14d8-458d-8575-c8d29dc80bdf none swap sw
0 0
PARTUUID=db40aeb2-88b4-46eb-970f-58a410bf272e none swap
sw 0 0
i'm running my own compiled kernel without initrd. the disk with the btrfs
filesystem is the only disk on that laptop. i'm just booting the kernel
(everything works fine there) but when i try to run update-grub i get:
# update-grub
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
--alex--
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 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.
>>>>
>>>> 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
>
>
On Thu, Feb 01, 2024 at 11:25:28AM +0100, Linux regression tracking (Thorsten Leemhuis) 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.
Yeah it's affecting people and not stalled but we ran out of ideas.
I'll present the latest fix that works for me (similar setup as the
reporter), though not everybody may like it:
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2360,6 +2360,7 @@ static int btrfs_unfreeze(struct super_block *sb)
static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
{
struct btrfs_fs_info *fs_info = btrfs_sb(root->d_sb);
+ char real[4096] = { "/dev/" };
/*
* There should be always a valid pointer in latest_dev, it may be stale
@@ -2367,7 +2368,8 @@ static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
* the end of RCU grace period.
*/
rcu_read_lock();
- seq_escape(m, btrfs_dev_name(fs_info->fs_devices->latest_dev), " \t\n\\");
+ scnprintf(real + 5, sizeof(real) - 5, "%pg", fs_info->fs_devices->latest_dev->bdev);
+ seq_puts(m, real);
rcu_read_unlock();
return 0;
---
The problem that was reported was a discrepancy in what show_devname
returned (/proc/self/mountinfo) and what eg. mount showed. Both resolve
the device name in a different way. The problem is that mountinfo relies
on what btrfs remembers as the device path that was passed during
scanning && at the mount time. Since then it's not updated due to
changes done in 6.7 for temp_fsid (single devices don't have any cached
representation of the device, so the new path is basically forgotten).
What the fix does: print the path of the same block device but not the
cached (possibly stale) value.
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 PM Alex Romosan <[email protected]> wrote:
>
> just for the record it's still not fixed in 6.8-rc3 (obviously, since i've been looking at the btrfs patches being applied).
>
> On Thu, Feb 1, 2024 at 11:25 AM Linux regression tracking (Thorsten Leemhuis) <[email protected]> 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 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.
>> >>>>
>> >>>> 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
>> >
>> >
On Sun, Feb 04, 2024 at 07:29:29PM +0100, Alex Romosan wrote:
> 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.
I've updated the bug with link to fix
https://github.com/kdave/btrfs-devel/commit/b80f3ec6592c69f88ebc74a4e16676af161e2759
but would like to ask for testing.
i can confirm that with this patch applied on top of 6.8-rc3 i can now
run update-grub. thank you. checked the kernel logs for btrfs related
messages and everything seems fine:
Btrfs loaded, zoned=no, fsverity=no
BTRFS: device fsid 695aa7ac-862a-4de3-ae59-c96f784600a0 devid 1
transid 1990924 /dev/root scanned by swapper/0 (1)
BTRFS info (device nvme0n1p3): first mount of filesystem
695aa7ac-862a-4de3-ae59-c96f784600a0
BTRFS info (device nvme0n1p3): using crc32c (crc32c-generic) checksum algorithm
BTRFS info (device nvme0n1p3): disk space caching is enabled
VFS: Mounted root (btrfs filesystem) readonly on device 0:19.
BTRFS info (device nvme0n1p3): the free space cache file
(604538667008) is invalid, skip it
BTRFS info: devid 1 device path /dev/root changed to /dev/nvme0n1p3
scanned by (udev-worker) (277)
BTRFS info (device nvme0n1p3): the free space cache file
(675405627392) is invalid, skip it
BTRFS info (device nvme0n1p3): the free space cache file
(696880463872) is invalid, skip it
BTRFS info (device nvme0n1p3): the free space cache file
(725871493120) is invalid, skip it
BTRFS info (device nvme0n1p3): the free space cache file
(799959678976) is invalid, skip it
BTRFS info (device nvme0n1p3): the free space cache file
(1658160414720) is invalid, skip it
not sure what's going on with the free space cache file, it wasn't
that long ago i mounted the disk with the clear_cache option after
which those messages disappeared but now it's back again...
--alex--
On Mon, Feb 5, 2024 at 12:26 PM David Sterba <[email protected]> wrote:
>
> On Sun, Feb 04, 2024 at 07:29:29PM +0100, Alex Romosan wrote:
> > 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.
>
> I've updated the bug with link to fix
>
> https://github.com/kdave/btrfs-devel/commit/b80f3ec6592c69f88ebc74a4e16676af161e2759
>
> but would like to ask for testing.