• clone luks encrypted root from SATA SSD to NVMe SSD


    Hello there,
    I just installed my NVMe SSD yesterday. I used the expert mode of the clonezilla live CD to clone my SATA SSD over to my new one, unplugged the old SSD and rebooted. And ended up with this screen:
    sorry for the quality

    I’m not really sure whats the problem here. My duckduckgo-search told me it has to do with the swap partition being “modified” or something, but nothing in detail. Plus I don’t get why the swap partition is even necessary to boot aka letting me decrypt my root partition on bootup?

    The first UUID is indeed my swap partition. The second is the UUID of my unencrypted root partition, which he obviously can’t find since he did not ask me to unlock it in the first place. I double checked the UUIDs and they were cloned from the old SSD to the new one 1 to 1, just like they should be. Any ideas?

    My luks encrypted root and stuff was created by the Antergos installer last time I installed my system. So I did not configure it myself - unlike my HDDs, which I encrypted myself - and have no clue what so ever how I can fix this mess manually. For the time being I rebooted to my old SSD, but I really want to clone it with the least possible effort.

    If you need more information like content of different config files just ask. I’d be happy to provide them.

    Thanks in advance.

  • @pepper-jk
    Those UUIDs have probably changed. UUID is a unique identifier of a disk partition in your system. Now you have a new disk with new partitions, and the UUIDs of those new partitions are not be the same as on the original SSD disk, so probably your /etc/fstab file just has wrong UUIDs.

    NOTE: before doing anything more to your disks, do create a backup of your personal precious data to some safe place! You may regret if you don’t.

    So, to fix this, one way could be to use LABELs to identify partitions instead of UUIDs.
    Edit file /etc/fstab and change partitions to use LABEL instead of UUID. You probably can disable swap by commenting out the swap entry there.
    For example:

    # UUID=<your-long-uuid> / .....
    LABEL="Antergos" / .....
    

    By the way, if you have lots of RAM (say at least 8 GB) you may not need have swap at all. Furthermore, there is a possibility to use a swap file instead of a swap partition, which makes things even more easy.

    The LABELs to your disk partitions can be created e.g. with gparted.

    Disclaimer: I’m not sure if you can do this safely in the new NVMe encrypted disk, but maybe you can boot to the original SSD and make the /etc/fstab modifications there (and reboot to see that they work) and then copy the disk again to NVMe SSD.

  • @manuel Thanks for the quick reply.

    I’m sorry to proof you wrong tho. As for the UUIDs, this is my output of lsblk -no NAME,LABEL,UUID:

    sda                            
    ├─sda1            UEFI_SYSTEM  12D7-771E
    ├─sda2            AntergosBoot 8c43bf91-8bcd-43ce-ac52-b24c766e0653
    ├─sda3                         a007d8e6-cc39-4549-b2e1-4f227529dcb7
    │ └─cryptAntergos AntergosRoot 29fdcc7f-95e1-4b89-b4d5-bb5340c904f8
    └─sda4            AntergosSwap f454254e-336e-4178-8785-61de850eceea
    ....
    nvme0n1                        
    ├─nvme0n1p1       UEFI_SYSTEM  12D7-771E
    ├─nvme0n1p2       AntergosBoot 8c43bf91-8bcd-43ce-ac52-b24c766e0653
    ├─nvme0n1p3                    a007d8e6-cc39-4549-b2e1-4f227529dcb7
    │ └─tmp           AntergosRoot 29fdcc7f-95e1-4b89-b4d5-bb5340c904f8
    └─nvme0n1p4       AntergosSwap f454254e-336e-4178-8785-61de850eceea
    

    (cryptAntergos is the luks mapper /dev/mapper/cryptAntergos of the running SSD and tmp is the mapper of my new one, decrypted it to show all UUIDs)

    As for your note, I don’t really have anything important on the root partition anyway. It’s mainly the procedure of installing and configuring the system from the start, I try to avoid by cloning the SSD. Plus I doubt clonezilla would break my source disk while cloning it, but thanks for the well meant warning.

    Yes, I indeed do not need my SWAP partition anymore. I used to with only 8GB of RAM, but I upgraded to 16GB about 2 weeks ago. Did not have time to change my configurations yet. But I would want a swap file just in case.
    Yet again I don’t get the connection. I can try to boot without swap tho, and check if it makes a difference.

    LABELs are a nice thing, but since I don’t normally mess with the root partition (and should not have to), I doubt they are useful in this case. Additionally as you can see they already have labels added by the Antergos Installtion. They aren’t used in my /etc/fstab tho, because UUIDs are more precise - I guess.

    My fstab on both SSDs:

    UUID=a007d8e6-cc39-4549-b2e1-4f227529dcb7 / ext4 defaults,noatime,discard 0 1
    UUID=8c43bf91-8bcd-43ce-ac52-b24c766e0653 /boot ext4 defaults,noatime,discard 0 0
    UUID=12D7-771E /boot/efi vfat defaults,noatime 0 0
    UUID=f454254e-336e-4178-8785-61de850eceea swap swap defaults 0 0
    

    Please keep in mind that this should only be usable for the boot sequence, once I unlocked my encrypted root partition. Meaning the problem should be somewhere else. My first thoughts were something like this. But I just went in circles within the dm-crypt wiki pages.

    I will need to clone the disk again anyway, because I worked on the old one now. But first I’d like to understand the problem completely.

    EDIT:
    One thing I forgot to mention is, the disks are the exact same size:

    sudo fdisk -l
    Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
    ....
    Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
    ....
    

    old: Samsung SSD 840 SATA; new: Samsung 960 EVO M.2

  • @pepper-jk
    Sorry for misleading you. I just thought it would be a simple UUID problem, but more likely it is related to the encryption setup somehow.
    And as you can use the NVMe drive, it is not likely a driver problem.
    Hopefully someone here can help you!

  • @manuel
    No problem. Was important anyway to show the UUID and fstab situation to make sure it is not the issue. :)
    Thanks for your help.

  • @pepper-jk
    Just a thought (if you are still willing to listen to me ;)):
    maybe use plain old dd instead of clonezilla?
    Just to rule out the possibility that clonezilla did something unwanted extra…

  • @manuel Thanks, that did the trick.

    I was talking to a friend beforehand just to make sure I don’t get even more clone procedures by testing it with dd - and with it more write ops on my new SSD. But we came to the conclusion that clonezilla must have done something either to grub or to the partition layout (e.g. of by one block or something).

    I’m just happy it is solved, never gonna use clonezilla for 1 to 1 copies again. :D

    EDIT(to provide details):
    I used dd if=/dev/sda of=/dev/nvme0n1 bs=64M status=progress for cloning the SSD now.

  • @pepper-jk
    Nice to hear it worked!
    I’ve always relied on good old dd, it has never failed me. But this incident unfortunately can create a bit of shadow upon clonezilla (hope I’m wrong though).

  • @manuel Well for all we know it could have been user error, maybe I missed an option I should have taken in this case. Doesn’t matter now.
    Clonezilla will still be my number one pick for backup images.

  • @pepper-jk
    Hmmm… Are you sure that you have all the correct options for making backups with clonezilla? Have you ever restored backups successfully?
    Just asking out of curiosity to find out about the reliability of clonezilla since I’ve considered using it as my backup tool.

  • My HDDs tend to be pretty stuffed with files, so I don’t backup my own system, since I normally know how to repair it.
    I did use it to backup older systems, PCs from family and friends and I once helped a friends firm out providing clonezilla as a backup solution. Worked well everytime. This was the first time I encountered any problems to be honest.

root12 encrypted5 clone3 luks14 Posts 11Views 320
Log in to reply