0

Linux Mint 18 on SDD with LVM ext4

Booting in recovery mode shows:

ata3.00: status: { DRDY DF ERR }
ata3.00: error: { ABRT }
ata3.00: configured for UDMA/100
sd 2:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
=//= tag#0 Sense Key: Illegal Request [current] [descriptor] 
=//= tag#0 Add. Sense: Unaligned write command
=//= tag#0 CDB: Syncronize Cache(10) 35 00 00 00 00 00 00 00 00 00
blk_update_request: I/O error, dev sdb, sector 0
ata3; EH complete
fsck exited whit status code 4
done.
Failure: File system check of the root filesystem failed
The root filesystem on dev/mapper/ming--vg-root requires manual fsck

BusyBox v1.22.1 ....
(initramfs)

Manual mount returns:

# mount /dev/mint-vg/root /mnt/asdx
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mint--vg-root,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

Caja mounts disk with the same error:

Error mounting /dev/dm-0 at /media/batman/8b8126f2-1d26-4dee-b728-a85ca9274de5: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/dm-0" "/media/batman/8b8126f2-1d26-4dee-b728-a85ca9274de5"' exited with non-zero exit status 32:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mint--vg-root,missing codepage or helper program, or other error

fsck and e2fsck not working as expected:

# e2fsck -f -b 32768 /dev/mapper/mint--vg-root
e2fsck 1.42.13 (17-May-2015)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/mapper/mint--vg-root: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on /dev/mapper/mint--vg-root


/dev/mapper/mint--vg-root: ***** FILE SYSTEM WAS MODIFIED *****

/dev/mapper/mint--vg-root: ********** WARNING: Filesystem still has errors **********

gparted returns:

 dev/sdb Input/Output errors

Autorepair from boot-repair not helped.

testdisk can list files.

How do I fix this?

My original topic with some boot-repair logs and SSD SMART errors: https://forums.linuxmint.com/viewtopic.php?p=1419387

Update:

Disk was exchanged under warranty, so now I have to restore backups.

closed as off-topic by Rui F Ribeiro, andcoz, jayhendren, mdpc, cas Jan 24 '18 at 3:50

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Rui F Ribeiro, andcoz, jayhendren, mdpc
If this question can be reworded to fit the rules in the help center, please edit the question.

  • THIS DISK IS DYING if it isn't dead already. You could try making an image backup to another disk of the dying drive with ddrescue. Boot from a rescue disk (clonezilla or gparted make good rescue disks), have another formatted filesystem mounted and ready to save the image file to. There is no need to mount the dying filesystem. That will at least give you something you might be able to recover some files from. ddrescue will be slow as it continually retries reading from the dying drive when it encounters an error. Remember to make regular backups in future. – cas Jan 23 '18 at 16:33
  • use a mapfile with ddrescue in case you have to reboot (so it can restart where it left off rather than from the beginning). – cas Jan 23 '18 at 16:36
  • Thanks! Making image backup seems to be the only solution. Got this disk problem after exactly one year working (11 jan 2017 - 19 jan 2018). – serebuka Jan 23 '18 at 17:08
  • I'm voting to close this question as off-topic because it's about a hardware fault (disk failure), not about fsck or mount or anything specific to unix/linux. – cas Jan 24 '18 at 3:50
3

The errors that you're seeing look like a disk failure, not a problem with the filesystem. If the disk itself is failing, fsck won't help.

  • Exactly, I just left a comment saying the same thing. +1. It should be fairly obvious that if you cannot fix inconsistencies no matter what, that you have deeper issues. Furthermore, if either SMART and boot are giving errors, I do not even understand what the OP is hoping to achieve asking questions in several forums. Nobody will have a magical solution to fix a broken SSD/hd. – Rui F Ribeiro Jan 23 '18 at 15:33
  • Thanks for replies. I hoped to get some magic command to restore my fs in lvm volume. I thought all solutions with fsck are for regular /dev/sdXY case, not for my specific LVM ext4 /dev/mapper/mint--vg-root – serebuka Jan 23 '18 at 15:52
  • @serebuka the issue is with the disk itself, which underpins the PV holding the root LV. There is no "magic" here. – roaima Jan 23 '18 at 17:11
  • It's a pity! Will try to recover some data asap – serebuka Jan 23 '18 at 17:16
  • ddrecued most likely all data, now going to return SSD under warranty (3 years) – serebuka Jan 25 '18 at 7:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.