1

Topic: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

I hope that someone here has either heard of or personally encountered this problem before, and that that someone might be able to tell me what I did wrong, and maybe even how to dig myself out of this hole, preferably without having to reinstall Ubuntu from sctratch.  So anyway, here's the story...

Awhile back, I installed Ubuntu 16.04 desktop (amd64) onto a Sandisk Flair 16GB USB 3.0 stick I had lying around.  I then installed a few applications and made a couple of small customizations, e.g. simple harmless things like disabling click-to-focus, and so forth.

I wanted more space and also wanted the whole system to run a bit faster so I just got myself a brand new Adata 120GB SSD.

I used the trusty old Clonezilla (on a USB stick) that I had lying around to copy everything over verbatim from the USB stick to the SSD, including the MBR.  Conveniently, when I was done, the SSD booted up to my Ubuntu system without going in any way haywire, except...

Booting from the SSD is really slow.  I mean like really slow.

I just now checked again.  I can boot the system in question from the Sandisk USB3 stick in under 10 seconds.  But booting the exact same Ubuntu system off my shiny new SSD takes about 1 minute and 34 seconds.  Bummer.

So, um as Jerry Seinfeld would say "What's up with that?"  The whole idea of getting the SSD was that it was supposed to be faster, not slower.

What did I do wrong?

Thanks in advance for any help or guidance.


P.S.  Actually, I left out some details above... After I used Clonezilla to clone the USD3 stick to the SSD, I also then used gparted to (1) delete the Linux swap partition and (2) expand the Linux root (/) partition (from about 11 GB to about 60 GB) and finally (3) I used gparted also to recreate the original Linux swap partition, while making it just a tad bit bigger.  After all this, the system did still boot OK, but like I say, it is REALLY slow.

2

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

I guess the original installation was optimized for the medium you did use for it, the USB stick and the USB channel. Cloning the installation to another medium that needs other drivers and other access methods (SATA controller), would eventually force the hardware (motherboard components & drives) to work in modes other than the optimal ones, i.e. perhaps some emulation of the USB stick by the operating system or the SSD firmware. 

I think it would be possible to clone a system installation from a hard drive to another, that use the same drivers. I am not sure if it is possible to migrate the system from HD to SSD with no adjustment at all, but both HD and SSD use the same SATA controller. Did you try to run the system just after the cloning, before resizing the partitions? I think that the slow-down comes from the cloning it self, not from the resizing.

In order to avoid to reinstall the entire system, I would suggest to ask to the Ubuntu support forum, unless someone here can give an easy solution.

Another issue is the SSD alignment: by cloning the USB stick to the SSD, you did clone the sector alignment too. You have to check that it uses the MiB alignment. Using some other alignment like the legacy Cylinder would cause some performance penalty, although not so important as you report.

*** It is highly recommended to backup any important files before doing resize/move operations. ***

3

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

Further to Class413's explanation, if the sector size of the USB stick was different than the SSD then the installation may no longer be optimal.

Also mentioned was deletion and recreation of the swap space.  Did you remember to update the UUID in the /etc/fstab file so that Ubuntu could use the newly created swap space?

4

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

class413 wrote:

I guess the original installation was optimized for the medium you did use for it, the USB stick and the USB channel. Cloning the installation to another medium that needs other drivers and other access methods (SATA controller), would eventually force the hardware (motherboard components & drives) to work in modes other than the optimal ones...

Well, that is my sort-of vague guess too.  But I am hoping to learn for sure the exact nature and cause of the slowness, because it is always good to know such things, for future reference.

Did you try to run the system just after the cloning, before resizing the partitions? I think that the slow-down comes from the cloning it self, not from the resizing.

My recollection is that I _did_ boot the system immediately after clonezilling it to the SSD, just to see if it would even boot (which I was none too sure about).  It did boot, but I think I left the room while it was doing so, so unfortunately, I have no clear recollection of whether that first boot from the SSD was fast or painfully slow.

In order to avoid to reinstall the entire system, I would suggest to ask to the Ubuntu support forum...

Yes, I will do that.  I just wanted to ask here first because (a) I think you guys here probably have more familiarity with these kinds of issues generally and also (b) you guys are just nicer to deal with.  (The moderators over there seem to have too much caffeine, too much testosterone, or both.)

Another issue is the SSD alignment: by cloning the USB stick to the SSD, you did clone the sector alignment too. You have to check that it uses the MiB alignment. Using some other alignment like the legacy Cylinder would cause some performance penalty, although not so important as you report.

Right.  Yes.  I understood that... I mean that the alignment has to be proper for an SSD (1MiB).  But I have sort-of been assuming that these days _everything_ get aligned on 1MiB boundaries, and that thus, this alignment must have already been applied when I did the original install of Ubuntu to the USB3 stick.  (If so, then the alignment was already good for both the USB stick and the SSD.)

But I could be wrong.  Your advice that I should check it is sound.  There's only one small problem.  I'm really not sure off the top of my head how to do that.  Can you tell me?  (I know how to do this on FreeBSD, but not Linux.)  Can gparted tell me the exact partition starting locations?  And is that even the only thing that matters?  (I'm wondering if there are perhaps structures _within_ an ext4 filesystem that also really should be aligned to some minimal alignment.)

5

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

gedakc wrote:

Also mentioned was deletion and recreation of the swap space.

Yes, and that brings up another issue.  After the clone, I tried using gparted to just simply move the swap partition on down towards the right, you know, so that I could expand the root partition (which was to the left of that and at the start of the disk), but I tried a couple of different times in a couple of different ways and it seemed to me that gparted just didn't want to move it.  So finally, I just shrugged, deleted it, resized the root partition, and then just created a new swap immediately after (to the right) of that.

Does gparted have any issues/problems with moving a logical partition within an extended partition?  That's the way that a default Ubuntu install sets the swap partition up for some reason.  It was an approximately 3.5 GiB logical within an approximately 3.5 GiB extended partition.  (I have no idea why.  This seems rather silly to me, given that a default install puts the whole system within a single regular MBR partition... so there are three more of those available, one of which could be swap.)

Did you remember to update the UUID in the /etc/fstab file so that Ubuntu could use the newly created swap space?

Quite definitely the answer is no.  I didn't "remember" because I never knew before now that this might be an issue.  (And remember, the system _did_ boot up, even after all my fiddling.  That led me to believe that my newly created swap _was_ being found/used OK.  Buy you may be right.  Maybe it isn't.  I guess I'll need to check that too.)

6

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

Migrating an O.S. from USB stick to a SATA device (HD or SSD) is new to me. The usual way is to go from a SATA -often ATA emulating - device (HD) to another SATA device (SSD). That's why I suspect that the access to the device is different.
It can be even more complicated if we plan to migrate from a legacy MBR partition table to a GUID partition table.

You can check the alignment details with fdisk, using the parameters -l -u.
sudo fdisk -l -u
(-l is the lowercase L).
This shows the partition details in sectors. A MiB is 2048 sectors. So, if the first partition begins at sector 2048, it is MiB aligned. Same for the other partitions: their first sector number must be divisible by 2048.

(b) you guys are just nicer to deal with.

Thank you very much  smile

*** It is highly recommended to backup any important files before doing resize/move operations. ***

7

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

ronbaby wrote:

Does gparted have any issues/problems with moving a logical partition within an extended partition?  That's the way that a default Ubuntu install sets the swap partition up for some reason.  It was an approximately 3.5 GiB logical within an approximately 3.5 GiB extended partition.  (I have no idea why.  This seems rather silly to me, given that a default install puts the whole system within a single regular MBR partition... so there are three more of those available, one of which could be swap.)

Logical partitions can only be moved within the extended partition space.  In your situation it is likely that you needed to resize the extended partition to contain more free space.  Then you would be able to move the swap logical partition within the free space in the extended partition.

This is described in the GParted Manual - Advanced Partition Actions as a tip on resizing.  See also Moving Space Between Partitions for an example of moving space among primary, extended and logical partitions.

8

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

Yea... no.  I _wasn't_ trying to move the logical outside of its containing extended.

In fact (compliment ahead), this is one of the many nice aspects of the gparted GUI... It makes it VISUALLY quite apparent and intutive that the logical was _within_ the extended, and thus constrained within that outer box.

Generally, I use gparted just to create & delete partitions.  I can't actually remember when, if ever, I've used it in the past to MOVE partitions.  So I most likely just didn't know what I was doing and (thus) screwed it up.  But here's my recollection of what happened when I tried to use gparted to just simply move that containing extended partition to the right.

As I say, I'm not in the habit of using gparted to MOVE partitions, so I just googled that, and quickly found something that said I should just drag and drop the partition where I wanted it.  Well, I left clicked on it and tried dragging it rightward, but nothing happened.  So then I just left clicked on it again, to make sure it was highlighted, and then clicked on the move/resize button, thus bringing up the little menu that let's you specify (1) space before and (2) size and (3) space after.  All I remember now is that I kept on trying to put some non-zero number into the "space before" text entry field, and everytime I did, when I hit return afterwards, that number kept going back to zero.  Grrrrr.  That's when I gave up and just deleted the existing extended+logical (swap) resized the root (/) and then just created a fresh new extended and then a fresh new (linux-swap)  logical within that.

Still not sure why I failed to be able to just move the extended+logical (swap) rightwards, but I feel sure that it _is_ my own fault, and that a bit of RTFMing on my part would probably help a lot (which I confess I did not do).

9

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

Whoa!  Now THAT was unexpected!

I just now went back and re-did from scratch the Clonezilla clone of my entire Ubuntu system from my USB3 stick to my shiny new SSD.  Then, *without* me doing any other futzing around (i.e. -no- moving or resizing anything) I tried booting from the cloned SSD.  And surprise, surprise!  Now it also boots up in about 10 seconds, just like the USB3 stick, counting from the first sight of a pink/purple splash screen until I get a to where I can enter a password.  (It takes 4-5 seconds, even before that, on both USB3 and SSD, to get from the BIOS to the first sight of the pink/purple splash screen.)

So, bottom line:  It definitely was *not* just the Clonezilla cloning from the USB3 stick to the SSD that made things go slow.  It must have been something I did after that... i.e. one of the things I did with gparted... that caused the strange slowness.

I'll try to narrow this down some more and report back if I learn anything that gets closer to the actual cause of the mysterious slow-down.

10 (edited by ronbaby 2016-06-15 04:55:12)

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

OK, I futzed around with this for quite some time, and now I finally have the SSD configured the way I want it AND it is booting fast.

I learned a lot along the way... some of which isn't in the GParted manual, I think, but perhaps should be.

The first thing I learned is that I wasn't hallucinating when I recalled that gparted didn't seem to want to allow me to just plain move the extended+logical that contained the Ubuntu linux-swap.  If there was note in the manual explaning either (a) that gparted will refuse to move extendeds if they contain anything or (b) the reason for this limitation or (c) how to work around the problem, then I must have just missed all of these things, because I didn't see anything in the manual about any of this.

Fortunately, a bit of googling turn up this, which provided information about both (a) and (c), and provided also wnat amounts to a totally inadequate explanation for (b):

http://askubuntu.com/questions/659797/g … -the-right

So once I read the info/explanation/answer at the link above, even though the proedure described there does seem to be ridiculously "Rube Goldberg", at least I understood what I had to do, i.e. (a) expand the extended, (b) move the contained logical to the right hand end of that, and then finally (c) shrink the extended back down again (moving its start rightwards) so that it would again contain just the logical and would have a lot of free space to the left of it.  (Why gparted couldn't be endowed with enough smarts to do these three steps for me in one easy request is beyond me.)

Anyway, I tried to do these thing things and learned about even more possible "gotchas" along the way.  In the end, here is the recipie that I followed, which did work, and which did result in a nice fast bootable SSD with my cloned & expanded Ubuntu system on it.  (Note that this whole thing seems WAY more complex than it ought to be, given that people may want to do this exact thing very frequently, i.e. migrate an Ubuntu system from one physical volume to a newer bigger physical volume, expanding the root filesystem as they go.

So anyway, here's how I migrated & expanded my "default install" Ubuntu from a 16GB USB3 stick to a 120GB SSB.  I post these directions here for the benefit of others who may come here seeking complete instructions for doing this.  I believe that the same steps are applicable to _any_ case where it is desired to clone & expand a "default install" Ubuntu from one volume "A" to a bigger one "B".  (I stress "default install" because I probably could have avoided a lot of these headaches if I had just asked Ubuntu to use GPT partitions... rather than these funky old MBR ones... back when I did the original Ubuntu install onto the initial USB3 stick.)

If there is a simpler way to do any of this, please let me know.

=============================================================
1)  If the media/device containing the existing Ubuntu system... which we will call "A"... doesn't have gparted installed on it, then download and install that.  Also get a recent vintage Clonezilla and put that onto a USB stick.

2)  Connect both devices A and B as well as the Clonezilla USB stick.  Boot Clonezilla from the USB stick.

3)  Use Clonezilla to do a verbatim disk-to-disk copy of the whole A disk to B.  Be sure to say "Y" when asked if you want to also clone the boot loader.

4) When finished, poweroff.

5)  Remove the Clonezilla USB stick AND disconnect device B.

6)  Boot from device A (into Ubuntu).

7)  *After* booting is done, connect device B.  (If you connect it too soon, things can go haywire while attempting to boot from A.)

8) Run gparted and select device B (/dev/sdb).

9) In gparted, click on (thus highlighting) the Ubuntu EXTENDED partition.  Then right click on that, and in the resulting drop down menu, select Move/Resize.

10)  Decide where you want your relocated Ubuntu swap partition to end, and then adjust the *SIZE* of the extended partition accordingly.  Click apply.

11) After you do this, you will note that both the extended partition and the containing logical partitions now have a little key symbol next to them, because they have both now become "locked".  The reason that happened is that the resize of the extended partition (done in step 10 above) had a side-effect of causing the running Ubuntu OS (booted from A) to NOW see that there is a "new" and ADDITIONAL swap partition now available on device B.  So the running instance of Ubuntu OS (from A) now greedily decides to start using that (i.e. the B swap partition) ALSO as a swap partition, in addition to the one it is already using on A.

12)  You won't be able to move or resize the logical swap partition as long as it is locked, so right click on the key symbol next to it and then, in the resulting drop down menu, click "Swapoff".  (Note that this setting for this partition is NOT permanent is any sense, and will go away when... eventually, after completion of all the steps below... you reboot from your fully fixed-up device B.)

13) Select the linux-swap LOGICAL partition on device B by clicking on it to highlight it.  Then right click on it and select Move/Resize from the drop down menu.

14)  In the resulting pop-up menu, set Free Space Following to zero and then click Apply.

15)  Click the green check mark icon in the gparted top bar to apply pending operations and click "OK" to confirm.

16) Find the total number of sectors in the linux-swap LOGICAL partition by right clicking on it and then clicking "information".

17)  Drag out your calculator and divide the number of sectors in the LOGICAL swap partition (on B) by 2048.  Then add one to that result.  The resulting number is the number of mebibytes that you will now shrink the containing EXTENDED swap partition (on B) down to.

18) Right click on the EXTENDED partition and in the drop down menu select Move/Resize.

19) Left lick just to the right of whatever number you see in the SIZE field, and then repeatedly hit the backspace key until all digits of that number are erased.

20)  Type in the number you got as the final result of the calculations you did in step 17 above, and then hit enter.  (Note that when you do this, the "Space Before" number will be automagically adjusted to a proper value.) Then click "Apply".

21) Click the green check mark icon in the gparted top bar to apply pending operations and click "OK" to confirm.

22) Right click on the root (linux boot) partition and in the drop down menu select "Information".  Find the "Total Sectors" number in the resulting pop-up information window and divide that by 2048.  This is the CURRENT size (in mebibyte) of the root partition.  Write down this number.

23) Right click on the chunk of free/unallocated space that should now immediately follow the root partition.  Then, in the resulting drop-down menu, click "Information".  Find the "Total Sectors" value and divide it by 2048.  Write down the result of that division.

24) Add together the two numbers you wrote down in steps 22 and 23 just above.  This is the size (in mebibytes) to which you will now expand the root partition.

25)  Right click on the root partition and in the resulting drop down menu select "Move/Resize".

26)  Click just to the right of whatever number appears in the SIZE data entry field, and then hit the backspace key until all of the digits of that number have been erased.  Then type into the same SIZE data entry field the result you got from step 24 above.  Then hit enter.  Then click "Apply".

27) Click the green check mark icon in the gparted top bar to apply pending operations and click "OK" to confirm.

28)  Shut down / Power Off the system.

29)  Remove/disconnect device A.

30) Reboot the system using only device B.

Congratulations, you're done!
============================================================

As I said above, if there is a simpler way to clone+expand an existing "default install" ubuntu system, I would appreciate very much being told about that.  Otherwise I will continue to assume that yes, it really _is_ necessary to go through all of the above in order to do this one, seemingly simple thing.

(The apparent fact that a lot of the calculations needed to make this all work properly need to be done *manually* is especially disconcerting.  I think that gparted could be a bit more helpful in some cases where those results have to be computed.)


P.S.  Obviously, the above procedure is substantially different from what I had done before, i.e. first deleting and then recreating from scratch (using gparted) the linux-swap extended & logical partitions in a different location on the SSD.  With 20/20 hindsight I can confidently say with certainty that *that* was clearly a Bad Idea.  I'm still not at all sure why doing it that way resulted in a system which was at once both (a) still bootable but also (b) REALLY slow.  But perhaps that's just one of life's little mysteries that I'll never know the answer to.

11

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

I just understood that you tried to move the extended partition together with the contained logical ones. It is true that this isn't clearly marked in the GParted Manual. Each partition is processed separately. It has got its own partition boot record and data space. Of course, this could be done in theory. In practice, it is always possible to schedule the operations of resizing/moving each partition including the limits of the extended partition.

Fully automatic procedures are nice and useful in absence of any problem. In case of problem, however, it is better and safer to avoid long operation sequences and schedules, so that we are able to better control, check and track the error. Trust me, there are many unknown and unexpected sources of problems, related to various software or hardware issues. How to handle a bad block or a bad connection cable? Furthermore, such problems aren't always clear, so it is to the system administrator to investigate and take decisions. Imagine a more complex configuration with various file systems and operating systems with their own specific details, not always the same alignment, ... .

Thank you for your extremely detailed guide above. Just a few remarks:
- I see that you use the Ubuntu media to run GParted. This can work if you have the right GParted version installed there (usually the latest one). By using another live system, like the GParted livecd/usb, you would avoid the locked swap partition, because it doesn't use swap by default.
- I think you could move partition limits graphically on screen, unless you want to define a precise place in the disk space.
- You can always post a feature request in the appropriate section of the forum. Unfortunately, the developing team is quite small, that's why very few new features are added to the software. Your input is welcome and appreciated, of course smile

*** It is highly recommended to backup any important files before doing resize/move operations. ***

12

Re: Moved/copied Ubuntu from USB stick to SSD and now it's SLOOOOOOO

Further to the comments by class413, the steps could be reduced by moving the swap partition rather than deleting/recreating.

To resize the extended partition, none of the logical partitions may be in use.  This means the first step is to swapoff/unmount all logical partitions.  This is the default behaviour with the GParted Live image.

With that handled, the steps are (a) grow the extended partition to the far right, (b) move the swap logical partition to the far right, and (3) shrink the left side of the extended partition to the right to butt up against the swap logical partition.