You are not logged in.
Pages: 1
Hello, i was trying ubuntu 16.04 for a time and yesterday i figure it was time to go back to Arch Linux. So when i finished my installation i got this errors after rebooting into the HDD:
http://i.imgur.com/UrIZSTa.jpg
I thought "Ok, this is me screwing something up in the installation process", so i formated every partition i had again and installed following the Arch Wiki.
This time when i rebooted after the installation no errors appeared. I installed gnome, did a systemctl on gdm and rebooted again expecting everything to be ok...but it was not the same errors appeared. So i boot up my arch linux live usb and tried to do a scan with testdisk. A quick scan gave nothing but a deep search one gave this errors in like 20 seconds.
I mount the partitions hoping so i could salvage my files and when i did a arch-chroot the same erros appeared again, not letting me complete the arch-chroot.
So at this moment i'm pretty convinced that my HDD is done for..but then i format every partition again and install Ubuntu and for my surprise everything works fine. I can access my files and Ubuntu is running at full speed.
I tried to do a testdisk deep search scan again with Arch Live Usb after installing Ubuntu and the scan this time took 4m to find the same errors.
So my doubt here is if my HDD is really dying and i should get a new one or is this a problem that can be fixed.
Thanks for all the help in advance.
Last edited by CyberNhull (2016-12-28 02:26:36)
If it does not kill you....It will make you smarter
Offline
Run an extended SMART test and post the results.
Offline
Sounds like it might be software related.
I'm not familiar with testdisk,but imo the first stop for hardware errors on drives should be S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Run an extended SMART test and post the results.
This was the results, both of them finish way before the apointed time
https://imgur.com/gallery/BI58k
If it does not kill you....It will make you smarter
Offline
Why are you posting photos instead of proper text?
Backup all your data and do a full badblocks write+read test on the whole disk.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Why are you posting photos instead of proper text?
Backup all your data and do a full badblocks write+read test on the whole disk.
Because im writing this from my smartphone. With badblocks give me the same error output at 1.83% with 4/0/0 errors
If it does not kill you....It will make you smarter
Offline
"smartctl -a /dev/<device>" and watch out for pending sectors and offline uncorrectables, but it very much smells like death, so ensure to backup all important data *first*.
Offline
If you used the -w flag with badblocks and you get errors then I'd that disk is toast. Keep in mind that using -n will not be much different than the smart test you have already done, it _needs_ to be the write-mode test (-w).
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
If you used the -w flag with badblocks and you get errors then I'd that disk is toast. Keep in mind that using -n will not be much different than the smart test you have already done, it _needs_ to be the write-mode test (-w).
I did the test as you said and it didn't gave me any errors. I tried to do the tests again and it appears i have no errors now, thanks. Why putting the bits all to zeros fixed this problem?
If it does not kill you....It will make you smarter
Offline
The blocks magnetization decayed or the blocks were replaced by some reserve. Watch the outout of "smartctl -a" and track it a bit, because neither would be a good sign (unless you know of very particular incidents like drying it in a microwave or similar ;-)
Offline
R00KIE wrote:If you used the -w flag with badblocks and you get errors then I'd that disk is toast. Keep in mind that using -n will not be much different than the smart test you have already done, it _needs_ to be the write-mode test (-w).
I did the test as you said and it didn't gave me any errors. I tried to do the tests again and it appears i have no errors now, thanks. Why putting the bits all to zeros fixed this problem?
The previous write to those sectors could have been done incorrectly due to any number of reasons, could be a really bad sector, or due to voltage dip, mechanical shock when writing. From my experience so far, rewriting the sector is enough to make things work fine again but you should keep an eye on the smart parameters and see if you have any reallocated sectors, if you have more reallocated sectors than before or if the number starts increasing, backup your data and replace the disk as soon as possible.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1