1

Topic: Curious behaviour on hard drive with GParted - disk "locked"

I read the (Sticky) tutorial on GParted with fixing resized NTFS/ext4 partitions.

Saying that, I thought you or someone may be of help on a curious problem I have:
On an experimental box I have (Dell GX150), I usually test out various programs/OS/etc before I install them. I could of course use a VM but that is not the real environment.

Some time ago, The Dell had a 20Gb partition with WinXP Pro SP2 and I thought I would try installing the latest (at that time) Ubuntu 10.04 LTS desktop before I updated my 8.04 LTS system. The live CD worked well so I went ahead with the install - with partioning (not moving or resizing the existing 20Gb Windows primary partition) the remaining space on the Dell HD (Seagate Barracuda IDE Ultra ATA - remaining 60Gb) into a swap partition and a system partition with GParted (during the Ubuntu install process). Unfortunately, after partioning and a reboot, the Dell will not boot into any partition. I can still mount the NTFS, ext2, ext3, etc partitions by using the live CD but but not by hard booting. I can even access files with Mignight Commander, File manager, etc from the LiveCD.

No problem, I thought. I would delete all partitions and start again. Unfortunately, GParted returns an error that the disk cannot be partitioned after I use the commit command. I have tried all the disk wiping programs out there (Active@Disk, Darik's Boot & Nuke, HDDErase, shred, etc) but every program will exit with either claiming that the disk has been successfully erased or in the case of the Boot & Nuke, with an error - "successfully erased with one error". Unfortunately, the disk still shows up with the same partitions as before and unbootable. I have tried replacing the MBR, using fdisk and PQMagic, and have run out of avenues to explore. the disk is healthy (shows up so in Seagate's Disc Wizard) and runs with out any grinding or other noises.

I have replaced the disk but I've never used GParted again. I'm not blaming Gparted but I'm curious as to why this is an anomaly - after using GParted, the disk is "locked". Perhaps someone may have an explanation and a solution on "unlocking" the disk partitions or erasing the disk and start over.

2

Re: Curious behaviour on hard drive with GParted - disk "locked"

I am not sure that Ubuntu uses GParted for partitioning. It contains GParted (for older versions, at least) but I think it uses another tool, partman to partition the hard drive.

This seems quite strange. Are you sure that the hard drive firmware is good? I know there were some hard drives that were "locked" by installing the operating system. I guess this is performed by the BIOS (there were even "unlock" programs).
Is there any kind of protection in the motherboard BIOS? Whiping the disk but still getting the same partitions isn't usual at all!

Did you try to use the GParted livecd instead of GParted from the Ubuntu install cd?
Did you try the dd command (from the terminal) to put to zero the first few cylinders of the drive?
Did you try to run testdisk (included in the GParted livecd) to check the drive?
Did you try to connect it to another motherboard or controller?
Nevertheless, I think I don't read this story about the "commit command"  for the first time...  I can't remember how.

*** It is highly recommended to backup any important files before doing resize/move operations. ***

3 (edited by murugan 2011-12-12 05:00:16)

Re: Curious behaviour on hard drive with GParted - disk "locked"

class413 wrote:

I am not sure that Ubuntu uses GParted for partitioning. It contains GParted (for older versions, at least) but I think it uses another tool, partman to partition the hard drive.

This seems quite strange. Are you sure that the hard drive firmware is good? I know there were some hard drives that were "locked" by installing the operating system. I guess this is performed by the BIOS (there were even "unlock" programs).
Is there any kind of protection in the motherboard BIOS? Whiping the disk but still getting the same partitions isn't usual at all!

Did you try to use the GParted livecd instead of GParted from the Ubuntu install cd?
Did you try the dd command (from the terminal) to put to zero the first few cylinders of the drive?
Did you try to run testdisk (included in the GParted livecd) to check the drive?
Did you try to connect it to another motherboard or controller?
Nevertheless, I think I don't read this story about the "commit command"  for the first time...  I can't remember how.

Thanks for the reply and the suggestions.
I apologise on using the term "commit" - it comes from my CLI experience. I should have used "apply" as in the menu options.
I have tried moving the harddrive to another test box - a CTL computer but it doesn't make a difference.
Ubuntu does use Gparted as a choice and I've used the latest version of Gparted Live, PartedMagic Live (which includes GParted) but the disk is "locked" in its state as described).
I've used the command line (from sysRescueCD LiveCd, Knoppix, and Ubuntu RescueRemix) to repartion/wipe the disk, but all fail:
dd (if=/dev/zero of=/devsda), cfdisk (says it has deleted the partitions on a "write" - either one at a time or all - sda1, sda5, sda6 - but the partitions are the same as before) same with fdisk, sfdisk and sgdisk (/dev/sda --attributes=1:set:2 (same as before on sgdisk /dev/sda --attributes=1:show). I have even attempted to delete the MBR and write a new MBR (DOS 6.22 and syslinux (mbr.bin)) but they don't change the MBR at all - Windows is still the OS. I've tried installing GRUB (grub-install) but ........

I'm not blaming GParted (or any other partitioning software) - I was just curious as to why or if anyone else had the  same experience.
My only suspicion is that although Win OEM (Dell, HP, etc) installs seek a tattoo (fact), the OS has somehow also "tattooed" the hard drive firmware (unfounded by Google searches). To test this theory out, I'm going to redo the OS (OEM) install and repartition the disk as before on an identical hard drive I've got (Seagate 7200.7). To test the drive firmware being "tattooed" theory, I would have to re-flash my drive with existing or newer firmware. Unfortunately, Seagate have long pulled their firmware for this drive and only commercial firmware upgrades are available (which I don't trust - see http://www.firmwarebase.com/index.php?a … p;start=6)
(the hard drive in question is a Seagate 7200.7 Barracuda ST340014A F/W 3.06 3JX1G5ZS)
Hopefully this may prove or shed some light something. The "new" hard drive is expendable as it is a system pull when I upgraded my hard drives long ago (I'm suspicious of PATA/SATA drives as they don't last as long as SCSI ones).
As far as the existing hard drive is concerned, I have pulled it long ago but remains with me as a curiosity. Personally, my systems have only one IDE drive with all the rest running off Adaptec SCSI controllers (no RAID). Even though SCSI disks are lower in capacity, they have proven their reliability (I've yet to have a SCSI disk fail - I still have my first SCSI Seagate disk - a whopping 20Mb! in 1988 - running).
Will let you know how the "new" disk behaves.

Added: (the hard drive in question is a Seagate 7200.7 Barracuda ST340014A F/W 3.06 3JX1G5ZS) - maybe someone out there has a firmware flash for this  or a Seagate 7200.7 Barracuda ST340014A F/W 3.06 5JX4TAG8 which I plan on using as the next guinea pig. If so PM me.