If everything uses UUID for addressing disks, then the remaining problem is that your UEFI firmware might recognize the cloned disk as being a different disk. So you might have to add back the UEFI boot entries.
The one that it will boot, is the one that can be booted using “\EFI\Boot\bootx64.efi” relative to the EFI partition. And that’s probably windows.
If you can boot rescue media, you can use the “efibootmgr” command to add the boot entries that you need. Google for examples, or provide more details so that we can suggest a command.
That doomed you to failure. A true clone cannot be used in the same PC at the same time as that cloned from. There is no support for deciding which among identical twin UUIDs is to be selected. More likely there would be code in the boot process somewhere that aborts if such a duplication is encountered, in order to avoid inevitable corruption if proceeding was attempted.
Just picked only one source of boot in BIOS to be sure if it is booting from SAMSUNG USB SSD drive.
Then you did not do nothing. What else didn’t you do?
It does but windows only.
Exactly which Windows were you actually running? Are you sure?
Not what could you do, what did you do? If you booted post-clone with both disks connected you were proving nothing useful. Only one or the other can be connected post-clone and expect any good result.
The laptop came with Windows 10
I wasn’t asking which Windows release. I was asking whether the Windows on the original disk, or the Windows on the clone disk.
@mrmazda are you actually want to help or you want to show me you have eaten the wisdom of the whole world?
As I have said. I have cloned M.2 500GB NVMe to external SSD 1TB using dd command:
The clone seems to be successful except it boots only windows instead boot to grub menu and give me the OS list. This is it.
The fdisk -l shows the below:
GPT PMBR size mismatch (1000215215 != 1953525167) will be corrected by w(rite).
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: xyz
Device Start End Sectors Size Type
/dev/sdb1 2048 534527 532480 260M EFI System
/dev/sdb2 534528 567295 32768 16M Microsoft reserved
/dev/sdb3 567296 794656767 794089472 378.7G Microsoft basic data
/dev/sdb4 998166528 1000214527 2048000 1000M Windows recovery environment
/dev/sdb5 794656768 998166527 203509760 97G Linux filesystem
Next, yes I tried to boot the clone from the same machine. I will try a different machine on Monday.
Any other idea if the other machine will also boot in Windows only?
Insulting people who attempt to help you rarely helps.
As I have said.
At his point if should have become obvious to you that what you have said is not sufficient. So repeating the same over and over again won’t lead anywhere.
it boots only windows instead boot to grub menu
Without knowing what you did after having cloned disk and what exactly you do to boot “it” nobody can help you. “It” does not have free will, “it” does only what you make “it” do. The more details you provide (including snapshots or photos of each step) the more likely someone will be able to help you.
I’m surprised the clone boots Windows. I would not expect a true clone made while connected to a USB interface and cloned from an M.2 device installed internally to boot from a USB interface. Grub and linux kernel were configured for SATA and/or NVME boot, and not likely also USB. To expect a true clone to work correctly requires it be used in same manner as the original.
Mount your cloned disk on the running, original opensuse and then (for the partitions on the CLONED Disk!)
blkid /dev/sdbX
will give you the UUIDS for the respective partitions on the CLONED disk. Now have a look at /etc/fstab and you will most likely see, the UUIDS to be mounted on boot are still the UUIDs for the original disk. Try editing the UUIDs in fstab to match those for the correct partitions of the cloned disk and reboot. See what happenz…
When DD is used to clone, the clone is a true clone, a perfect bit-by-bit and sector-by-sector copy. No UUIDs were changed unless you did something to change them. If not attempting to boot with both original and clone in the system at the same time, no UUIDs need to be changed. If the opposite, attempting to boot with both attached at the same time, then before that attempt is made, all UUIDs, and everything referencing anything by UUID, must be changed.
What else would need changing to boot a clone from USB bus instead of original bus I won’t attempt to answer, since it’s not a use case for cloning I have any experience with.
Be absolutely sure you only work on the CLONE, not the actually booted suse! In my fstab there are three partitions mounted on boot, all with the respective UUID of the partition (the “very long number” in your opinion) You have to read fstab AND blkid for the CLONE partition. You can post the output of fdisk -l as a starter. There you will see the boot HDD/SSD as well as the Clone and find out the correct /dev/sdX for your purpose… can you paste the fstab here?
Many commands you might be familiar with are available at a Grub shell prompt, among them clear, btrfs-info, dump, file, hdparm, ls, lspci, lsmod, search, reboot, boot and many more. Maybe start with ‘set pager=1’ and help, then find some clues.
None of these is available at grub rescue propmpt unless they have been compiled into core.img. They are not compiled in in case of normal installation using grub-install and as far as I remember also not for signed image.
# mount -o bind /dev /mnt/dev
# mount -o bind /run /mnt/run
# mount -o bind /sys /mnt/sys
# mount -o bind /proc /mnt/proc
# chroot /mnt
2. # grub2-install --target=x86_64-efi
3. # grub2-mkconfig -o /boot/grub2/grub.cfg
The only problem I have now is when I reboot It does not show the grub menu list. I have to do a full shut down process to see the grub menu options. It is probably some config issue. Any idea?