Add Cc to debian user list. On 2018/10/24 上午3:21, Tony Prokott wrote: > The trouble is yet unresolved, symptoms are as they were, but I've diagnosed a step further. Maybe you can help me advance the diagnosis or better pose my question among debian experts, related to adjusting the building of initrd. > > ---- On Thu, 18 Oct 2018 00:08:08 -0700 Qu Wenruo <quwenruo.btrfs@gmx.com> wrote ---- > > > > Still looks like a initramfs problem [rather] than btrfs problem. > Yes, but linux-btrfs list still knows better than I how best to proceed, mainly how to distill the trouble description using proper terms, also lending broader understanding of what named modules serve what device activate&cfg or storage-access purpose. Personally speaking, distro guys are much better at such problem. In fact I'm not even a debian guy, and for my distro, it's super easy to setup initramfs to boot from USB device. > > > > > In the busybox environment, have you tried listing /dev to see if that external device is found? > External usb attached drives are definitely not found by a newly launched kernel, and particulars of why are still not self evident. Boot loader grub2 all along still has no trouble accessing -- presumably it's not able to leverage raid1 redundancy in btrfs but does have access to the ext mirror device and takes notice in passing of matching UUID's. So missing drivers. Without the driver, btrfs scan doesn't make sense at all. It needs not only usb drivers but also some other drivers. Normally distro should provide such tools to do runtime probe and generate all needed drivers and their dependency, or manually setup needed drivers. BTW, have you tried something like fallback initramfs? Generally speaking such fallback initramfs should have more modules thus higher chance to detect external usb drivers. > > > By default, btrfs must see *all* devices to mount RAID1/10/5/6/0. Unless you're using "degraded" mount option. > > You could argue it's a bad decision, but still you have the choice. > Yes did manage to mount it degraded, just to see that content demirrored is also unclobbered, however can't finish the job by such means; hopefully in the process no metadata or other junk was written unintentionally (forgot to mount readonly - degraded) > > The task now seems to be finishing resolving which modules can bring in the rest of the critical infrastructure to allow access to the drives that had been no customized bother to bring online, prior to rootfs raid1 conversion. A recently found item of great interest is module "autofs4" which has userland friends such as systemd; it's present in cindy(LMDE3) which boots fine in spite of deriving from stretch, and was absent in stretch & buster which no longer boot. > > > > When manually trying to mount in busybox, it gives a similar error about missing the same external device, by its UUID_SUB > > Then it's still something wrong about the initramfs. From your description, it looks pretty like the lack of external disk driver is the root cause. > Agreed *something* missing in initrd and-or module deployment is the cause of failing access to ext usb3 drive enclosure devices, but am still tracking down which other missing blobs may be of concern; since busybox won't allow "lsblk" "lshw" or "lsusb" -- only "blkid" or "ls /dev" work to detect devices -- my confidence and expediency in tracking is reduced; haven't yet happened upon the debian feature that lets more nonkernel programs and libraries--not just modules-- be built into initrd. At least for my distro, it's pretty easy to inject external commands into initramfs. (Archlinux provides "add_binary" function in mkinitcpio, which will not only add the binary but also its dependency) So it's really dependent on the distro. Thanks, Qu > > As an aside probably not germane, the grub.cfg "linux" line to load the kernel in some cases has "ro" readonly option and others not; what's the difference signify? How to make informed choice whether to use ro? Why mount a real disk rootfs without write access, before corruption's detected? Would that not potentially cripple some vital features such as logging? > > So far it's clear that uas, usb_storage, & autofs4 may be built into initrd and then load ok, but they're not enough to restore normal systemd launch. Setting "MODULES=dep" in /etc/initramfs-tools/conf.d/driver-policy seems not smart enough for building in all necessary objects. Ideas welcome. > > regards- > TP > >
Attachment:
signature.asc
Description: OpenPGP digital signature