[PLUG] filesystems question
wes
plug at the-wes.com
Fri May 13 18:04:44 UTC 2022
On Fri, May 13, 2022 at 10:02 AM Ben Koenig <techkoenig at protonmail.com>
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
More information about the PLUG
mailing list