Almost...

[swestrup]

I spent the day trying to downgrade my main Linux box from 500 GB to 200 GB, since I want the 500 GB for my fileserver / PVR and I've only been using 150 GB of it so far.

This turned out to be much more complicated than expected, having to do with the fact that the 200GB drive would be the 3rd PATA device in a machine that only has 1 IDE controller. I thought I could just use a Promise Ultra66 card I inherited from pphaneuf but it doesn't work in this machine (although it works fine in the machine I took it out of).

I eventually decided to do without my removable IDE drive tray for now, so I took it out and put the 200GB drive in its place. Then I booted up with a LiveCD. Or, that is, I tried. True to form, 5 out of 6 live cd's failed to successfully initialize my screen at all. This, I find, is typical. When it comes to X config, debian-based distros usually guess wrong. Finally my Debain Lenny Install disk booted into a usable state.

I then dd-ed the first 200 GB from the 500 GB drive onto the 200 GB drive, (which took just over 3 hours) and I was hoping I was all set. The plan at that point was to fix the partition table on the 200 GB so it no longer referred to an unused partition larger than it was, and then to mount the copy of the boot and main partitions, go into a chroot, re-grub and see if the sucker would boot.

Well, the first problem was that the live CD I was using doesn't support LVM. Fine, I booted up my regular system since it DOES support LVM, but of course then LVM complained that the volume groups on the new drive had identical names and uuid's to the ones that were already mounted, and refused to let me do anything with any of them. Honestly, I should have anticipated this, but didn't.

As a wild experiment, I rebooted with the 500 GB disabled to see if I could boot from the other. It got as far as trying to mount VolGroup00, and died complaining that it couldn't find it. Not sure why, since it had no trouble finding multiple copies earlier...

Anyway, I have officially give up for the night. I had hoped to manage this simple task in a single day, but its clearly not to be. Tomorrow when I'm not so sleepy I'll see if I can figure out the simplest and fastest way to fix things without having to re-copy partitions.

Comments

[skjalm.livejournal.com]

Using dd to transfer file systems is doable, but is (in my experience) dangerous at best as there is no guarantee that the data is physically located in the beginning of the disk.

There are various ways of doing this, but my favourite is to repartition the new disk as I want it to be and then mount each partition somewhere suitable and copying the files with find and cpio:

mount NEWBOOTPARTITION /mnt/tmp
cd /boot
find . -xdev | cpio -pm /mnt/tmp
umount /mnt/tmp
mount NEWROOTPARTITION /mnt/tmp
cd /
find . -xdev | cpio -pm /mnt/tmp
(and so on for other partitions)

This has worked well for me in the past and while there may be faster/better solutions I tend to go for the "if it works don't fix it" approach when it comes to things like this. It also has the advantage that you can copy to different file system types and to raid or lvm devices if you should want to.

[pphaneuf.livejournal.com]

This maneuver could work, if he ext2resize'd it or something similar, but truncating the filesystem? Whoa. If the filesystem is Reiser and that works, I'd recommend buying a lottery ticket immediately!

I use a variant of skjalm's method, although I prefer not to overwrite a working system with another one, but rather doing this from a live CD or something like that (the best is one of those that are designed for recovery, they don't bother with X, and cram it with tools for every single filesystem and logical volume manager setups you could possibly think of), and mounting both disks from there.

I also often take the opportunity to install a fresh system, as I'm usually careful to keep as much as possible under /home (symlinking from various places as needed, or having a Subversion repository under /home for the configuration files), but if you've got a tricky system that works, just cpio the whole thing...

[skjalm.livejournal.com]

I usually don't overwrite the system that's actually booted, but sometimes copy a running system to another disk. It's bad, I know, but it's actually been several years since I did that and back then I didn't have a (good) live cd to use for it.

Installing a fresh system can indeed be a very good thing as you can get rid of a lot of inherited annoyances - and it's a great way to check if you actually know what services you're running and how they're configured ;)

[swestrup]

I would prefer to use a livecd as well, but I've had horrible experiences with them. Besides, in order to be able to re-grub the hard drive when I'm done, I need a live cd that A) can run 64-bit apps, B) has LVM support. So far, I haven't found one.

[swestrup]

And I'm not truncating any filesystems. I'm just truncating the disk. The partitions will be transfered intact. Its just one unused partition that got truncated. I'm also not using Reiser on this machine.

I used Reiser on my mail server, and once I've solved some problems with its kernel (a project for another day) it'll probably get converted to ext3 (or 4) or xfs.

[swestrup]

As I'm rather new to this whole linux-on-the-desktop thing, I would prefer NOT to have to reinstall or reconfigure anything. That's why I chose the dd route.

[pphaneuf.livejournal.com]

LVM is pretty common (unless you mean pre-lvm2?), but why do you need to run 64-bit apps? It's a rescue CD, you only need to be able to run the rescue tools, no?

[swestrup]

Is it possible for a 32-bit grub to set things up so a 64-bit grub can boot?

And even if so, the methods I know for re-grubbing all require you to mount the drive to grub, chroot to the drive's mount point and then run some apps. At that point you're using the rescue disk kernel to run native apps on your to-be-grubbed drive. If the kernel is 32-bit and my apps are all 64-bit, I won't even be able to ls.

Or is there something fundamentally wrong with my understanding?

[swestrup]

Oh, and none of the rescue discs I have, that boot, have LVM2.

[pphaneuf.livejournal.com]

You might have an easier time setting up the partitions the way you want them, and then dd'ing a partition at a time rather than the whole disk. Still, I agree with skjalm on this, dd'ing disks around is kind of iffy...

[swestrup]

Yeah. My hope was that I could swap drives and have it 'just work', but this seems to not quite work.

It may just be the lvm.conf file in the initrd of the boot partition needs tweaking...

[pphaneuf.livejournal.com]

I see LVM2 right here on this one, on a random one that has a package list: http://www.sysresccd.org/Detailed-packages-list

It might not be super-popular on the "random CDs that happen to be bootable Linux systems", but in the specific "my Linux system is borked, here's a CD that will help me fix it" genre, I'd be surprised if it weren't.

[pphaneuf.livejournal.com]

I don't think there's such a thing as a 64-bit grub (there's a few bits in assembly in there, and it just wouldn't be useful, other than for a new way to screw oneself over), although you're right that the various utilities could be compiled for 64-bit (and that wouldn't work with a 32-bit only system).

On my 64-bit Ubuntu system, they were very clever, and knew Bad Things (tm) could happen, so the "grub" utility is actually 32-bit (and statically linked, too). grub-install also sports a --root-directory to tell it where to work, so you can use the one bundled with the rescue live CD while pointing it at the root of the filesystem you need to fix. I didn't check, but I'd suspect that the core-utils (like "ls") on a 64-bit system would be 32-bit also. I'm not above copying a busybox in there before chrooting either. ;-)

[swestrup]

Hmm. Hadn't thought of the busybox idea. I should try that.

[pphaneuf.livejournal.com]

Or just whatever plain old binaries from the rescue live CD that you need. Heck, "mount -o bind /bin /foobar/bin" if you have to!