Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Disk /dev/sda - 160 GB / 149 GiB - CHS 19457 255 63
Current partition structure:
Partition Start End Size in sectors
Warning: number of heads/cylinder mismatches 65 (NTFS) != 255 (HD)
Warning: number of sectors per track mismatches 26 (NTFS) != 63 (HD)
I think this may be more to the point; I get the impression that this machine has not been used for a while, the backup battery for the BIOS settings may be low/dead, and the BIOS settings may have been corrupted/restored to default values. Is any of that plausible?
#hdparm -iI /dev/sda
/dev/sda:
Model=SAMSUNG HD160JJ, FwRev=ZM100-33, SerialNo=S08HJ10Y968343
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312581808
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
ATA device, with non-removable media
Model Number: SAMSUNG HD160JJ
Serial Number: S08HJ10Y968343
Firmware Revision: ZM100-33
Standards:
Used: ATA/ATAPI-7 T13 1532D revision 4a
Supported: 7 6 5 4 & some of 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 312581808
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 152627 MBytes
device size with M = 1000*1000: 160041 MBytes (160 GB)
cache/buffer size = 8192 KBytes (type=DualPortCache)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
SET_MAX security extension
Automatic Acoustic Management feature set
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Read/Write Long (AC1), obsolete
* SCT Write Same (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
120min for SECURITY ERASE UNIT. 120min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct
Quote:
Any particular BIOS mucking you did BTW?
Quote:
I think this may be more to the point; I get the impression that this machine has not been used for a while, the backup battery for the BIOS settings may be low/dead, and the BIOS settings may have been corrupted/restored to default values. Is any of that plausible?
I haven't been tinkering with the BIOS, and I did use my computer on a regularly irregular base, but not those partitions. Because I had a backup, I didnt feel rushed to hook those up in my current setup.
I just recalled this: About a month ago, I booted to my Windows partition. I got error messages concerning the partitions of the hard disk. There were plenty and quite indeipherable to me. I rebooted to Linux and never paid attention to them. Perhaps it was then when this failure happened. Because I never had seen errors while using or booting Linux , I just regarded them as plain Windows error messages and did nothing after. Bit thick perhaps.
Set 16383 cylinders, 16 heads and 63 sectors in testdisk and try again?
Quote:
Originally Posted by geofyt
I just recalled this: About a month ago, I booted to my Windows partition. I got error messages concerning the partitions of the hard disk. There were plenty and quite indeipherable to me. I rebooted to Linux and never paid attention to them.
(Not that I am the slightest interested in looking at it but) Windows does have system logs. So any errors will be recorded there. Maybe have a look?
Set 16383 cylinders, 16 heads and 63 sectors in testdisk and try again?
I'm currently not able to. But tomorrow, I will. Perhaps a new year will bring luck
Quote:
(Not that I am the slightest interested in looking at it but) Windows does have system logs. So any errors will be recorded there. Maybe have a look?
It seems those logs are accessed through an event manager, which requires me to boot into Windows to run a program to look at the files... I'm a bit hesitant to do so, because I suspect Windows did something to my disk. No solid proof of that though.
This makes testdisk think I have a 8455MB hard drive. For every partition Testdisk also warns about "Bad starting head (CHS and LBA don't match)"
I realized I have a similar hard drive laying around. I scooped it up, and connected it to see what the CHS data was. The drive is a Samsung SP1614C which has the same numbers of bytes and sectors as the HD160JJ we are trying to fix. SP1614C has 19457 cylinders, 255 heads and 63 sectors. These values are also used in Testdisk's analyze option.
Furthermore I tried the program to see what it could do, but honestly, I dont really get it. Despite consulting the wiki.
Lastly, I knew I had a print of results from fdisk -l from a few years ago. I found it, but apparently fdisk didn't include CHS data some time ago. (Different partition layout was used as well)
1 * HPFS - NTFS 0 32 33 9728 203 11 156291072
2 P HPFS - NTFS 9728 203 12 12322 237 11 41674752 [Documenten]
3 P Linux 12322 237 12 14917 16 11 41674752
4 E extended LBA 14917 16 12 19457 53 52 72937472
5 L Linux 14917 48 44 17511 82 43 41674752
6 L Linux Swap 17511 115 13 17835 195 24 5210112
7 L Linux 17835 227 57 19457 21 20 26044416
This looks correct to me. I feel rather silly to ask, but can I write this partition table to disk? Safely without compromising data on /dev/sda5 and /dev/sda7...?
I feel rather silly to ask, but can I write this partition table to disk? Safely without compromising data on /dev/sda5 and /dev/sda7...?
Yes you can as the data in the Partition Table is just one location at the start of the disk, changing it doesn't change partition data.
Making a backup of the PT to file never hurts:
Yes you can as the data in the Partition Table is just one location at the start of the disk, changing it doesn't change partition data.
Caution: There is an extended partition with logical drives. Each of those logical drives will get a sector with an extended partition table written at the start of it. If those logical drives are not in the correct position, you will be overwriting some of your data. It is only the primary partition table that can be casually overwritten without fear of hurting your data.
There would be no such concern with GPT, but this drive is not using GPT.
Caution: There is an extended partition with logical drives. Each of those logical drives will get a sector with an extended partition table written at the start of it. If those logical drives are not in the correct position, you will be overwriting some of your data. It is only the primary partition table that can be casually overwritten without fear of hurting your data.
Thanks for clarifying, I learned something new there.
I'm now doing a cylinder analysis for the complete disk. I have no hopes for that, but it never hurts.
After a full analysis, Testdisk suggested trying 140 cylinders. This won't be it, so here no luck either.
In other tries I tested to check for Reiser superblocks. Nothing. In the end I let loose photorec to see what it could harvest from both disks. There were files found, but alas, not the ones useful. Seems to me, this is a hopeless case. Right?
My last-ditch strategy with testdisk is to set Partition Type to "None" at the start, then go into the Geometry menu and change both Heads and Sectors to 1, letting testdisk recalculate "Cylinders" as the total number of sectors on the disk. Sometimes that's the only way to get it to ignore space that it sees as properly allocated and to check every sector, not just the ones that it thinks are in "likely" locations.
My last-ditch strategy with testdisk is to set Partition Type to "None" at the start, then go into the Geometry menu and change both Heads and Sectors to 1, letting testdisk recalculate "Cylinders" as the total number of sectors on the disk. Sometimes that's the only way to get it to ignore space that it sees as properly allocated and to check every sector, not just the ones that it thinks are in "likely" locations.
Too bad, it didn't work! Testdisk reckons the disk to be too small (< 9440361 TB / 8585958 TiB) Quite the disk
Code:
The harddisk (160 GB / 149 GiB) seems too small! (< 246 GB / 229 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
> NTFS 241172479 482342910 241170432
FAT32 290509999 342930030 52420032 [D]
FAT32 290510005 342930036 52420032 [NO NAME]
Disk /dev/sda - 160 GB / 149 GiB - 312581808 sectors
The harddisk (160 GB / 149 GiB) seems too small! (< 9440361 TB / 8585958 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
These were the results of the initial analysis. The first time it probed the first three partitions correct and started to search from off that third partition's end. After that analysis I did a deep search which made it search for the full 100%. Results:
Code:
The following partitions can't be recovered:
Partition Start End Size in sectors
> VMFS 31326185 18438206466684363 18438206435358178
VMFS 146036641 3377907519533190 3377907373496549
NTFS 156293119 312584190 156291072
NTFS 241172479 482342910 241170432
FAT32 290509999 342930030 52420032 [D]
FAT32 290510005 342930036 52420032 [NO NAME]
[ Continue ]
VMFS 3698590810, 9440361 TB / 8585958 TiB
The list of partitions was long. I could list files of some supposedly fat12 partitions. The directory list was comprised of "stuff from the 80s".
Code:
-rwxr-xr-x 0 0 7274601 1-Mar-1980 00:03 n
I copied one file out of curiosity. It was a succesfull copy according to Testdisk, but into the target directory nothing was written.
Well, I guess the conclusion is that nothing can be done anymore. Just another heart breaking tale of data loss.
Thanks everyone, for the help. It is much appreciated.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
