Disabling HPA on Samsung HDDs

A friend of mine bought a new 1TB hard drive from Samsung (HD103SJ with firmware 1AJ100E4). He used Windows Vista to partition it and format 2 partitions for NTFS, one to install Windows 7 and one to move data from an external drive. Everything worked well, Vista used the drive as intended. When he rebooted to install Win7 everything – Windows 7 setup, BIOS and unfortunately also Vista – saw the drive with only 33 MB capacity, reporting one unformatted partition on it.

Searching the internet we found out it must be a problem with the drive’s host protected area (HPA) in conjunction with his mainboard/SATA controller (ironically from Gigabyte). He updated BIOS and chipset drivers but the problem persisted. According to some forums there are some tools for Windows to fix that issue. Since many people reported data loss afterwards and he didn’t have another copy of the data he moved from his external drive we decided to boot into the new Gentoo Live DVD that also allowed me to log in remotely via SSH to investigate the problem (we are more than 500km away from each other).

Following a short guide on how to detect and disable HPA we could see the settings of his drive:

# hdparm -N /dev/sdb
max sectors = 65134/1953525168, HPA is enabled

This seems to have been the opposite configuration of what should have been set according to the guide: While the examples from the guide had a much greater value before the slash his drive seemed to show the intended remainder to be allocated to the HPA set for “public” use, so his HPA seemed to cover almost the entire 1TB of his HDD.

Before we tried to correct that value we wanted to check if we can access any data right away. Unfortunately everything prevented us from accessing the HPA – the kernel did only register /dev/sdb1 but not /dev/sdb2, smartmontools showed 33MB capacity as well, parted refused to work and fdisk finally showed the correct partition table but reported a mismatch in geometry, so at least we still seemed to access the same start sector of his HDD:

Disk /dev/sdb: 33 MB, 33348608 bytes
255 heads, 63 sectors/track, 4 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x24c2a85c

Device Boot Start End Blocks Id System
/dev/sdb1 1 38245 307200000 7 HPFS/NTFS
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(38244, 193, 29)
/dev/sdb2 38245 121601 669558784 7 HPFS/NTFS
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(38244, 193, 30)
Partition 2 has different physical/logical endings:
phys=(1023, 254, 63) logical=(121600, 247, 55)

We also tried to access /dev/sdb with dd but only got the 33MB until the drive “ended”. Considering the HPA modifications to be the last resort we tried to change it only temporarily at first, but had to set it permanently to get any effects on the system after a reboot. Please note that the manpage for hdparm explicitely states that changing that setting is “VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY”. I copied the old value to a text editor before making the modifications, so I hoped we could at least set it back to what it was before our changes in case it didn’t work well. To make a permanent change, simply run the same command with p (for permanent) followed by the new maximum value to be set (to disable HPA this would be the exact same value as written after the slash):

# hdparm -N p1953525168 /dev/sdb

Having rebooted, fdisk did not complain any more and the kernel recognized both partitions:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x24c2a85c

Device Boot Start End Blocks Id System
/dev/sdb1 1 38245 307200000 7 HPFS/NTFS
/dev/sdb2 38245 121601 669558784 7 HPFS/NTFS

hdparm confirmed that we just disabled HPA:

# hdparm -N /dev/sdb

max sectors = 1953525168/1953525168, HPA is disabled

We mounted his data partition read-only using ntfs-3g and since everything seemed fine we started to copy everything back to his external drive, just to be sure we had a backup of his data in case that Windows would decide to crash his partition after another reboot. However, Windows Vista did recognize the drive correctly again and so did Windows 7; he can access all data and nothing seems to be corrupted or missing.

It appears strange that Windows initially ignored the HPA and worked well until he rebooted. But having had extreme, sporadic problems myself using a Silicon Image SATA controller with Windows XP SP2 as well as Windows Vista (without SP, back in 2007) it did not really surprise me any more.

segfaults and libjpeg.so.62 missing after update

I updated my Gentoo system last week (amd64) and ran into multiple problems.

Due to compile errors on many ebuilds I decided to run a revdep-rebuild. After about an hour it recognized that about 380 ebuilds were broken and had to be remerged. I began but could not finish that day so I left revdep-rebuild (which happened to stop due to an error anyway) and shut my system down.

The next day I realized that about half my system was broken. CUPS crashed repeatedly, reporting a segfault with libc whenever I tried to print anything (visible in the kernel log). Remerging cups or glibc did not help, so I went to the Gentoo forums and found the advise to run

emerge -e system 
perl-cleaner all 
emerge -1 libtool 

It took a long time involving the usual stop-and-go caused by build errors but finally it finished. CUPS worked again and so did most of the system. Unfortunately 64 bit binaries like nxclient still did not run because libjpeg.so.62 did not exist any longer. Well, it did for 32 bit apps (so the 32 bit Firefox binary could still run) but not for 64 bit. (the 32 bit version is belongs to app-emulation/emul-linux-x86-baselibs) As usual, linking to the 32 bit library was without success (wrong ELF architecture) and linking to libjpeg.so.7 didn’t work well (I was able to run NX but all JPEGs were missing).

I was lucky enough to find a rather unrelated bug report on the bugtracker that indicates there is a second ebuild for libjpeg called media-libs/jpeg-compat which actually contains the missing 64 bit version of libjpeg.so.62. Having emerged that everything works fine again now.

Wechsel des Blog-Systems

Nachdem mir jahrelang Serendipity treue Dienste geleistet hat (genauer: 4 1/2 Jahre), ich jedoch an den vielen Features und Plugins, sowie der besseren Oberfläche von WordPress Blut geleckt hab, habe ich nun komplett umgestellt. Die alten Beiträge sind vollständig importiert und Umleitungen auf allen wichtigen Adressen gesetzt. Die meisten alten Links sollten auf die entsprechenden Artikel bei WordPress auflösen; Probleme gibt es nur bei Sonderzeichen und Umlauten, wobei keine allzu wichtigen Artikel davon betroffen sind, weshalb ich das einfach mal ignoriere.

Hier und da gibt es noch ein paar Problemchen und abgesehen davon fehlt dem CSS auch noch der Feinschliff und die Sprache des Templates steht vorerst auf Englisch fest. Da ich jedoch unter dem alten System nicht weiterbloggen wollte, da WordPress schon seit 2 Wochen fertig eingerichtet hier rum lag, habe ich mich dazu entschlossen, die Umstellung gleich vorzunehmen und alles Weitere nach und nach im laufenden Betrieb zu erledigen.