When I attempt to mount a block device, I get the error: --------------------------------- root@barley:~/tempserver-check# date; mount /dev/stretch-vg/boot stretch_boot Mon 13 May 2019 11:42:15 PM PDT mount: /root/tempserver-check/stretch_boot: can't read superblock on /dev/mapper/stretch--vg-boot. --------------------------------------------- Same error if I add -t ext2, 3, or 4.
But when I check the block device, there don't seem to be any complaints: ================================ root@barley:~/tempserver-check# date; e2fsck -n /dev/stretch-vg/boot Mon 13 May 2019 11:45:49 PM PDT e2fsck 1.44.5 (15-Dec-2018) /dev/stretch-vg/boot: clean, 345/97536 files, 116077/389120 blocks ============================== See below for more info from dumpe2fs. I suspect this is some problem with my use of qemu-nbd. The stack is pretty complex: /dev/stretch-vg/boot is a logical volume based on a "physical volume" which is a partition of a virtual disk served up by qemu-nbd which is based on a virtual disk file, stretch vdi on a trivial RAID array (RAID1 with only one member) whose only element is a partition That partition was created by ddrescue from a disk that was failing; all but one 4k sector were recovered. FWIW this particular virtual machine seemed to be operating OK even after the disk error. File systems and devices were opened read only where possible. My real target is some logical volumes that were encrypted, and so one more layer. But I figure if I can't handle an unencrypted partition my chances of reading an encrypted one are slim. Key commands, working from the bottom up: mdadm -v --assemble --readonly /dev/md/media5 /dev/sdf2 Mon 13 May 2019 08:12:09 PM PDT mdadm: looking for devices for /dev/md/media5 mdadm: /dev/sdf2 is identified as a member of /dev/md/media5, slot 0. mdadm: added /dev/sdf2 to /dev/md/media5 as 0 mdadm: /dev/md/media5 has been started with 1 drive.
