Clone internal HDD to new SSD

Multi tool use
I recently installed an SSD into my machine. The machine itself is a Lenovo thinkpad W520, and it previously had an internal HDD. I moved the internal HDD into an expansion bay (replacing the CD-ROM), and put the new SSD into the internal bay.
The problem I'm having is that I have my Ubuntu configuration EXACTLY the way I want it - I originally spent many hours configuring it to get it to the way it is now. I'd rather not do this again. But, I'd also like the boot-up gains I would get from the OS being on the SSD.
So, what I'd like to do is clone my Ubuntu partition onto the SSD. The catch is that the standard HDD is significantly bigger than the SSD. And it has a windows partition that I don't need on the SSD (I never use Windows, so if it boots off of the other hard drive, that's fine). The layout of my hard drives are as follows:
/dev/sda (SSD):
Model: ATA M4-CT256M4SSD2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 147GB 147GB primary ext4 boot
/dev/sdb (HDD):
Model: ATA ST9500420AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 1259MB 1258MB primary ntfs boot
2 1259MB 269GB 268GB primary ntfs
4 269GB 483GB 214GB extended
5 269GB 416GB 147GB logical ext4
7 416GB 475GB 58.9GB logical linux-swap(v1)
6 475GB 483GB 8470MB logical
3 483GB 500GB 16.8GB primary ntfs
What I've tried so far:
1) Resizing the partitions /dev/sdb5 and /dev/sda1 to be the same size.
2) Booting into Ubuntu 11.04 (from /dev/sdb5) and running dd if=/dev/sdb5 of=/dev/sda1 (of course this causes problems with booting, so I had to reinstall grub.. I can get it to boot, but then I have problems with initrd not finding some files ... presumably it can't load some partitions I think).
Now, I think those two steps are the wrong approach, because it will clone /dev/sdb5 EXACTLY - including references in fstab which point to the wrong hard drive. I'm not sure exactly how to rectify this. I could install Ubuntu 11.04 onto the SSD, then try and copy over all of my configurations, but I'm concerned that I'm going to lose something, or that I'm going to overwrite something like fstab that points back to the original hard drive.
Note that currently, I can still boot from the HDD, so it's not imperative that I get this figured out right away, but I do want it to be exactly how it is right now, so that I can maintain my current level of productivity (it's a work laptop).
Suggestions on how I might be able to overcome this difficulty?
Thanks in advance!
11.04 boot partitioning configuration ssd
add a comment |
I recently installed an SSD into my machine. The machine itself is a Lenovo thinkpad W520, and it previously had an internal HDD. I moved the internal HDD into an expansion bay (replacing the CD-ROM), and put the new SSD into the internal bay.
The problem I'm having is that I have my Ubuntu configuration EXACTLY the way I want it - I originally spent many hours configuring it to get it to the way it is now. I'd rather not do this again. But, I'd also like the boot-up gains I would get from the OS being on the SSD.
So, what I'd like to do is clone my Ubuntu partition onto the SSD. The catch is that the standard HDD is significantly bigger than the SSD. And it has a windows partition that I don't need on the SSD (I never use Windows, so if it boots off of the other hard drive, that's fine). The layout of my hard drives are as follows:
/dev/sda (SSD):
Model: ATA M4-CT256M4SSD2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 147GB 147GB primary ext4 boot
/dev/sdb (HDD):
Model: ATA ST9500420AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 1259MB 1258MB primary ntfs boot
2 1259MB 269GB 268GB primary ntfs
4 269GB 483GB 214GB extended
5 269GB 416GB 147GB logical ext4
7 416GB 475GB 58.9GB logical linux-swap(v1)
6 475GB 483GB 8470MB logical
3 483GB 500GB 16.8GB primary ntfs
What I've tried so far:
1) Resizing the partitions /dev/sdb5 and /dev/sda1 to be the same size.
2) Booting into Ubuntu 11.04 (from /dev/sdb5) and running dd if=/dev/sdb5 of=/dev/sda1 (of course this causes problems with booting, so I had to reinstall grub.. I can get it to boot, but then I have problems with initrd not finding some files ... presumably it can't load some partitions I think).
Now, I think those two steps are the wrong approach, because it will clone /dev/sdb5 EXACTLY - including references in fstab which point to the wrong hard drive. I'm not sure exactly how to rectify this. I could install Ubuntu 11.04 onto the SSD, then try and copy over all of my configurations, but I'm concerned that I'm going to lose something, or that I'm going to overwrite something like fstab that points back to the original hard drive.
Note that currently, I can still boot from the HDD, so it's not imperative that I get this figured out right away, but I do want it to be exactly how it is right now, so that I can maintain my current level of productivity (it's a work laptop).
Suggestions on how I might be able to overcome this difficulty?
Thanks in advance!
11.04 boot partitioning configuration ssd
add a comment |
I recently installed an SSD into my machine. The machine itself is a Lenovo thinkpad W520, and it previously had an internal HDD. I moved the internal HDD into an expansion bay (replacing the CD-ROM), and put the new SSD into the internal bay.
The problem I'm having is that I have my Ubuntu configuration EXACTLY the way I want it - I originally spent many hours configuring it to get it to the way it is now. I'd rather not do this again. But, I'd also like the boot-up gains I would get from the OS being on the SSD.
So, what I'd like to do is clone my Ubuntu partition onto the SSD. The catch is that the standard HDD is significantly bigger than the SSD. And it has a windows partition that I don't need on the SSD (I never use Windows, so if it boots off of the other hard drive, that's fine). The layout of my hard drives are as follows:
/dev/sda (SSD):
Model: ATA M4-CT256M4SSD2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 147GB 147GB primary ext4 boot
/dev/sdb (HDD):
Model: ATA ST9500420AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 1259MB 1258MB primary ntfs boot
2 1259MB 269GB 268GB primary ntfs
4 269GB 483GB 214GB extended
5 269GB 416GB 147GB logical ext4
7 416GB 475GB 58.9GB logical linux-swap(v1)
6 475GB 483GB 8470MB logical
3 483GB 500GB 16.8GB primary ntfs
What I've tried so far:
1) Resizing the partitions /dev/sdb5 and /dev/sda1 to be the same size.
2) Booting into Ubuntu 11.04 (from /dev/sdb5) and running dd if=/dev/sdb5 of=/dev/sda1 (of course this causes problems with booting, so I had to reinstall grub.. I can get it to boot, but then I have problems with initrd not finding some files ... presumably it can't load some partitions I think).
Now, I think those two steps are the wrong approach, because it will clone /dev/sdb5 EXACTLY - including references in fstab which point to the wrong hard drive. I'm not sure exactly how to rectify this. I could install Ubuntu 11.04 onto the SSD, then try and copy over all of my configurations, but I'm concerned that I'm going to lose something, or that I'm going to overwrite something like fstab that points back to the original hard drive.
Note that currently, I can still boot from the HDD, so it's not imperative that I get this figured out right away, but I do want it to be exactly how it is right now, so that I can maintain my current level of productivity (it's a work laptop).
Suggestions on how I might be able to overcome this difficulty?
Thanks in advance!
11.04 boot partitioning configuration ssd
I recently installed an SSD into my machine. The machine itself is a Lenovo thinkpad W520, and it previously had an internal HDD. I moved the internal HDD into an expansion bay (replacing the CD-ROM), and put the new SSD into the internal bay.
The problem I'm having is that I have my Ubuntu configuration EXACTLY the way I want it - I originally spent many hours configuring it to get it to the way it is now. I'd rather not do this again. But, I'd also like the boot-up gains I would get from the OS being on the SSD.
So, what I'd like to do is clone my Ubuntu partition onto the SSD. The catch is that the standard HDD is significantly bigger than the SSD. And it has a windows partition that I don't need on the SSD (I never use Windows, so if it boots off of the other hard drive, that's fine). The layout of my hard drives are as follows:
/dev/sda (SSD):
Model: ATA M4-CT256M4SSD2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 147GB 147GB primary ext4 boot
/dev/sdb (HDD):
Model: ATA ST9500420AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 1259MB 1258MB primary ntfs boot
2 1259MB 269GB 268GB primary ntfs
4 269GB 483GB 214GB extended
5 269GB 416GB 147GB logical ext4
7 416GB 475GB 58.9GB logical linux-swap(v1)
6 475GB 483GB 8470MB logical
3 483GB 500GB 16.8GB primary ntfs
What I've tried so far:
1) Resizing the partitions /dev/sdb5 and /dev/sda1 to be the same size.
2) Booting into Ubuntu 11.04 (from /dev/sdb5) and running dd if=/dev/sdb5 of=/dev/sda1 (of course this causes problems with booting, so I had to reinstall grub.. I can get it to boot, but then I have problems with initrd not finding some files ... presumably it can't load some partitions I think).
Now, I think those two steps are the wrong approach, because it will clone /dev/sdb5 EXACTLY - including references in fstab which point to the wrong hard drive. I'm not sure exactly how to rectify this. I could install Ubuntu 11.04 onto the SSD, then try and copy over all of my configurations, but I'm concerned that I'm going to lose something, or that I'm going to overwrite something like fstab that points back to the original hard drive.
Note that currently, I can still boot from the HDD, so it's not imperative that I get this figured out right away, but I do want it to be exactly how it is right now, so that I can maintain my current level of productivity (it's a work laptop).
Suggestions on how I might be able to overcome this difficulty?
Thanks in advance!
11.04 boot partitioning configuration ssd
11.04 boot partitioning configuration ssd
asked Apr 4 '12 at 17:42


jwir3jwir3
1621416
1621416
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
There is more than one way to accomplish getting your old system onto a new drive, but you didn't really ask it that way, you asked for how to clone the system.
I would just use gparted, myself, from the live CD so neither partition is mounted. You can shrink the original partition to the size you want it to be on the SSD, then copy and paste the partition to the new drive. If I remember correctly, this will reuse the same UUID, but you can change that on one or the other partition afterwards. The command for this is sudo tune2fs -U random /dev/sdb5
assigns UUID for sdb5.
If you don't want to change the old system, and if you want to keep it mounted for a while, you could change the UUID for the SSD partition, and edit your fstab. It's actually not hard at all, and is something you should learn about. It's pretty self-explanatory for someone with the knowledge you already seem to have. Once you assign a new UUID, you can see all of them with this command: sudo blkid -c /dev/null
- the parameter -c specifies the cache file, and /dev/null means don't use a cache, so you always get any changes right away. I always use that form, and can see no downside unless you have a lot of partitions.
Once you get the UUID, you can copy and paste it over the old one in /etc/fstab using gedit or whatever text editor you prefer.
Personally, though, rather than taking time to resize the partition first, I'd simply copy the old install to the new disk. If you don't know how to install GRUB to the mbr, you might want to first install a base Ubuntu, then back up /etc/fstab, copy the old install over it, and then copy the fstab from the new install so it has only the correct entries.
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.
– jwir3
Apr 8 '12 at 2:29
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
|
show 5 more comments
Boot from the livecd, mount both drives, then just copy the files over with sudo cp -ax /media/source /media/dest
. Edit the /etc/fstab on the destination to point to the correct UUID ( look up with blkid
), and reinstall grub.
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as runninggrub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)
– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
add a comment |
I would suggest avoiding to use dd if=/dev/sdb5 of=/dev/sda1
if your system is running from /dev/sdb5
itself (and presumably not mounted read-only).
Another way to copy partitions across is to boot from the live CD (or USB) and start GParted. You can use Ctrl+C/Ctrl+V to copy partitions from one disk to another.
One the copy is made (and perhaps after reboot is the partition table needs to be refreshed), still from the live CD, mount your new root partition using a Terminal:
sudo mount /dev/sda1 /mnt
Then, edit /mnt/etc/fstab
to point to the correct locations.
if youdd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).
– Alecz
Oct 18 '17 at 20:37
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f118927%2fclone-internal-hdd-to-new-ssd%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is more than one way to accomplish getting your old system onto a new drive, but you didn't really ask it that way, you asked for how to clone the system.
I would just use gparted, myself, from the live CD so neither partition is mounted. You can shrink the original partition to the size you want it to be on the SSD, then copy and paste the partition to the new drive. If I remember correctly, this will reuse the same UUID, but you can change that on one or the other partition afterwards. The command for this is sudo tune2fs -U random /dev/sdb5
assigns UUID for sdb5.
If you don't want to change the old system, and if you want to keep it mounted for a while, you could change the UUID for the SSD partition, and edit your fstab. It's actually not hard at all, and is something you should learn about. It's pretty self-explanatory for someone with the knowledge you already seem to have. Once you assign a new UUID, you can see all of them with this command: sudo blkid -c /dev/null
- the parameter -c specifies the cache file, and /dev/null means don't use a cache, so you always get any changes right away. I always use that form, and can see no downside unless you have a lot of partitions.
Once you get the UUID, you can copy and paste it over the old one in /etc/fstab using gedit or whatever text editor you prefer.
Personally, though, rather than taking time to resize the partition first, I'd simply copy the old install to the new disk. If you don't know how to install GRUB to the mbr, you might want to first install a base Ubuntu, then back up /etc/fstab, copy the old install over it, and then copy the fstab from the new install so it has only the correct entries.
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.
– jwir3
Apr 8 '12 at 2:29
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
|
show 5 more comments
There is more than one way to accomplish getting your old system onto a new drive, but you didn't really ask it that way, you asked for how to clone the system.
I would just use gparted, myself, from the live CD so neither partition is mounted. You can shrink the original partition to the size you want it to be on the SSD, then copy and paste the partition to the new drive. If I remember correctly, this will reuse the same UUID, but you can change that on one or the other partition afterwards. The command for this is sudo tune2fs -U random /dev/sdb5
assigns UUID for sdb5.
If you don't want to change the old system, and if you want to keep it mounted for a while, you could change the UUID for the SSD partition, and edit your fstab. It's actually not hard at all, and is something you should learn about. It's pretty self-explanatory for someone with the knowledge you already seem to have. Once you assign a new UUID, you can see all of them with this command: sudo blkid -c /dev/null
- the parameter -c specifies the cache file, and /dev/null means don't use a cache, so you always get any changes right away. I always use that form, and can see no downside unless you have a lot of partitions.
Once you get the UUID, you can copy and paste it over the old one in /etc/fstab using gedit or whatever text editor you prefer.
Personally, though, rather than taking time to resize the partition first, I'd simply copy the old install to the new disk. If you don't know how to install GRUB to the mbr, you might want to first install a base Ubuntu, then back up /etc/fstab, copy the old install over it, and then copy the fstab from the new install so it has only the correct entries.
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.
– jwir3
Apr 8 '12 at 2:29
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
|
show 5 more comments
There is more than one way to accomplish getting your old system onto a new drive, but you didn't really ask it that way, you asked for how to clone the system.
I would just use gparted, myself, from the live CD so neither partition is mounted. You can shrink the original partition to the size you want it to be on the SSD, then copy and paste the partition to the new drive. If I remember correctly, this will reuse the same UUID, but you can change that on one or the other partition afterwards. The command for this is sudo tune2fs -U random /dev/sdb5
assigns UUID for sdb5.
If you don't want to change the old system, and if you want to keep it mounted for a while, you could change the UUID for the SSD partition, and edit your fstab. It's actually not hard at all, and is something you should learn about. It's pretty self-explanatory for someone with the knowledge you already seem to have. Once you assign a new UUID, you can see all of them with this command: sudo blkid -c /dev/null
- the parameter -c specifies the cache file, and /dev/null means don't use a cache, so you always get any changes right away. I always use that form, and can see no downside unless you have a lot of partitions.
Once you get the UUID, you can copy and paste it over the old one in /etc/fstab using gedit or whatever text editor you prefer.
Personally, though, rather than taking time to resize the partition first, I'd simply copy the old install to the new disk. If you don't know how to install GRUB to the mbr, you might want to first install a base Ubuntu, then back up /etc/fstab, copy the old install over it, and then copy the fstab from the new install so it has only the correct entries.
There is more than one way to accomplish getting your old system onto a new drive, but you didn't really ask it that way, you asked for how to clone the system.
I would just use gparted, myself, from the live CD so neither partition is mounted. You can shrink the original partition to the size you want it to be on the SSD, then copy and paste the partition to the new drive. If I remember correctly, this will reuse the same UUID, but you can change that on one or the other partition afterwards. The command for this is sudo tune2fs -U random /dev/sdb5
assigns UUID for sdb5.
If you don't want to change the old system, and if you want to keep it mounted for a while, you could change the UUID for the SSD partition, and edit your fstab. It's actually not hard at all, and is something you should learn about. It's pretty self-explanatory for someone with the knowledge you already seem to have. Once you assign a new UUID, you can see all of them with this command: sudo blkid -c /dev/null
- the parameter -c specifies the cache file, and /dev/null means don't use a cache, so you always get any changes right away. I always use that form, and can see no downside unless you have a lot of partitions.
Once you get the UUID, you can copy and paste it over the old one in /etc/fstab using gedit or whatever text editor you prefer.
Personally, though, rather than taking time to resize the partition first, I'd simply copy the old install to the new disk. If you don't know how to install GRUB to the mbr, you might want to first install a base Ubuntu, then back up /etc/fstab, copy the old install over it, and then copy the fstab from the new install so it has only the correct entries.
answered Apr 4 '12 at 18:07


Marty FriedMarty Fried
13.4k53847
13.4k53847
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.
– jwir3
Apr 8 '12 at 2:29
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
|
show 5 more comments
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.
– jwir3
Apr 8 '12 at 2:29
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
This is very helpful, thank you. I am going to try it and see if I can get it to work. Then I'll come back and accept the answer or ask you more about it. ;)
– jwir3
Apr 4 '12 at 18:30
1
1
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
I've used the live install CD a lot of times, as it has most everything you need. But the best actual rescue image I've used is System Rescue CD. This bootable CD, also available as USB stick, has fixed GRUB for me a number of times after something (or someone, who shall remain unnamed) wiped it out. It has gparted, grub tools, and everything else you'd want to fix a linux installation, without too much overhead. Is this the type of thing you were asking about?
– Marty Fried
Apr 4 '12 at 21:23
1
1
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
You're welcome, and good luck.
– Marty Fried
Apr 5 '12 at 0:31
1
1
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (
apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.– jwir3
Apr 8 '12 at 2:29
This worked well. One thing I was a bit unsure on was how to configure grub, and, more specifically, that there are very different ways to configure grub legacy vs. grub2. I used the following as reference for grub2, once I installed it (
apt-get install grub2
): dedoimedo.com/computers/grub-2.html I was originally going by a grub2 installation method, when in fact, grub-legacy was installed on my system.– jwir3
Apr 8 '12 at 2:29
1
1
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
Ah, yes, the lovable grub, and it's improved, grub2 (NEW! IMPROVED! NOW EVEN MORE COMPLEX!). Sorry, it's all my fault; I had gotten to fully understand the old grub, so of course, they changed it. Then, when I thought I was getting grub2, they made a few more minor changes, incompatible with the previous version. That's why I suggested the possibility of a base install first, just to get grub set up. But it's a good idea to learn grub, and it's actually not that complicated, really. Did you change over to grub2 now?
– Marty Fried
Apr 8 '12 at 16:44
|
show 5 more comments
Boot from the livecd, mount both drives, then just copy the files over with sudo cp -ax /media/source /media/dest
. Edit the /etc/fstab on the destination to point to the correct UUID ( look up with blkid
), and reinstall grub.
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as runninggrub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)
– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
add a comment |
Boot from the livecd, mount both drives, then just copy the files over with sudo cp -ax /media/source /media/dest
. Edit the /etc/fstab on the destination to point to the correct UUID ( look up with blkid
), and reinstall grub.
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as runninggrub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)
– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
add a comment |
Boot from the livecd, mount both drives, then just copy the files over with sudo cp -ax /media/source /media/dest
. Edit the /etc/fstab on the destination to point to the correct UUID ( look up with blkid
), and reinstall grub.
Boot from the livecd, mount both drives, then just copy the files over with sudo cp -ax /media/source /media/dest
. Edit the /etc/fstab on the destination to point to the correct UUID ( look up with blkid
), and reinstall grub.
answered Apr 4 '12 at 17:49
psusipsusi
31k15087
31k15087
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as runninggrub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)
– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
add a comment |
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as runninggrub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)
– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
That's what I'd do, but it took me forever to get a handle on grub2 - mostly due to the myriads of different methods I read, none of which seemed to be complete. Your post assumes the person is on the same level as you are, or perhaps you simply assume he will ask about the parts that aren't known (which is probably OK). But it's curious that you specified the easiest part, the copy command, and kinda glossed over the harder parts. :)
– Marty Fried
Apr 4 '12 at 18:13
2
2
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as running
grub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)– psusi
Apr 4 '12 at 19:18
@MartyFried, a quick google jumps right to help.ubuntu.com/community/Grub2#Reinstalling_GRUB2, which says it's as simple as running
grub-install --root-directory /mnt /dev/sda
after mounting the Ubuntu partition in /mnt ;)– psusi
Apr 4 '12 at 19:18
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
Ah, I'm glad to hear that they've improved or added to the documentation. It's been a while for me, but when I was trying to get a handle on it, even the official GRUB documentation was not totally correct. Also, there was a version change for GRUB2 that caused it to fail with an obscure error message. But the problem with the Ubuntu forums I used to frequent more is that there is a lot of misinformation repeated until it becomes fact by people who barely know what they are talking about - not everyone, but it's hard to sort out sometimes.
– Marty Fried
Apr 4 '12 at 21:14
add a comment |
I would suggest avoiding to use dd if=/dev/sdb5 of=/dev/sda1
if your system is running from /dev/sdb5
itself (and presumably not mounted read-only).
Another way to copy partitions across is to boot from the live CD (or USB) and start GParted. You can use Ctrl+C/Ctrl+V to copy partitions from one disk to another.
One the copy is made (and perhaps after reboot is the partition table needs to be refreshed), still from the live CD, mount your new root partition using a Terminal:
sudo mount /dev/sda1 /mnt
Then, edit /mnt/etc/fstab
to point to the correct locations.
if youdd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).
– Alecz
Oct 18 '17 at 20:37
add a comment |
I would suggest avoiding to use dd if=/dev/sdb5 of=/dev/sda1
if your system is running from /dev/sdb5
itself (and presumably not mounted read-only).
Another way to copy partitions across is to boot from the live CD (or USB) and start GParted. You can use Ctrl+C/Ctrl+V to copy partitions from one disk to another.
One the copy is made (and perhaps after reboot is the partition table needs to be refreshed), still from the live CD, mount your new root partition using a Terminal:
sudo mount /dev/sda1 /mnt
Then, edit /mnt/etc/fstab
to point to the correct locations.
if youdd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).
– Alecz
Oct 18 '17 at 20:37
add a comment |
I would suggest avoiding to use dd if=/dev/sdb5 of=/dev/sda1
if your system is running from /dev/sdb5
itself (and presumably not mounted read-only).
Another way to copy partitions across is to boot from the live CD (or USB) and start GParted. You can use Ctrl+C/Ctrl+V to copy partitions from one disk to another.
One the copy is made (and perhaps after reboot is the partition table needs to be refreshed), still from the live CD, mount your new root partition using a Terminal:
sudo mount /dev/sda1 /mnt
Then, edit /mnt/etc/fstab
to point to the correct locations.
I would suggest avoiding to use dd if=/dev/sdb5 of=/dev/sda1
if your system is running from /dev/sdb5
itself (and presumably not mounted read-only).
Another way to copy partitions across is to boot from the live CD (or USB) and start GParted. You can use Ctrl+C/Ctrl+V to copy partitions from one disk to another.
One the copy is made (and perhaps after reboot is the partition table needs to be refreshed), still from the live CD, mount your new root partition using a Terminal:
sudo mount /dev/sda1 /mnt
Then, edit /mnt/etc/fstab
to point to the correct locations.
answered Apr 4 '12 at 17:52
BrunoBruno
346110
346110
if youdd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).
– Alecz
Oct 18 '17 at 20:37
add a comment |
if youdd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).
– Alecz
Oct 18 '17 at 20:37
if you
dd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).– Alecz
Oct 18 '17 at 20:37
if you
dd
from the live CD you don't need to edit the fstab provided it uses UUIDs (which it should).– Alecz
Oct 18 '17 at 20:37
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f118927%2fclone-internal-hdd-to-new-ssd%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
L4RyLC81lsp1DN,QTLd JIQ7xObA1NXlmJ0Mth,sPeZGI