Since I needed to get this done I had to use a process which I was reasonably sure would work, even if not the ideal I had hoped for. Until someone has a better answer, for later users, I'll answer with what I did do, successfully.
The initial problem statement included the information that BIOS boot was in use and the disk was partitioned in the DOS, or MBR, format. As such, the possible complications, if any, using UEFI boot or GPT partitioning are not considered here.
Note: almost every important process requires root privileges. This can either be done by logging in as root (not an option on some distributions), switching to the root user with sudo su, or prepending every command with sudo. The presumption here is that everything is being done as root, using one of the first two options. The commands are all written as if executed from roots account, not the user's account.
Needed for this are:
- The existing system in a running state
- A second disk, HDD or SSD, accessible to the system (internally or by USB)
- A bootable version, CD or USB, of Clonezilla Live
- A bootable disc of USB drive with either a live distro, or the ability to enter a recovery mode.
The last item is best if it's a version of the system being cloned with either the same, or a very close, kernel. Which ever tool is chosen the ability to mount and chroot into the new system is needed. No other tools are needed from the disc or USB drive.
1. Verify the disk names involved.
Run the mount | grep '/dev/sd'. This will show all currently mounted partitions. In the case of a BTRFS file system, as given in the question, there is likely to be several different mount points listed for the partition which has on / type btrfs given. All such partitions can be ignored as the process of cloning the root will clone them as well. If other partitions are mounted from a different physical disk, and that disk will remain after the migration, they can be skipped as well.
Also needed, and harder to find, is the partition on which Windows is installed. If, as is common, Windows was installed first, the Windows partition is very likely to be /dev/sda1, especially if the Linux system is also on a partition of /dev/sda.
Common partitions to look for are /home and /boot.
2. Create the needed partitions on the new disk
If the new disk is able to be connected by USB that makes things a bit easier.
- With the disk not connected run the command
lsblk
- Connect the disk and run
lsblk a second time
- The device in the second listing not it the first is the device to use
Caution: If you do a reboot at any time in the process, and have more than one USB disk attached, it is quite possible for the device name to change. Check each time to verify the correct device name before proceeding or you will probably loose data somewhere.
The tool to use is a personal choice, and depends on your preferences. Some options typically available in most systems could include parted, gparted, cfdisk, fdisk, and gdisk.
After the partitions are created, run partprobe to be sure the system "knows" about the new partitions. Some tools will notify the kernel that it needs to, others won't. Doing it yourself ensures that it did get done.
Verify that the partitions are made, and seen by the kernel with the lsblk command again.
3. Create the Linux file systems on new partitions
The BTRFS root partition can be made with the mkfs.btrfs command, and mkfs.ext4 could be used to make the /boot and /home partitions. For convenience sake, if the new disk has a swap partition, the new swap partition can be prepared with the mkswap command.
4. Clean up the BTRFS root partition to reduce the time spent on the clone operation
List the snapshots of the system, with snapper list and remove as many as possible, with snapper delete <number>. Rollback options will be quite limited as a result. If the system is being cloned it's probably in a stable state and rollbacks to prior conditions should not be needed.
Run the balance operation on the BTRFS filesystem. A full balance can be very time consuming! Limiting it to only balancing chunks which are utilized less than some percentage can accomplish a lot, while spending a lot less time waiting. Depending on how dirty the system is 50% might be the limit of your patience. My system is balanced often, so I can use a higher percentage (90%) and spend a tolerable amount of time. The -dusage option limits the balance operation to data chuncks utilized less than the given percentage.
For my system the command was btrfs balance start -dusage=90 /
5. Create mount points and mount the new partitions for cloning
The root partition is obvious in all cases. Also needed might be the /home and /bootpartitions.
6. Clone the non-BTRFS filesystems
The rsync command is a better choice than a simple cp as it can be used to preserve the ownerships and permissions of the copied files. It's also possible to have rsync restart the process if it gets interrupted.
An example would be rsync --archive -hh --hard-links --partial --info=stats1 --info=progress2 --modify-window=1 --one-file-system /boot/ /boot2/
7. Clone the root, BTRFS, partion
The btrfs-clone program was the tool I decided to trust. The documentation suggests that the best results (in terms of space used) are from the "generation" strategy, so that's the one I choose.
The command, simple as it is, to do that would be btrfs-clone --strategy generation / /mnt
Expect the operation to take a while.
8. Modify the "new" system
There may be changes you need to make to the /etc/fstab file to accommodate changes to the partitions you want mounted in the new system. The entire system does not have to remain exactly the same. Label names, UUIDs and even device names can be changed during the process of migration.
In the case of openSUSE there is another possible cause of trouble. The system setup includes a file used during GRUB configuration to hard code some kernel parameters in the grub.cfg menu. The file is /etc/default/grub and may contain a line similar to:
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent resume=/dev/disk/by-label/Linux_swap quiet mitigations=auto"
Of concern is the section resume=..... This points to the swap partition used for suspend-to-disk operations. If the line is not commented out, has the resume=... in it, and the new disk has a different label, UUID or device name than the current disk, it has to be changed to reflect what the new version is. This will become important in a later step.
9. Use Clonezilla to clone the Windows partition.
I'm not an expert on Clonezilla. The option seems to be to use Clonezilla live on a bootable CD. Other than the langauge/keyboard options, the steps I followed were:
device-device work directly from a disk or partition to a disk or partition
Expert Expert mode: choose your own options
part_to_local_part local_partition_to_local_partition
Select the source partition
Select the target partition
Options menu changes
add Reinstall grub on target hard disk
drop Automatically adjust geometry ...
drop sfdisk uses CHS ...
drop Resize filesystem ...
add No GUI ...
add Remove NTFS volume dirty flag ...
-sfck Skip checking/repairing source file system
-p choose Choose reboot/shutdown/etc when everything is finished
After that completes the Windows partition has been cloned and GRUB might be added to the MBR.
10. Replace the old disk with the new disk
This is the point to get physical. Uninstall the old disk and install the new disk. If both disks stay installed, or connected, after this the system will probably get confused. As an alternative, if both disks are to be used, with the new one as the boot disk, the old, no-longer needed partitions need to be changed or reformatted, to give them new UUIDs and Labels.
11. Rebuild the boot process
From my experiment, the boot loader added to the MBR, if any, by Clonezilla is incomplete. The initrd of the old system may not be compatible with the new system, especially on openSUSE due to the /etc/default/grub setting above. Lastly, the grub.cfg file might have elements which are not compatible with the new system. Correcting all three is a straight forward process, if the preceding steps have been accomplished successfully.
Boot the live disc, and if needed select the option for recovery. If using a live CD, such as Ubuntu, it's possible to go all the way into the live system and then open a terminal. Using the terminal on a live system will also require the use of sudo su to have root privileges. Recovery mode on most systems is in root already.
The following presumes a disk of /dev/sdx with the following partitions:
/dev/sdx1 Windows
/dev/sdx2 `/boot`
/dev/sdx3 `/`
/dev/sdx4 swap
The partition numbers, and even the device name, could be different on your system, and the following steps need to be modified to match the situation
The steps
- Make a directory to work in, commonly
/mnt, which may already exist
- Mount the new system's root partition:
mount /dev/sdx3 /mnt
- Mount the new system's boot partition:
mount /dev/sdx2 /mnt/boot
- Connect the existing system's processes to the new one
for item in proc sys dev run; do
mount /$item --rbind /mnt/$item
done
- Switch into the mounted system
chroot /mnt
- Mount any other partitions the new system normally mounts
mount -a
- Create the new
initrd
mkinitrd
- Install GRUB to the MRB
grub2-install /dev/sdx
- Generate new
grub.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg
- Exit
chroot and reboot
exit
reboot
- Remove the disk of USB drive with the live or recovery system on it.
- Check that the new disk can boot into both the Window and Linux systems.
clonezillato clone the entire disk to the new, larger disk, and then usedgpartedto move and resize the partitions. Actually, you could do it all with just gparted live, and not bother with clonezilla.ddon a 500 GB disk and then the resizing is likely to take longer than just reinstalling both systems.