Migrating Linux Mint to SSD: Transfer Issues, Boot Errors, & Clonezilla Cloning Guide

MrDoimer 8214 8
This content has been translated flag-pl » flag-en View the original version here.
  • #1
    Level 38  
    Trying to transfer the current Linux Mint system to the SSD.
    According to the guide on the blog, I did good programs called "We are moving Ubuntu to SSD".
    Everything worked out, but after trying to boot from the SSD, I get the message as in the picture.
    Then for a moment there is a Linux loading screen, then busybox turns on.
    What did I do wrong?
    Migrating Linux Mint to SSD: Transfer Issues, Boot Errors, & Clonezilla Cloning Guide

    Now, after Clonezill's attempt to cloning, the effect is that the system loads indefinitely. I'd ask for a good guide.
  • #2
    Level 30  
    What circuses are there with "good programs". I usually copy the whole disk image and it's done. These messages are from grub, because there I recognize discs by UUID, if you got mixed up, these UUIDs have changed and now they don't match. Make a copy of the disk by dd by copying # dd if = / dev / sdb of = / dev / sdc bs = 1M assuming you have booted linux from USB, the source disk is / dev / sdb and the target is / dev / sdc. The dd tool is over 40 years old, why clonezille, linux has everything you need.
    As if you would like to see the progress: # pv / dev / sdb | dd of = / dev / sdc bs = 1M Just DO NOT confuse disks! The bs (block size) parameter speeds things up a bit.
  • #3
    Level 1  
  • #4
    Level 38  
    Ok thanks, I will do as you wrote.

    I will ask you again - can I get up without cloning the / home partition?
    I can't clone the entire disk because I have a partition on the HDD:
    sda1 - mount point "/" with size 20GB
    sda2 - mount point "/ home" with size of 270GB and about 120GB of data sits on it.

    and SSD has 2 (3 together with SWAP) with a size of 20GB and 220GB respectively.
  • #5
    Level 25  
    Linux partitions do not need to be cloned - you can copy the contents of the partition while maintaining permissions. You can use mc or rsync for this.
    After copying, you need to correct the UUID in / etc / fstab
  • #6
    Level 38  
    It looks like:
    HDD 320GB:
    sda1 - swap
    sda2 - "/" 19GB
    sda3 - extended - 290GB
    sda5 - "/ home" - 290GB

    SSD 240GB:
    sdb1 - "/" 20GB
    sdb2 - "/ home" - 215GB
    sdb3 - swap

    - I launched the Live distribution
    - I cloned the sda2 partition to sdb1
    - I've set the Gpedit flag in the "boot" partition of sdb1
    - I did NOT clone sdb5 because of the "greater> smaller"
    - I used the "# grub-Install" command from "root-directory = / mnt" or "/ media" (I don't remember, I found it on the internet).
    - I entered a new UUID giving the UUID of each partition on the SSD.

    The effect is that after the loading screen the system shows the error "Due to an internal error, the overlay / startx (?) Can't start" or something like that (doing work on this computer now, I can't stop and write the exact message, but you know what is going on). A black image remains.

    My guess is that you shouldn't copy the sda5 partition.
    What to do now?

    Now I have two questions - wanting to copy the files themselves (which weigh about 100GB) can I use the cp command?
    I also want to back up this partition to another disk, but also a smaller one, but should I indicate sda3 or sda5 as the source?
  • #7
    Level 39  
    What you want to do can be done in several ways. The rule is that the system is booted with GRUB or lilo. Their configuration files state where the kernel image is located and it must be correctly defined. Moving e.g. libraries is absolutely allowed, which means that it is not necessary to make a post-sectoral copy of the system.

    1. The case when you started the system and the one you want to move is mounted, its partition e.g. in / mnt / mint and the target partition / mnt / newmint. You usually copy data between partitions using cp with the -axp options. Then add the target partition / mnt / newmint in GRUB or lilo as an optional boot. If it is a different disk, it is advisable to add the boot flag, e.g. using fdisk. On the target disk you still have to bury in fstab to set up partitions. You are restarting from the copied partition and the system should stand up.
    2. Compress the entire system so that you can unpack it. The easiest way to do this is when the compressed system is mounted in e.g. / mnt / mint and inactive. The point is that a working system has quite a few things that are true but should not be compressed e.g. device files, tmp. if you have a filesystem mounted, you enter its partitions, e.g. / mnt / new_mint into the main tree and compress:
    tar -xJvpf mint_image.txz *
    The J flag means that you compress the system with xz, which means it will take a while ;) .
    3. Of course you can do it on a working system but then you will have to inform tar about what you don't want to include in the archive. This is done with the --exclude flag.
    In the main tree you issue the command:
    tar -cJvpf --exclude var --exclude proc --exclude opt --exclude sys --exclude home --exclude mnt --exclude dev --exclude tmp --exclude run mint_obraz.txz *

    Again, when you unpack it to the destination disk you need to create directories that you did not compress (option --exclude). It would be good to do a simple script to add them or to bother each time using e.g. mkdir :) .
    Then you will add the unpacked system image to the GRUB of the currently running system and restart. Of course, after starting the newly unpacked system, you should run the GRUB or lilo configuration tool so that the bootloader will also be installed on the new disk.

    The target disk can be small enough for the unpacked system image to enter.
  • #8
    Level 38  
    So doing it with "dd" as I did and described is not correct and will not work?

    If it is not correct, please answer:
    MrDoimer wrote:
    My guess is that you shouldn't copy the sda5 partition.
    What to do now?
  • #9
    Level 1