On Fri, May 13, 2022 at 10:02 AM Ben Koenig <[email protected]> wrote:
> I might be channeling Captain Obvious here, but /dev/md0 is basically just > a block device. > I believe you are channeling a very different captain. > Sounds like you should identify the filesystem the same way you would for > a normal HDD partition. If this array was automounted then does it have an > entry in /etc/fstab? > /etc/fstab is on the inaccessible volume. the backup I have of it seems to be old or incomplete. or maybe mounting was handled by lvm for most of the volumes. I do, however, appear to have a backup of the contents of /etc/lvm, including lvm.conf, archive/, and backup/. this doesn't mean the current volume was definitely using lvm, but if it was, and maybe it was at some kind of offset, this could provide the info we need. now I will see if I can find any info on how to import a config file to lvm. > Does lsblk say anything useful? At some point it will need to be mounted > like any other partition. > > # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 465.3G 0 disk ââsdb1 8:17 0 476M 0 part â ââmd0 9:0 0 475.7M 0 raid1 /mnt ââsdb2 8:18 0 228.2G 0 part ââmd1 9:1 0 684.1G 0 raid6 sr0 11:0 1 1024M 0 rom sdc 8:32 0 931G 0 disk ââsdc1 8:33 0 476M 0 part â ââmd0 9:0 0 475.7M 0 raid1 /mnt ââsdc2 8:34 0 930.5G 0 part ââmd1 9:1 0 684.1G 0 raid6 sdd 8:48 0 465.3G 0 disk ââsdd1 8:49 0 476M 0 part â ââmd0 9:0 0 475.7M 0 raid1 /mnt ââsdd2 8:50 0 228.2G 0 part ââmd1 9:1 0 684.1G 0 raid6 sde 8:64 0 465.3G 0 disk ââsde1 8:65 0 476M 0 part â ââmd0 9:0 0 475.7M 0 raid1 /mnt ââsde2 8:66 0 464.8G 0 part ââmd1 9:1 0 684.1G 0 raid6 sda 8:0 0 931G 0 disk ââsda1 8:1 0 476M 0 part ââsda2 8:2 0 930.5G 0 part sdf 8:80 0 465.3G 0 disk ââsdf1 8:81 0 476M 0 part â ââmd0 9:0 0 475.7M 0 raid1 /mnt ââsdf2 8:82 0 279.4G 0 part ââmd1 9:1 0 684.1G 0 raid6 sdg 8:96 1 14.5G 0 disk ââsdg1 8:97 1 14.5G 0 part /lib/live/mount/medium loop0 7:0 0 322.8M 1 loop /lib/live/mount/rootfs/filesystem.squashfs dunno if there's anything helpful in there. Also you said this was a 2 drive failure so even if it failed to sync you > should still be able to mount it. If the array failed, the filesystem will > be completely FUBAR. > it definitely failed. but if it's going to be fubar, should it not have also failed to re-assemble and re-sync? I've repaired many failed (degraded?) arrays before by adding a new drive and re-syncing in a live boot environment. I'm trying to understand what went wrong on this particular outing. > You can probably just run mount on it and see what gets autodetected. > if file can't identify it, mount surely won't be able to either. however, just for fun: # mount /dev/md1 /mnt mount: block device /dev/md1 is write-protected, mounting read-only mount: you must specify the filesystem type -wes
