Re: [CentOS] Recover from an fsck failure

2020-05-29 Thread Simon Matter via CentOS
Hi > On Thu, May 28, 2020 19:38, Robert Nichols wrote: > >> What output do you get from: >> >> file -s /dev/mapper/vg_voinet01-lv_log >> lsblk -f /dev/mapper/vg_voinet01-lv_log >> > > file -s /dev/mapper/vg_voinet01-lv_log > /dev/mapper/vg_voinet01-lv_log: symbolic link TO '../DM-5' > dm

Re: [CentOS] Recover from an fsck failure

2020-05-29 Thread James B. Byrne via CentOS
On Thu, May 28, 2020 19:38, Robert Nichols wrote: > What output do you get from: > > file -s /dev/mapper/vg_voinet01-lv_log > lsblk -f /dev/mapper/vg_voinet01-lv_log > file -s /dev/mapper/vg_voinet01-lv_log /dev/mapper/vg_voinet01-lv_log: symbolic link TO '../DM-5' dm-f lsblk -f /de

Re: [CentOS] Recover from an fsck failure

2020-05-28 Thread Robert Nichols
On 5/28/20 1:33 PM, James B. Byrne via CentOS wrote: /dev/mapper/vg_voinet01-lv_log The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is cor

Re: [CentOS] Recover from an fsck failure

2020-05-28 Thread Pete Biggs
> > I ran mke2fs to locate the backup superblocks: > > mke2fs -n /dev/mapper/vg_voinet01-lv_log That will only tell you what mke2fs would do on that machine. I don't know if it will be the same on every machine. You should probably run dumpe2fs /dev/mapper/vg_voinet01-lv_log | grep superbl