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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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:~$sudoblkid/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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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
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:
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.
Also, you may have to fix /etc/fstab along the same lines.