partition cloning problems

[fox]

I want to transfer a Ubuntu partition from one laptop to another. I don't want to clone the entire drive because both contain Windows 10 partitions, and I'm concerned that it wouldn't work when transferred from one computer to another. My thought was to use Clonezilla to clone the partition to an external SSD and then clone that to the laptop. I made sure that the partition on the external was larger than the source partition I want to clone from, but nevertheless, the operation failed three times. In each case the operation would proceed and then at some point, the percent of the operation completed would stop advancing; it never made it past 50%. I let the operation continue for an extra 10-20 minutes before stopping things by shutting off the computer. (No other way to stop it.) In all cases Clonezilla was run from a usb stick using default ("beginner") options, and I kept the usb stick in the laptop during the operation (i.e. I didn't put Clonezilla in memory). In the last two tries I wiped the target partition to make sure that somehow the drive wasn't getting filled during the data transfer.

First question - why didn't it work? Second question - might I be better off doing this from the command line with dd?

Both the source and target laptop are running Ubuntu 18.10 (along with Windows 10). The source partition has on it programs that take a lot of work to install; one program in particular is old and requires a bunch of 32 bit libraries that have to be hunted down and installed before it will work. That program resides in my home folder, but not the libraries. Knowing that both source and target partitions are running the same version of the same distro, is there an easier way to accomplish what I'm trying to do?

Those of you who attended the last PLUG meeting will get the irony of this problem. At that meeting I demoed Clonezilla!!!

[buster]

Do you have an older version of Clonzilla to  try with?

[Jason]

Are you creating an image? Because, I would go with creating an image if at all possible since the SSD isn't the final target drive. I'm not saying it should have failed if you were doing a direct clone drive to drive but maybe this is more likely to work.

There should be some way of producing debugging information in logs that you can review to see what happened. But doing some basic searches I haven't figured it out. I know it's an additional boot parameter you can pass to turn it on but not sure where it puts the logs to check later. Go to this page and search in the page (usually Ctrl-F) for 'debug' and you'll find it. It's not much to go in but maybe you can search on 'ocs' or 'clonezilla debugging' and find something helpful.

[fox]

Do you have an older version of Clonzilla to  try with?

Actually, I was using an older version (1-2 years old) on my first try. I then updated to the current version and tried again with that. Both the older and newer versions are/were the Debian, not Ubuntu, versions.

[fox]

Are you creating an image? Because, I would go with creating an image if at all possible since the SSD isn't the final target drive. ....

I could try the disk image. I started to last night, but I was concerned that I didn't understand what it was calling for as the "target" because it didn't use that name.

Apparently, one can use DD to make either a partition clone or disk image (instructions here. DD is apparently faster than Clonezilla, and the command is easier to understand for the disk image. Is there any advantage, then, to using Clonezilla for this function rather than DD? One advantage would be that you can run DD from an internal drive rather than a USB stick. But would I be correct to assume that one cannot use the partition you're running from as source for DD?

[Jason]

Apparently, one can use DD to make either a partition clone or disk image (instructions here. DD is apparently faster than Clonezilla, and the command is easier to understand for the disk image.

dd is command-line so it might have slight gains in efficiency from that. However, dd copies everything, even empty blocks. Clonezilla doesn't copy empty blocks as long as it supports the file system. Otherwise, it uses dd for the cloning. So if your drive is only half-full, Clonezilla should be about 2x as fast.

But would I be correct to assume that one cannot use the partition you're running from as source for DD?

Well, technically, you can (i.e. it will let you) but I don't know if it's a good idea. The question posted here is similar and though it refers to FreeNAS which I think is based off of FreeBSD, it's still a Unix-based system so I think it would apply to Linux, too. Similar tools are used across the BSDs and Linux.

[fox]

Well the DD command worked, but only for a partition clone. When I tried it for a disk image, it ran for a few gb then gave me an "out of space" message. I tried it several times with the same result, and on two different external drives. However, the partition clone worked very quickly; much faster than Clonezilla even if it was copying free space. As for the disk image not working, I have a feeling that I didn't give it the right command.

I should point out that I DD'd onto an external spinning drive, not the SSD I tried previously, so I can't rule out the SSD itself not being the problem. My next move will be to clone the cloned partition onto the other laptop. We'll see if that works. Even if it does, I anticipate some problem getting the partition to boot up, as the grub on the other laptop will have the wrong UUID for the target partition, as it will be changed to that of the cloned partition. Hopefully I can still boot it up by editing the grub parameters once it's installed.

[fox]

What I ended up doing is leaving the current bare installation of Ubuntu on the target laptop, and squeezing it down to make room for a new partition I want to use as a target. I then booted the target laptop with Ubuntu and DD'd the clone onto the partition I prepared. That part was successful. I then updated the grub to include the new partition. It did boot up, but it threw up a bunch of systemctl errors and I couldn't get it booted up to a GUI in any mode. I will try to repair it, but I suspect that the problem is incompatibility with the target laptop. In the end I might have to go through the laborious process of reinstalling everything to the working Ubuntu partition. I left myself with instructions on how to get my old program to work on an 18.04 or 18.10 installation, but there will be a lot of libraries to transfer and it will be a pain.

[Jason]

Btw, it's probably too late now but I want to be clear (perhaps only for others) what I mean by doing a disk image. I mean turning the entire disk into a single file that you can then restore from on another computer. These steps, specifically:

https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/01_Save_disk_image

[fox]

Thanks for posting that, Jason. Unfortunately for me, I cannot find a way to use the clone of my 18.10 partition on the other computer. It starts booting and then gets hung up. I'm going to have to recreate a number of things on the other computer.

[Jason]

Did you try booting it in recovery mode? This guide should help if you're not familiar with it though I confess I haven't used these tools. You can also edit the grub menu on the fly to insert kernel boot parameters that might get you to a working system.

[fox]

Yep, tried that, too; didn't work. However, I tried another trick that did work, sort-of. I reinstalled Ubuntu 18.10 over the cloned partition. This saved my Home files, but not most of my apps. But one thing it saved was the old statistical application I was having so much trouble with. It didn't work at first because some i386 library files were missing, but I was able to restore these from the cloned external drive and the application works. However, if that worked, it shouldn't be hard to go to the other partition I installed from scratch and do the same, the advantage being it would be a clean installation. I'll probably try this and if it works, I'll just rebuild that one with the lost applications.

[Jason]

Do you mean just backing up your home directory and restoring that? That would work. It's handy to even have /home on a separate partition for this very reason.

[fox]

Nope, not what I meant. I used the Ubuntu 18.10 installer and one of the installation options is "something else". If you choose that and then choose the partition you want to clean and it's the same distro (I think it can be an older version, but current version definitely works), it will install the same distro cleanly over your current one without wiping the home folder and any preferences stored there. When you choose it, you have to unselect "format" and mount it at root (/). That's all I had to do.

Until I read about it, I would have guessed that this would wipe your partition, but it doesn't. It does, however, remove apps not in the distro's repos, except for those installed in your home directory (which included the old app I was trying to keep). Also, you have to choose the same name for your Home folder as you had originally.

I don't know if this option is Ubuntu-specific, or applies to other Debian-based distros or even all distros.

[fox]

... it shouldn't be hard to go to the other partition I installed from scratch and do the same, the advantage being it would be a clean installation. I'll probably try this and if it works, I'll just rebuild that one with the lost applications.

Actually, what I did by installing Ubuntu over Ubuntu using the same version is more or less a clean installation. All I had to do was reinstall a few applications not in the Ubuntu repos (simplenote, Mendelay reference manager, RStudio frontend to R stats program, Crossover and insync), and their preference files were preserved, so it was quick and easy. I'm a happy camper.