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] > >
signature.asc
Description: OpenPGP digital signature
