I cloned my Btrfs drive with OpenSUSE Tumbleweed installed on it to a larger drive with Clonezilla, I've even tried doing this sector-by-sector. Yet, even though the process appears to have been finished successfully every time, when I try to boot from the new drive, a Ubuntu GRUB appears, and of course nothing is loading. I assume that the Ubuntu menu is coming from Clonezilla itself, but why wouldn't Clonezilla copy everything identically?

Also, I cannot mount the new drive from OpenSUSE. The drive is seen in the partition manager, but no mount option is available.

Can someone please clarify what is it that is causing the drive clone not to boot and even not to mount? I presume there are some peculiar specifics of Btrfs, but I have no idea why sector-by-sector cloning would not produce an identical copy of everything, making the disk bootable and mountable. Would appreciate some help.

Update: I was able to make the partition mountable with the help of Error for `mount`: `system call failed: File exists.` But I still can't boot from it. Also, for some reason there is no user directory under /home/ on the new disk, despite the supposedly identical copy.

  • Please show the output of lsblk on your system, the contents of your /etc/fstab file, and if your system uses UEFI-style boot, also the output of efibootmgr -v. – telcoM Oct 12 '19 at 20:26
  • @telcoM lsblk output: pastebin.com/raw/Pda9QLF5; fstab: pastebin.com/raw/SiD01ig6; efibootmgr -v: pastebin.com/raw/f3LerYzU. I noticed that efibootmgr gives a lot of entries which are coming from my previous Linux installs, but I only have OpenSUSE presently on the disk. – sequence Oct 12 '19 at 20:34

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
  • 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.

  • Thank you for this comprehensive answer. This is a very new concept to me, I didn't know this about Btrfs, it looks like this file system is very specific. I couldn't even mount it in Ubuntu. I'm not even sure if it's worth it using this filesystem at this time. I did the commands sgdisk --partition-guid=1:R and efibootmgr -c -d /dev/sdb -l \\EFI\\opensuse\\shim.efi -L opensuse-clone and rebooted. The new item opensuse clone (on /dev/sdb3) appeared in the boot menu so I chose it but still the system on sda loaded instead. Not sure why. – sequence Oct 13 '19 at 2:43
  • Also if I explicitly choose the physical disk associated with sdb in the BIOS boot menu, the Ubuntu boot prompt appears. So maybe I also need to edit the UEFI file on the disk. But I decided to do the cloning again, remove the old disk and see what happens when I try to boot from the new one, as to eliminate the conflict of UUIDs. Also, can you please clarify the difference between btrfstune -m /dev/sdb3 and sgdisk --partition-guid=1:R /dev/sdb. Both appear to change the UUID. And how does one access \EFI\Boot\bootx64.efi? The slashes are not Linux slashes. – sequence Oct 13 '19 at 2:47
  • 1
    I've extended my answer to hopefully answer your questions. It seems to me that you have two new things to fully understand: 1.) btrfs can be like a LVM and a filesystem packaged together, much like ZFS if you're familiar with it, 2.) UEFI is quite different from traditional MBR-based PC booting: if there is no fallback bootloader on the disk, selecting just the disk to boot on is not enough; in that case you'll also have to explicitly select the bootloader, and unfortunately not all firmwares give you a good UI for that. – telcoM Oct 13 '19 at 9:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.