Re: RAID mount fails after upgrading to kernel 6.2.0

[Eric Levy <contact@ericlevy.name>]

On Thu, Jul 20 2023 at 10:26:57 AM +0800, Anand Jain 
<anand.jain@oracle.com> wrote:
> On 20/07/2023 09:13, Eric Levy wrote:
>> I recently performed a routine update on a Linux Mint system, 
>> version \x7f21.2 (Victoria). The update moved the kernel from 5.19.0 to 
>> 6.2.0. The \x7fsystem includes a non-root mount that is Btrfs with 
>> RAID, which no \x7flonger mounts. Error reporting is rather limited and 
>> opaque.
>> 
>> I am assuming the file system is healthy from the standpoint of the 
>> old \x7fkernel, but I may need help understanding how to make it viable 
>> for the \x7fnew one.
>> 
>> Mounting from the command line prints the following:
>> 
>> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdg, 
>> \x7fmissing codepage or helper program, or other error.
>> 
>> The following is extracted from the boot sequence recorded in the 
>> kernel \x7fring:
>> 
>> kernel: BTRFS error: device /dev/sdd belongs to fsid 
>> \x7fc6f83d24-1ac3-4417-bdd9-6249c899604d, and the fs is already mounted
>> kernel: BTRFS error: device /dev/sdf belongs to fsid 
>> \x7fc6f83d24-1ac3-4417-bdd9-6249c899604d, and the fs is already mounted
>> kernel: BTRFS info (device sde): using crc32c (crc32c-intel) 
>> checksum \x7falgorithm
>> kernel: BTRFS info (device sde): turning on async discard
>> kernel: BTRFS info (device sde): disk space caching is enabled
>> kernel: BTRFS error (device sde): devid 7 uuid 
>> \x7f2f62547b-067f-433c-bec1-b90e0c8cb75e is missing
>> kernel: BTRFS error (device sde): failed to read the system array: -2
>> kernel: BTRFS error (device sde): open_ctree failed
>> mount[969]: mount: /mnt: wrong fs type, bad option, bad superblock 
>> on \x7f/dev/sde, missing codepage or helper program, or other error.
>> systemd[1]: mnt.mount: Mount process exited, code=exited, 
>> status=32/n/a
> 
> 
> Looks like the fsid is already mounted. Could you please help check?
> 
>     cat /proc/self/mounts | grep btrfs
> 
> You could try a fresh scan and mount.
> 
>     umount  ..
>     btrfs device scan
>     mount ...
> 
> If this doesn't help. Can you share the output of:
> 
>     btrfs filesystem dump-super /dev/sd[a-g]  <-- basically all 
> devices
> 
> Thanks.


The unmount command followed by rescan does enable a successful mount, 
but the suggestion that the volume was mounted already had not been 
validated by the dump of the mount table. Based on the mount table, the 
volume appeared as unmounted even before the command.

Do you have any suggestions for how to resolve why the volume would be 
registered as having been mounted?