Re: Conversion to btrfs raid1 profile on added ext device renders some systems unable to boot into converted rootfs

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4874 bytes --]



On 2018/10/18 上午12:38, Tony Prokott wrote:
> Good day. My technical trouble seems to be beyond the scope of active helpers on debian's irc support channel. Reasonable supposition that it's quite particular to the development stage of btrfs infrastructure on 4.17.xxx backport kernels and userland tools available on debian 9.5 stretch as well as buster, the testing suite to be released in the next several months as 10.0 stable. 
> 
>  > / # uname -a; lsb_release -a
>  > Linux localhost 4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27) x86_64 GNU/Linux
>  > Distributor ID: LinuxMint
>  > Description: LMDE 3 Cindy
>  > Release: 3
>  > Codename: cindy
>  > 
>  > / # btrfs --version
>  > btrfs-progs v4.7.3
>  > 
>  > / # btrfs fi sh
>  > Label: 'sys'  uuid: [snip]
>  > Total devices 2 FS bytes used 24.07GiB
>  > devid    1 size 401.59GiB used 26.03GiB path /dev/sda2
>  > devid    2 size 401.76GiB used 26.03GiB path /dev/sdc1
>  > 
>  > / # btrfs fi df /
>  > Data, RAID1: total=24.00GiB, used=23.27GiB
>  > System, RAID1: total=32.00MiB, used=16.00KiB
>  > Metadata, RAID1: total=2.00GiB, used=820.00MiB
>  > GlobalReserve, single: total=69.17MiB, used=0.00B
>  > 
>  > / # btrfs su li -ta /
>  > ID	gen	top level	path
>  > --	---	---------	----
>  > 260	115103	5		<FS_TREE>/d9
>  > 261	115103	5		<FS_TREE>/d10
>  > 262	123876	5		<FS_TREE>/home
>  > 263	115148	261		<FS_TREE>/d10/@
>  > 264	115136	261		<FS_TREE>/d10/@home
>  > 443	123874	447		<FS_TREE>/md3/@
>  > 444	123876	447		<FS_TREE>/md3/@home
>  > 447	115103	5		<FS_TREE>/md3
>  > 451	115144	260		<FS_TREE>/d9/@
>  > 452	115136	260		<FS_TREE>/d9/@home
> 
> Providing no dmesg content so far, as it doesn't bear on the kind of difficulty in question. My system requires expert help now to restore bootability to 2 of its OS installations; it has a btrfs root file system in subvolumes for stretch, buster, and LMDE3(cindy) which derives directly from stretch and so has most core elements if not cfg defaults in common; even kernel versions are alike, besides buster. subvolid=262 is a  /home fs shared among  linux distros; 451, 263, and 443 are rootfs for stretch, buster and cindy respectively.
> 
> All 3 installations had been booting and running fine when data block group profile was "single" on an internal sata HDD /dev/sda2; then an external usb3 drive enclosure's sata HDD partition /dev/sdc1, also of size ~0.4TiB, was added and balanced as btrfs "raid1"; raid conversion did not damage subvolume content or filesystem integrity afaict, but rather rendered stretch and buster unbootable (more to follow), whereas cindy carried on without hiccup.
> 
> At first it seemed as though the initrd's might be missing a module or so, to allow access to external drives -- i.e. grub starts the unbootable kernel/initrd but drops to busybox prompt right away without starting external drives, referring to allegedly "missing" btrfs device's UUID_SUB.
> 
> But after chrooting to update-initramfs and cataloging resulting image content, usb_storage and uas were present under /lib/modules/xxx already, and failing systems still just busybox without a real rootfs rather than launch systemd; even tried kernel option "rootwait" which had no effect on access to ext storage; udev still seems not to have noticed the ext drives once busybox had control.

Still looks like a initramfs problem other than btrfs problem.

In the busybox environment, have you tried listing /dev to see if that
external device is found?

> 
> I could list all initrd modules present in cindy & absent for others, but need better knowledge than my reasonable guesses of what's required to make btrfs volume companion devices cooperate at boot time, as initrd transitions to steady state rootfs.

Since you have a busybox environment, have you checked if "btrfs"
command lives in the initramfs?

IIRC at least you need the following things/abilities to boot:

1) usb and sata drivers
   Means you could see both devices in the busybox environment under
   /dev

2) "Btrfs" command
   Mostly for scan

Then you could try the following commands under busybox environment:

# btrfs device scan
# mount <device> <some temporary mount point>

If it works, it may mean you're missing "btrfs device scan" during boot
so kernel can't see all RAID1 disks for btrfs and failed to boot.

Please refer to your distribution initramfs creation tool to see how to
add that scan. (Some distro has special hook for btrfs to handle such case).

Thanks,
Qu

> 
> What would be a more practical diagnostic? Could stretch & buster initrd's somehow be failing to do a btrfs device scan at the proper moment? Not so interested in giving up on btrfs software raid so early in the game.
> 
> thanks in advance-
> TP [not a list subscriber]
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]