On Wed, Jan 24, 2024 at 10:19 AM Phillip Susi <phill@xxxxxxxxxxxx> wrote: > > Andy Smith <andy@xxxxxxxxxxxxxx> writes: > > >> Try mount -t ext4. If that doesn't work, see what e2fsck/tune2fs say. > > > > I've not needed that before and my instinct is that if it is needed, > > something has gone wrong. But in any case it did not help: > > If the fs is listed in /etc/fstab, then mount finds the fs type from > there. Otherwise, you have to specify it. At least, that used to be > the case. This may have changed at some point and I still do it from > mussle memory. > > I have never had adding the -t <fstype> be necessary and/or work better than mount without a -t even when the fs is not in /etc/fstab. That is going back at least 15+ years (note rhel4 did not need -t, and it is old). The mount program seems to find the type of fs (from the first few bytes on the fs) and handle it, and if it does not mount, then adding -t <correctfstype> had never made the mount work (usually because the fs is seriously damaged in some manner, or completely gone). So if "mount <device> some-location" does not work, then either the fs is corrupted (for some reason), or the partition table changed making it appear to be corrupted(data at wrong locations), or the fs module is not loaded and/or supported in the kernel. And I have debugged a lot of fs missing, and in the environment I am in it is usually someone "fixed" the partition table start to be different for some reason (or removed the partition table), or put a partition table on top of the fs. You might do a "dmsetup table" and specify what the lv names is and maybe a ls -l /dev/mapper so we can see what the partitioned lv dm mapping looks like. and a fdisk -l against the partitioned lv, and a ls -l /dev/<vgname>/
