Menu

Issue cloning ssd internal to nvme external

Help
2024-12-01
2024-12-03
  • Colin Barrett

    Colin Barrett - 2024-12-01

    Hi guys!! Ok I'm having some issues using clonezilla. I'm trying to clone an 1tb internal ssd to a 2tb external nvme.

    I'm pretty sure I'm doing something incorrectly.
    After the cloning process when I attempt to boot from the nvme drive i get the following error:

    Busybox v1.36.1 (Ubuntu 1:1.36.1-9ubuntu1) built-in shell (ash)

    Enter 'help' for a list of built-in commands

    (initramfs)

    I'd genuinely appreciate at help i can get.

     
  • Gabriel VC

    Gabriel VC - 2024-12-03

    Hi! Your issue is the name of the device. On Linux, internal sata ssds are /dev/sdX (sda, sdb,...) whereas the nvmes are things like /dev/nvme0n1p1. Clonezilla wont fix this, so GRUB will try to find the OS into something like /dev/sda1, where the device wont be plced there by thr kernel anymore.

    I dont know the commands for it from that prompt but you must fix the routes that GRUB has for your boot options to point to the right parttiion / volume. Maybe try to fix the boot.cfg manually with a live linux usb flash to properly regenerate it at mext boot

     
  • Gabriel VC

    Gabriel VC - 2024-12-03

    Sorry, lot of typos above --I was typing from the phone and this website is not very responsive. An amendment to the above message is that the file I was referring by memory is not boot.cfg, but grub.cfg

    The key issue here is that the kernel is in the EFI partition that will be found no matter what by the system. So what is happening is the following:

    grub.cfg is pointing to /dev/sdaX or /dev/sdbX. This can be directly, or using an UUID which will be different for different devices. This is an example of my grub.cfg:

    gvisoc@vao:~$ sudo cat /boot/efi/EFI/fedora/grub.cfg
    search --no-floppy --root-dev-only --fs-uuid --set=dev bd53135a-8132-4d7c-adb8-72be7fe4dabf
    set prefix=($dev)/grub2
    export $prefix
    configfile $prefix/grub.cfg
    

    The kernel loads the devices, and places the NVMe partitions into /dev/nvme0nXpY instead that will have a different UUID.

    Then, it tries to build the filesystems using grub.cfg pointer to /dev/sdaX (or its UUID) in order to find the init system and rest of the daemons, and it can't find it as a result of all the above.

    So once you temporarily fix the grub.cfg from a live system and it boots, you should check grub documentation and re-generate all the boot configuration. If your grub.cfg has uuids, you'll have to use blkid to get the UUIDs of your drives.

    gvisoc@vao:~$ sudo blkid
    /dev/nvme0n1p3: LABEL="fedora" UUID="6c858fbf-d900-4394-b283-abaec1095c6b" UUID_SUB="0992b7a1-bc76-4f49-a7aa-5cba044df9ec" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="be7eb575-fcef-4706-88ba-ce2112142e1e"
    /dev/nvme0n1p1: UUID="DAC2-4BDD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1feb8325-fdc6-43ad-954d-bf48434c5ec9"
    /dev/nvme0n1p2: UUID="bd53135a-8132-4d7c-adb8-72be7fe4dabf" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0c7a6b70-6111-4a68-8750-7431af735930"
    /dev/zram0: LABEL="zram0" UUID="416203b8-de8c-4a8d-9be0-84d744726d49" TYPE="swap"
    

    Also, you may have to fix /etc/fstab along the same lines.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.