File system check of the root filesystem failed, manual fsck can not fix [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
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.
linux lvm ssd busybox superblock
edited Jan 31 at 2:37
galoget
36319
asked Jan 23 at 15:21
serebuka
41
closed as off-topic by Rui F Ribeiro, andcoz, jayhendren, mdpc, cas Jan 24 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
add a comment |Â
up vote
-1
down vote
favorite
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.
linux lvm ssd busybox superblock
edited Jan 31 at 2:37
galoget
36319
asked Jan 23 at 15:21
serebuka
41
closed as off-topic by Rui F Ribeiro, andcoz, jayhendren, mdpc, cas Jan 24 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
THIS DISK IS DYING if it isn't dead already. You could try making an image backup to another disk of the dying drive withddrescue. 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.ddrescuewill 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 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 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 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 at 3:50
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
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.
linux lvm ssd busybox superblock
edited Jan 31 at 2:37
galoget
36319
asked Jan 23 at 15:21
serebuka
41
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.
linux lvm ssd busybox superblock
edited Jan 31 at 2:37
galoget
36319
asked Jan 23 at 15:21
serebuka
41
edited Jan 31 at 2:37
galoget
36319
edited Jan 31 at 2:37
galoget
36319
edited Jan 31 at 2:37
galoget
36319
36319
asked Jan 23 at 15:21
serebuka
41
asked Jan 23 at 15:21
serebuka
41
asked Jan 23 at 15:21
serebuka
41
41
closed as off-topic by Rui F Ribeiro, andcoz, jayhendren, mdpc, cas Jan 24 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
closed as off-topic by Rui F Ribeiro, andcoz, jayhendren, mdpc, cas Jan 24 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
THIS DISK IS DYING if it isn't dead already. You could try making an image backup to another disk of the dying drive withddrescue. 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.ddrescuewill 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 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 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 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 at 3:50
add a comment |Â
THIS DISK IS DYING if it isn't dead already. You could try making an image backup to another disk of the dying drive withddrescue. 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.ddrescuewill 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 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 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 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 at 3:50
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 at 16:33
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 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 at 16:36
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 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 at 17:08
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 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 at 3:50
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 at 3:50
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
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.
answered Jan 23 at 15:33
Andy Dalton
4,7561520
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 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 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 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
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.
answered Jan 23 at 15:33
Andy Dalton
4,7561520
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 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 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 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
add a comment |Â
up vote
3
down vote
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.
answered Jan 23 at 15:33
Andy Dalton
4,7561520
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 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 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 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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.
answered Jan 23 at 15:33
Andy Dalton
4,7561520
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.
answered Jan 23 at 15:33
Andy Dalton
4,7561520
answered Jan 23 at 15:33
Andy Dalton
4,7561520
answered Jan 23 at 15:33
Andy Dalton
4,7561520
answered Jan 23 at 15:33
Andy Dalton
4,7561520
4,7561520
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 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 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 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
add a comment |Â
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 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 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 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
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 at 15:33
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 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 at 15:52
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 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 at 17:11
@serebuka the issue is with the disk itself, which underpins the PV holding the root LV. There is no "magic" here.
– roaima
Jan 23 at 17:11
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
It's a pity! Will try to recover some data asap
– serebuka
Jan 23 at 17:16
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
ddrecued most likely all data, now going to return SSD under warranty (3 years)
– serebuka
Jan 25 at 7:41
add a comment |Â
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.ddrescuewill 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 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 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 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 at 3:50