I attempted to upgrade my system from openSUSE Leap 15.6 to Leap 16 using the openSUSE migration tool. After the upgrade, the machine became unbootable, and the problems appear to stem from how the migration handles the transition to systemd‑boot and the existing partition layout.
I ran the official opensuse-migration-tool package from Leap 15.6. Only afterwards did I discover, by reading its upstream GitHub repository, that the tool is explicitly marked as experimental and “use with caution"". This warning is visible in project materials, but it is easy to miss when you follow the standard system upgrade documentation, which presents the tool as an available method rather than stressing its experimental status. The package upgrade itself completed without obvious errors, but on reboot the system failed to start the new Leap 16 kernel.
During the migration, the system was switched to systemd‑boot, which follows the Boot Loader Specification and stores boot entries in the EFI System Partition under /loader/entries/. Systemd‑boot does not read kernel images from Btrfs snapshots or parse Btrfs metadata; instead it expects plain EFI‑readable files (kernel and initrd) located on the EFI System Partition. On a typical Leap 15.6 installation, the EFI System Partition is often sized around 100 MB to 256 MB, which can be tight or insufficient for multiple modern kernel and initrd combinations, especially when you add new versions and keep old ones.
In my case, it looks like the upgrade routine tried to move the kernel and initrd to the EFI System Partition for systemd‑boot, but either did not copy them completely or ran out of space on that partition. I did not see a clear error at upgrade time, but the end result was that systemd‑boot did not have a valid, complete kernel to boot. This could be due to a silent “disk full” condition on the EFI System Partition, which would produce truncated or missing files and leave systemd‑boot with broken entries. That part is inferential rather than documented, but it fits the symptoms of an unbootable system after a bootloader switch on a small EFI System Partition.
When I tried to fall back to the old Leap 15.6 kernel while the rest of the system had already been upgraded to Leap 16 user space, the system quickly failed. Mixing an older kernel with a newer user space that includes upgraded glibc and systemd is not supported and can easily result in severe boot problems or kernel panics due to ABI and feature mismatches. In other words, the “old kernel plus new user space” fallback was not a viable rescue path.
At that point, I decided to wipe the disk and install openSUSE Tumbleweed fresh. With current backups available, I was able to restore most of my environment without major data loss, except for some local Brave browser data that had not been backed up. This time, I want to keep the Tumbleweed instance for at least 4-5 years without breaking it. I’ve already cut the fat and eliminated a lot of unneeded stuff.
This experience highlights that openSUSE’s download pages and documentation need very clear, prominent warnings about two things: first, the experimental status and risk profile of the openSUSE migration tool, and second, the bootloader and partitioning changes associated with adopting systemd‑boot, including EFI System Partition space requirements. Users should be made aware in advance that a small EFI System Partition can cause serious issues when switching to systemd‑boot and placing kernels and initrds there.
Finally, Tumbleweed and other recent openSUSE variants are increasingly using systemd‑boot as the default bootloader on UEFI systems. For users who rely on GRUB2’s password‑protected configuration interface and other boot‑level controls, this move can feel like a regression. Systemd‑boot offers a simpler interface with some firmware‑level security options, but it does not replicate GRUB2’s rich access control and configuration features in the same way, which is a real concern for people who want strong authentication at the boot menu itself.