Topic: HDD Upgrade Glitch

Hey guys,

I just moved my #! system onto a larger disk, but for some reason it still thinks it's on the smaller one. Any ideas on how I can convince it otherwise?

Thanks,

Scarab

Re: HDD Upgrade Glitch

Try booting from a #! Live CD and running Gparted

gksu gparted

You'll see the partition layout of your hard drive. If there is empty space to the right or left, you can drag the #! partition to fill it.

I hope it's as easy as that; if you run into any complications, post back! smile

Re: HDD Upgrade Glitch

yep, should just be a matter of expanding the partition to however big you want it.

just call me...
~FSM~

Re: HDD Upgrade Glitch

Thanks for the tips guys, but it seems to be a bit more complicated than that.
When booted from a live CD, gparted reports the correct total disk size as 18.63GiB, however it claims that 16.69GiB have been used, even though this is a dd copy from a 7.33GiB system. When booted natively, Conky reports that 5.39 of 7.33GiB have been used, and PCMan tells pretty much the same story. I tried copying a 5GiB file from an external disk to see if it was just the utilities that were messing up, but it ran out of room. Needless to say, this has me rather confused.
I don't know if this makes a difference in troubleshooting, but this is on a dual-booted (formerly triple-booted) late-2008 Macbook Pro using the rEFIt boot loader.

Re: HDD Upgrade Glitch

You may find the following command useful for scoping out your partition scheme:

sudo fdisk -l

Copy & paste the results back here if you want us to take a look.

Re: HDD Upgrade Glitch

Snow,
Here are the results:

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd6ddd6d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          26      204819+  ee  GPT
/dev/sda2              26       58338   468388352   af  Unknown
/dev/sda3   *       58354       60785    19531248   af  Unknown

Re: HDD Upgrade Glitch

Whoops, I think I told you the wrong command, the one that tells you the % free is actually:

df -h

My bad. smile

I am a little concerned by your fdisk -l output however. My Linux partitions show up as ID 83 and System Linux, for example (I snipped my Windows partitions for clarity):

   Device Boot      Start         End      Blocks   Id  System
/dev/sda5            9787       40181   244147806   83  Linux
/dev/sda6            5717        9786    32692243+  83  Linux
/dev/sda7           40182       53801   109402618+  83  Linux

However, I should point out I am not a Mac expert smile so maybe your result of Id af/System Unknown is normal for a Mac?

Re: HDD Upgrade Glitch

Huh...
Well hopefully the ID won't be an issue.

Here is the df -h output:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             7.4G  5.4G  1.6G  78% /
tmpfs                 1.5G     0  1.5G   0% /lib/init/rw
varrun                1.5G  116K  1.5G   1% /var/run
varlock               1.5G     0  1.5G   0% /var/lock
udev                  1.5G  160K  1.5G   1% /dev
tmpfs                 1.5G  196K  1.5G   1% /dev/shm
lrm                   1.5G  2.2M  1.5G   1% /lib/modules/2.6.28-13-generic/volatile

If you haven't guessed by now, I'm a relative noob. I have no idea what any of the directories below /dev/... are. The seem to be taking up a good chunk of space though.

Re: HDD Upgrade Glitch

So (1.5g * 6) + 7.4g = 16.4g, which is roughly what gparted reports as used (16.69g). But only 7.4 is available for you to use; the rest is tied up in these 1.5g "chunks."

I am stumped and think we need a 2nd opinion. smile

While we are waiting for someone else to read this, can you back up and explain the method used to clone the partition, perhaps that will shed some light...

Re: HDD Upgrade Glitch

Of course. When the system was triple-booted (OS X, #!, Windows 7) I made a bit-for-bit dd copy of the hdd via the OS X terminal onto an external firewire drive as one of several backups. I recently imported the windows partition into a vm, wiped the entire drive and restored it from the Mac's Time Machine utility. At this point OS X occupied all 500GB. I then created a 20GB partition using the OS X disk utility and used dd to copy the old linux partition (~8GB) from the firewire drive to the new one. That's when I noticed the problem and posted this thread. I hope this causes some lightbulbs to go off somewhere smile

Re: HDD Upgrade Glitch

That is awesome; I think you are totally a CrunchBanger at heart (we love all kinds of crazy computer projects), and you'll fit right in on these forums!

You said #! is working OK (except for the missing space), what about Mac and Windows? I have never tried importing Windows to a VM, was the project a success?

Sorry I have nothing specific for you at the moment, let me think on it a while. smile

Re: HDD Upgrade Glitch

Haha, thanks man! I like this place already. Don't get too excited about the VM import though. I used the Parallels import manager because I don't quite know enough about how OS's interface with their storage devices yet. One of these days... But to answer your question, yes it works tongue