Okay, so according to your lsblk output and your /etc/fstab, you have essentially an all-btrfs system, with the exception of the EFI system partition.
Note that a single btrfs filesystem can extend beyond a single partition or even to multiple disks: since your lsblk output does not say what your /dev/sdc is being used for, it might be used as an extension of your btrfs that contains your /home subvolume. That might explain why it is not there on the clone, or perhaps you simply failed to mount all the different subvolumes. You could use btrfs filesystem show to see which devices/partitions belong to each mounted btrfs filesystem.
When you ran btrfstune -m /dev/sdb3 as you mentioned in the comments to the other question you linked, it changed the UUID of the cloned filesystem, so the UUID entries on the /etc/fstab on the cloned filesystem are no longer correct. You'll have to fix them in the /etc/fstab file of the clone, and possibly also in its GRUB configuration and/or initramfs. You can use lsblk -o +UUID to view the new filesystem UUID. This UUID is used by GRUB and the Linux kernel, but not by the UEFI firmware. It is stored within the filesystem metadata.
You would have to do something like this:
mount /dev/sdb3 /mnt
mount -o subvol=/@/boot/grub2/x86_64-efi /dev/sdb3 /mnt/boot/x86_64-efi
mount /dev/sdb1 /mnt/boot/efi
and then:
edit /mnt/etc/fstab to replace the filesystem UUID on every line referring to the btrfs filesystem
edit /mnt/boot/grub/grub.cfg (or maybe /mnt/boot/efi/EFI/opensuse/grub.cfg depending on where OpenSuSE places its actual GRUB configuration) to replace the filesystem UUID on kernel boot options line
- edit
/mnt/etc/default/grub to replace the filesystem UUID so that the old UUID does not accidentally come back when installing a kernel update or regenerating the GRUB configuration for some other reason
- maybe completely recreate your initramfs file
If it turns out the initramfs file needs to be recreated (if it completely relies on kernel boot parameters to find the root filesystem, it might not be necessary), you can do it like this at this point:
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt /bin/bash
mkinitrd # or whatever is the appropriate command for OpenSuSE
exit
- finally unmount everything you mounted
To get the system to actually boot from the cloned disk, you'll need a UEFI boot variable defined for it. From your efibootmgr -v output, the OpenSuSE boot entry refers to the EFI System Partition by a partition UUID. This is a separate UUID, which is used by the UEFI firmware only. It is stored in the GPT partition table.
Boot0000* opensuse-secureboot HD(1,GPT,e099a79f-8b66-412d-89ae-a4869876f500,0x800,0x100000)/File(\EFI\opensuse\shim.efi)
You can view the partition UUIDs with lsblk -o +PARTUUID.
Having two disks with identical partition UUIDs may confuse your system firmware, or the firmware may simply pick the first disk with the matching UUID. If you plan to keep both disks in the same computer, you might have to change the partition UUID using sgdisk --partition-guid=1:R /dev/sdb (this command will generate a new random partition UUID for partition #1 on /dev/sdb).
Once complete, you would need to create a new UEFI boot variable for the cloned disk. The command for that would be something like efibootmgr -c -d /dev/sdb -l \\EFI\\opensuse\\shim.efi -L opensuse-clone. Note the doubled backslashes, because the backslash is a special escape character for the shell; the ESP filesystem is FAT32, so the UEFI firmware uses MS-DOS/Windows style backslashes as path separators instead of Unix-style forward slashes. Helpfully, this command will automatically read the partition UUID from the specified drive, so you won't have to type it.
(You may want to use efibootmgr -B -b XXXX where XXXX is the BootXXXX number of one of your past Linux installations, to clean up the obsolete UEFI boot variables from the system NVRAM.)
But if you plan to move the disk to another computer, changing the partition UUID should not be necessary, but the UEFI boot variable should be created on the system that is the recipient of the cloned disk. You might use some Linux Live boot media to do that, but ensure that you boot from the media specifically in UEFI style, or you won't be able to access the UEFI boot variables.
Alternatively, if you need the cloned disk to be bootable on any UEFI system with no significant preparations, you should set up a copy of the UEFI bootloader at \EFI\Boot\bootx64.efi, the fallback/removable media bootloader path on the ESP partition of the cloned disk. Unfortunately I don't have information of the exact set-up of the OpenSuSE UEFI bootloader at hand, so I cannot give you exact steps for that.
To access the ESP on the cloned disk, you would have to first mount it, for example:
mount /dev/sdb1 /mnt
and then you could place the fallback bootloader at /mnt/EFI/BOOT/bootx64.efi, which now corresponds to the DOS-style pathname \EFI\BOOT\bootx64.efi used by the UEFI firmware.
lsblkon your system, the contents of your/etc/fstabfile, and if your system uses UEFI-style boot, also the output ofefibootmgr -v.lsblkoutput: pastebin.com/raw/Pda9QLF5;fstab: pastebin.com/raw/SiD01ig6;efibootmgr -v: pastebin.com/raw/f3LerYzU. I noticed thatefibootmgrgives a lot of entries which are coming from my previous Linux installs, but I only have OpenSUSE presently on the disk.