SlackwareThis Forum is for the discussion of Slackware 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.
I right now have a 16GB SSD in my netbook with Slackware installed on it. I have /dev/sda partitioned to the following:
/dev/sda2 (Slackware installation)
I have bought a new 32GB SSD from newegg which I will be installing and would like to clone my Slackware installation so that i can copy it over to a USB, then install my harddrive and install it from USB. This is what I'm thinking of doing but not sure exactly what to do:
1) sda is my harddrive, sdb is my usb. So i start by copying my current installation to my USB so that later I can transfer it to my new hard drive.
dd if=/dev/sda of=/dev/sdb
2) From here i was thinking of installing the new harddrive, then booting a live usb stick of Damn Small Linux or some type of Live USB. Then fdisk the new harddrive by partitioning the swap and sda2 partition, and then dd from my slackware usb i made earlier to the new harddrive. Or should I just dd my slackware USB and not even fdisk? Also will I need to install LILO again somehow? Not sure honestly how to do this the best way while keeping my slackware installation perfectly like it is, i don't want to lose my configurations and tuned applications I have done.
You try to use the backup utility fsarchiver. This is a CLI tool which archives a whole partition into a single compressed file with the added benefit that it can be restored to a bigger partition that the original.
The commands are these (as root):
save only one filesystem (/dev/sda1) to an archive:
fsarchiver savefs /data/myarchive1.fsa /dev/sda1
save two filesystems (/dev/sda1 and /dev/sdb1) to an archive:
fsarchiver savefs /data/myarchive2.fsa /dev/sda1 /dev/sdb1
restore the first filesystem from an archive (first = number 0):
fsarchiver restfs /data/myarchive2.fsa id=0,dest=/dev/sda1
restore the second filesystem from an archive (second = number 1):
fsarchiver restfs /data/myarchive2.fsa id=1,dest=/dev/sdb1
restore two filesystems from an archive (number 0 and 1):
fsarchiver restfs /data/arch2.fsa id=0,dest=/dev/sda1 id=1,dest=/dev/sdb1
restore a filesystem from an archive and convert it to reiserfs:
fsarchiver restfs /data/myarchive1.fsa id=0,dest=/dev/sda1,mkfs=reiserfs
save the contents of /usr/src/linux to an archive (similar to tar):
fsarchiver savedir /data/linux-sources.fsa /usr/src/linux
save a /dev/sda1 to an archive split into volumes of 680MB:
fsarchiver savefs -s 680 /data/myarchive1.fsa /dev/sda1
It isn’t good idea to use dd for that purposes. It copies everything including the boot sector and the partition table. As a result your new 32 GB SSD would look like 16 GB SSD. The minor problem are bad sectors or bad blocks. If the old drive has them dd will copy them to the new drive as is.
I use for that purposes the following procedure:
1. I boot the machine including the source drive using USB stick or CD/DVD including some live distribution (for a few last times I used USB stick with Porteus).
2. I mount the root partition of the source drive in /mnt directory.
3. I use the commands:
tar czf /the path/to/the_target_file.tgz *
in order to store the root tree in the archive.
4. I move the_target_file.tgz to the USB stick.
(In your case you have to switch the drive after the step 4. and before the step 5.)
5. I boot the machine including the destination drive using the same USB stick or CD/DVD.
6. I prepare the partition table suitable for the destination drive.
7. I prepare file systems using mkreiserfs (for ReiserFS) and mkswap.
8. I mount the root partition of the destination drive in /mnt directory.
9. I use the commands:
tar xzf /the path/to/the_target_file.tgz
in order to restore the root tree on the destination partition.
10. I chroot to the /mnt directory.
11. I restore LILO using lilo command.
12. I reboot the machine.
I hope I didn’t passed over some important step. The above description is a shortened one so it isn’t fool proof. After the reboot some tuning of the system is necessary in some cases.
I do have a similar situation sometimes. My solution is to 1) backup my entire system to a local FTP server using Ghost4Linux (raw mode) 2) put the new hard disk in the machine 3) restore it with Ghost4Linux, still in raw mode, and finally 4) load PartedLive and correct the partition size for the disk, which is a simple drag-and-drop operation. Works great, but don't do it without backing up your data first.
It isnít good idea to use dd for that purposes. It copies everything including the boot sector and the partition table. As a result your new 32 GB SSD would look like 16 GB SSD. The minor problem are bad sectors or bad blocks. If the old drive has them dd will copy them to the new drive as is.
I second that. Changing disk drives is also a good opportunity to optimize your partition scheme and to start with fresh filesystems. A fresh filesystem allows you to tune parameters more easily. You can optimize your system based on your experience with the previous setup (for instance: optimize the inode count, or use new filesystem features).
Another aspect is the evolution of filesystems, that is kernel and user space, and on-disk-structures.