So apparently the "LBA not found" error is occurring because the long SMART test (#1, power-on hour 9843) is succeeding, yet there are still pending sectors.
This is a different case from the issue I mentioned in #2 above. Either the 16 pending/uncorrectable sectors have actually been relocated (as the 16 reallocated sectors) but a disk firmware bug is causing them still to be reported, or the long test is not managing either to correct or to detect the errors. If there's a bug you have to live with it, or perhaps try something like a security erase of the disk.
There are suggestions that the "offline" test may be able to fix the latter case
smartctl -t offline /dev/sda.
man smartctl said:
The effects of this test are visible only in that it updates the SMART Attribute values, and if errors are found they will appear in the SMART error log, visible with the '-l error' option.
Otherwise you might try to run an exernal disk repair tool that doesn't rely on the SMART test, but that will take a lot longer than
fixdisk.
If you want to keep the box in question working, you could set it up with a spare or replacement disk, and access the suspect disk using a USB SATA dock. But if you're doing that and have a Linux PC (or a spare that can be booted from a live CD), it will be more reliable and faster to use the dock with that, especially if the PC and dock support USB3 (or if it's a desktop PC with a spare SATA slot, better to use that).
A filesystem checker command like this should carry out a non-destructive read-write test of the disk allocated to the filesystem and then correct the resulting filesystem -- there are three separate filesystems on the HDR disk:
Code:
# disk to check: replace as appropriate
dev=/dev/sda
# for each of the 3 partitions: check with: -cc read-write block test; -f force check; -y agree to repairs
for nn in 1 2 3; do e2fsck -cc -f -y ${dev}${nn}; done
This is supposed to be non-destructive but the usual caveats apply if any of the disk contents are precious and not otherwise backed up.
To run on the HDR, especially when repairing the large partition, the above would need a paging, aka swap, file which it doesn't have in Maintenance Mode;
fixdisk does the last partition and then uses a swap file there, and you could try to emulate that:
Code:
# disk to check: replace as appropriate
dev=/dev/sda
fix1() { # partition
# check partition with: -cc read-write block test; -f force check; -y agree to repairs
e2fsck -cc -f -y $1
}
# partitions to be checked shouldn't be mounted
for nn in 1 2 3; do umount -l ${dev}${nn}; done
SWAPFILE=/mnt/hd3/.swap
setup_swap() {
# make a 1GB paging file, quite slow
dd if=/dev/zero of=$SWAPFILE bs=1M count=1024 2> /dev/null &&
mkswap $SWAPFILE
}
swap_on() {
setup_swap &&
swapon $SWAPFILE || return 1
mount -o remount,size=512M /tmp
}
# Do partition 3 of the disk first, mount /mnt/hd3 if necessary, make a "big" swap file and enlarge /tmp
fix1 ${dev}3
mount | grep -q " on /mnt/hd3 " || mount ${dev}3 /mnt/hd3
swapoff $SWAPFILE
swap_on
grep -qE "^$SWAPFILE " /proc/swaps || echo "Swap file problem" 2>&1
# do each of the remaining partitions
for nn in 1 2; do fix1 ${dev}${nn} || break; done
I can't remember trying this on a running HDR but it may be asking too much for the HDR to run the PVR functions as well as the disk check, even with a much bigger swap file.
However even quite an old desktop PC should have enough RAM for a live filesystem as well as the entire check program and its spawned
badblocks program and their buffers, as well as a beefier CPU.
