Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
In the process of cloning an old 80gb SATA laptop drive onto a new 320gb SATA laptop drive, I've apparently managed to convince the OS that my new HDD is also of size 80gb. Here are the details:
I normally run Windows, so I booted into Linux via Slax (Kernel 22.214.171.124) on a USB drive.
I used dd to copy my old drive onto my new drive.
I opened GParted 4.1, which displayed, as expected, that my new drive contained a small service partition (FAT16, I think) followed by a large data partition (NTFS) followed by a large amount of free space.
I told GParted to resize the NTFS partition from ~80gb to take up all the free space on the drive. This operation completed successfully.
When I try to boot into Windows off the new drive, I get a stop error. Back in Linux, when I run fdisk on the new drive or examine it in GParted, the 320gb drive now shows up as an unformatted 80gb drive.
I have a well-tested SATA-to-USB enclosure which I used to hold one of the drives. The new drive shows up as the wrong size regardless of whether it's in the enclosure or plugged into the laptop's SATA port directly.
I downloaded the latest BIOS from Dell just a few weeks ago, so I don't think this is a matter of an old BIOS not recognizing drives larger than 80gb.
(I used dd instead of GParted to do the actual copying because GParted wouldn't copy the service partition on my old drive. I'm not sure if that service partition is necessary -- I've heard that some Lenovo laptops won't boot without it, but I've never heard that about Dell laptops -- but I figured I might as well try to copy it. In any case, this procedure worked just fine on a friend's Lenovo laptop, with a very similar setup.)
It looks like resizing the NTFS partition somehow messed up the operating system's idea of the new hard drive's geometry. To wit, fdisk reports 9546 cylinders, but I expect 16383. Changing the number of cylinders with fdisk doesn't seem to do anything. (If the geometry really is the problem, then more than just the cylinder count is wrong; the drive is 1/4 its expected size, but it's missing fewer than half its cylinders.)
I'm perfectly happy to start from scratch with this drive, ignore the service partition, and use GParted to perform the cloning this time. But first, I need to convince the operating system that the drive is actually 320gb in size, and I'm not sure how to do that. I've already tried copying over the new drive (well, the first 80gb of it, anyway) with /dev/zero, but that didn't change anything; at this point, I'm out of ideas.
Do you guys have any idea what's going on here? I'd really appreciate whatever insight you have.
Well, anytime you clone a HDD, it should clone it exactly, meaning that you'll always end up with a 80GB partition on your new 320GB Hard Drive.
But you followed all the steps I would've taken to make it larger, by using GParted to expand the partition. However, it would appear that GParted messed up when it was expanding the partition.
You might be able to perform the same steps again, and this time get it to work, OR, GParted is actually formatting as well as expanding, and in that case you'll want to check the commands you've given it.
As a last case, have you tried booting windows without the expansion? It should work that way, and you might just think about creating a separate partition with the free space using GParted, if you can't get the expansion to work.
BIOS should have nothing to do with recognizing the drive. It's just been partitioned with only 80GB, and the rest is just waiting to be created, before it can be recognized by the system. Just check around for some formatting programs. I've always used Partition Magic because that works extremely well in windows, except that costs money.
I don't remember the details, but I've read about a similar problem and you would need some pretty specialized programs to fix it.
If I understand correctly:
1) There is a feature in the firmware of many drives to let them pretend to be smaller in a way intended to be very hard for an end user to clear. So a vendor can replace defective drives under warranty with a bigger drive (because original size is obsolete) without giving customers an incentive to break drives.
2) There is code in the boot area of drives set up by DELL to reprogram the drive firmware, using the feature described in (1) when you boot off of a cloned drive. I don't understand the benefit to Dell of doing that to their customers. But I think I understood correctly that they do.
If I understand correctly, once you have booted the cloned drive, simply removing the offending code from the boot area won't help. The problem is now in the drive's firmware.
@johnsfine: Wow, looks like you're right. I found this forum post: http://forum.hddguru.com/disk-resize...nis-t6774.html , which suggested I use some software called HDAT2 (http://www.hdat2.com/) to reset my HPA LBA mode, whatever that is. As soon as I booted into HDAT2 and went into the Set Max HPA menu, there was a big red sign telling me that whatever setting was to be changed was set so that I was missing 240GB from my drive.
I followed the instructions on the FAQ (Q6 at http://www.hdat2.com/hdat2_faq.html), setting LBA first to 24-bit, shutting down, then setting it to 48-bit, and when I rebooted into Linux, the drive showed up as 320GB!
This is so strange. I'm going to try cloning the drive again (this time without the Dell support partition), and I'll report back on my success. Until then, thanks a lot, johnsfine.
Is the problem code in the Dell support partition?
I thought the problem code was in the rest of the first cylinder where the main body of boot sector viruses normally go (after the MBR, but before the first partition).
If you can install a standard Windows MBR (there is a program to do that on any Windows CD) it should be better to clone the NTFS partition, rather than the drive, so you don't clone whatever is in the first cylinder. When I did something similar, I first used Linux tools to create a target partition just slightly larger than the source NTFS. Then used Linux tools to clone the NTFS partition then grow it to the real desired size. Then use the Windows CD to repair the Windows boot and all should be healthy.
I didn't want to try for a perfect partition size match before cloning, because cylinder rounding might make the target slightly smaller that the source, which would be a serious problem. Cloning to a target that is a bit too big gives you a file system that is too small for its partition, which causes problems (for Windows chkdsk later) if left that way and is surprisingly hard to directly fix. But the Linux code for growing an NTFS partition seems to grow the partition to the new size, then grow the contained filesystem to the new size, without caring if the filesystem started at an incompatible size with the partition. So by growing it after cloning, the size mismatch from before cloning stops mattering.
BTW, I'm also curious about your research process to find a relevant thread. I unfortunately gave you only a concept, not any keywords or phrases that would suggest an easy google search. I also can't think of any good phrases for a search based on your original symptoms. So what search led you to a useful thread?
(First time Google Search History has ever been useful.) I searched for "Dell cloned hard drive flashes firmware". The forum post's title, "disk resized from 120gb to 60gb after cloning with acronis" caught my eye. I think I was just really lucky with that query.
I tried cloning just the NTFS partition, but Windows refused to boot, giving me a really vague error message (which I nevertheless neglected to write down). My guess is that Windows was expecting to be on partition 1 rather than partition 0. I'm considering making a dummy partition in front of my main partition to see if that solves the problem.
Perhaps I'll also zero out the first track of the disk, in case any drive-reconfiguring software is still lurking there.
I have some schoolwork I need to work on, so I might not be back to report my success terrifically soon. But I'll let you know how it goes.
Another option for what you just did, might be to use Clonezilla.. it's got a bit more intelligence than straight gparted / DD, and can be set to copy the data portions only, rather than all the slack space as well. Clonezilla shoudl also be able to clone between different sized partitions (smaller-to-larger)
Clonezilla imaged both the 'utility' partition, and the 'OS' partition from my Latitude E6500 to image files on an external USB HD..
I'll be going the other way tomorrow, when the replacement HD for the laptop shows up.
partimage was unable to see the Har Drive in the laptop when I tried using it to clone the system. Guess my hardware is too new for that Live CD imaging program.
honestly, thanks so much for this, i think this is what just happened to my machine... I have a 80 GB that I cloned and resized it to 320 in ghost everything worked fine for months until the other day I bought a usb enclosure and though to my self let me delete all my work stuff off there and make it a bootable USB HD which all my games and stuff are stored when on the road.
Anyways, after trying to boot to it, it failed with a stop 7 because it's trying to boot off sata instead of USB... Anyways, I unplugged it and tried to boot off the 320gb internally and now it thinks it's a 80 GB... I was scathing my head for so long thinking how the hell that could happen.
I think I now found my answer, I'm going to try to find a windows tool to fix the sizing issue.
I was similarly mystified by what went on when I cloned a 100GB disk to a new 320GB disk for my Dell using Acronis even after fixing it with HDAT2
-- to preserve the Dell recovery, I cloned the disk with Acronis manual as-is method
-- the hard drive shrank from 320GB to ~92GB
-- whenever I changed SET MAX ADDRESS with HDAT2 back to 320GB, it would reset to the original size when I booted to Windows
-- Dell embeds some facility in the MBR of it's hard drives that sets a user limit on the SET MAX ADDRESS less than the NATIVE MAX ADDRESS
-- Acronis COPIED the Dell MBR to the new disk -- reducing it's size with a HPA -- hidden protected area
-- Dell hard drives have 3 partitions --
(1) an upfront mini- boot partition,
(2) the Windows partition and
(3) a hidden CP/M recovery restore partition
-- Windows expects to boot from the second partition on the disk
The solution ... uses two CD booted utilities
-- Get ULTIMATE BOOT CD ... one of the disk Boot utilities can restore a standard MBR
-- Get HDAT2 and reset the SET MAX ADDRESS ... this is done in two steps, two boots. First use 28 bit addressing to reset the max to 137GB ... reboot ... then use 48 bit addressing to reset to 320GB
-- the next depends on whether you want to preserve the Dell restore / recovery partition ... this partition (#3) appears unmoveable by Partition magic and other partitioning utilities on ULTIMATE BOOT CD ... so ...
-- (a) create a DATA partition in the recovered space that will become a new Windows "drive" OR
-- (b) delete the dell recovery and resize the primary Windows partition
I'm sure there are other options to remove the first hidden Dell partition and reseting Windows Boot.ini to boot from the first partition, etc. etc.
Any ideas on how to validly move the "unmoveable" Dell Recovery partition?