Hi Martin, As luck would have it, I did just that this weekend. Except that my system used lvm for all partitions, which massively simplified the procedure for me.
Martin McCormick (mar...@x.it.okstate.edu on 2011-08-14 21:32 -0500): > I have a 10-gigabyte hard drive that sounds like a 747 > just before takeoff so the time has come to replace it. I > replaced it with a 16-gigabyte SATA flash drive and IDE adaptor > as the system it runs on is a little too old to handle a large > drive. Flash drives have different requirements on alignment and block size than spinning disks, because of their limited erase cycles. You're probably better off creating a new partition table. Then again, the jury's still out on whether drive longevity is a real issue. > > If I use dd to copy the 10-gig drive over to the new > drive as in: > > dd if=/dev/hda of=/dev/hdb bs=20M Sure, but then you'll run into issues with partitioning. You can only resize the last partition on the disk. How many partitions were on the original disk? > it works when I remove the old screamer drive, change the jumper > on the new drive to Master and boot but this is not very > efficient as it wastes almost 6 gigs of drive. > > What I tried to do was to format /dev/hdb with hdb1 > being around 15GB and then /dev/hdb2 being extended and holding > hdb5 marked as swap just like /dev/hda. /dev/hdb1 is also set to > bootable and shows up as such when using fdisk /dev/hdb and > then the p command. # dd if=/dev/hda of=/dev/hdb bs=512 count=1 or # sfdisk -d /dev/hda | sfdisk /dev/hdb would only copy the partition table to the new disk (assuming MBR partitioning of course). Then you can use any other partitioning tool to resize the partitions without caring for the data just yet. Second: if you're using less than 4 partitions, there is no need for an extended partition. Just using hdb1 and hdb2 will be fine. > The rsync command tries to copy everything on the old > disk except /proc and it also fails to copy those files which > probably never stay around such as timer values and other > volital information so /dev and everything else get copied. For 1:1 pristine copies, I recommend using just tar: # tar cv --one-file-system . | tar xC /mnt will recreate the current directory in /mnt. Assuming you have already mounted your new partition in /mnt and your PWD is /, that will transfer your complete root filesystem to the new disk, excluding any other mounts (proc, sys, dev, tmp). > > When I boot the efficiently-built system, it does start > to boot and then hangs. At a guess: it hangs at either "LILO" or "GRUB loading..." ? You probably need to reinstall your bootloader after changing partitions. But you did not give the error message, nor which bootloader you were using (lilo, grub-legacy, grub-pc?). Like another respondent has said, if you did any formatting (mkfs.*) then you might need to change /etc/fstab accordingly. > Is there a way to copy the working file system to a > larger drive such that the new drive will also boot? There is. But what you need to do differently depends on where it failed and what the error message was. > I even tried to use the dd method and then tune2fs but I > either did something wrong or this can't work because I still > had only a 9.6G file system when all was said and done. tune2fs will not resize your partitions, you need a partitioning tool for that (followed by resize2fs). And if you did the dd-per-partition, then only resize2fs should suffice. Regards, Arno -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110816001048.733c3...@neminis.loos.site
