Problem with booting after resizing partitions

[stalek]

I installed openSUSE Tumbleweed on previously prepared partitions. I assumed that 300 MB for the EFI partition and about 1.2 GB for the BOOT partition would be sufficient. I expected the kernel files along with their additions to be stored on the BOOT partition, but unfortunately they are currently being written to the EFI partition.

Because the first update filled up the EFI partition and I could no longer perform another zypper dup, I decided to resize the EFI partition. Since the BOOT partition was essentially unused (it had mount point for EFI), I decided to remove it and merge it with the EFI partition. In my case this was fairly convenient, because the BOOT partition was created directly after the EFI partition, so I could cannibalize it for EFI. I did this after first making a backup of the entire EFI contents onto the ROOT disk.

My ROOT partition is on Btrfs and sits on top of MD. I have three NVMe disks: on disk 0 I have the boot setup, and on disks 1 and 2 I have swap partitions. In this way, I boot from disk 0 and have a RAID 0 (striped) array across three NVMe disks, all with logically aligned sizes for the RAID.

After booting from a live disk with GParted, I opened a console and made sure that all drivers could see the partitions and RAID disks as expected. Then I deleted the BOOT partition, expanded the EFI partition to the full size of both partitions combined (EFI + BOOT), created a filesystem on EFI, and copied the old EFI contents onto the enlarged EFI partition. Up to this point, everything was fine.

After these operations, I created a directory on the ROOT disk for mounting EFI under the boot directory (just as it was before) and modified /etc/fstab by removing the BOOT partition mount entry, since that partition no longer existed.

At this point I performed a chroot and ran dracut to generate new boot code for the system. Unfortunately, Tumbleweed now reaches the splash screen with the spinning wheel and after some time (a few minutes?) drops into emergency mode with a Dracut console.

The messages indicate that the system is trying to mount the old BOOT partition. In the new fstab I provided the UUID of the new EFI partition for mounting, but somehow a plain invocation of dracut did not take my new entries into account.

How can I properly regenerate the initramfs and related components so that the system boots normally again?

I also considered passing some disk mapping parameters from the Dracut console to get the system to boot once, and then run a normal zypper dup, which would probably resolve the issue. However, so far I haven’t had a clear idea of what parameters and settings I would need to pass at boot time from that console.

Do you have any ideas on how to get out of this situation? I definitely do not want to reinstall the system, and I want to keep the existing data intact.

[deano_ferrari]

@stalek

I installed openSUSE Tumbleweed on previously prepared partitions. I assumed that 300 MB for the EFI partition and about 1.2 GB for the BOOT partition would be sufficient. I expected the kernel files along with their additions to be stored on the BOOT partition, but unfortunately they are currently being written to the EFI partition.

By default, Tumbleweed now uses GRUB2 with BLS (BootLoaderSpec) support. That can be a surprise to those who weren’t expecting it.

GRUB2-BLS in openSUSE Tumbleweed is now the default

@stalek

At this point I performed a chroot and ran dracut to generate new boot code for the system. Unfortunately, Tumbleweed now reaches the splash screen with the spinning wheel and after some time (a few minutes?) drops into emergency mode with a Dracut console.

Your system is dropping into dracut because the old boot partition UUID is likely still referenced. You need to regenerate initramfs and refresh the BLS entries so they point to the new EFI partition.

Inside the chroot environment: mount /dev/<new-efi-partition> /boot/efi, and update /etc/fstab so /boot/efi uses the new partition UUID. You can use blkid /dev/<new-efi-partition> to get that info.

Regenerate initramfs images with dracut --force --regenerate-all

Recreate BLS entries pointing to new EFI with sudo sdbootutil mkinitrd

After this, the system should boot as expected again.

[stalek]

Thanks for the quick reply. I managed to resolve the issue yesterday.
As I mentioned earlier, I initially ran dracut in the active chroot, but it had no effect at all. I then ran dracut again, this time with the verbose flag enabled and saved the execution logs to a file. At the end of the log, I noticed that dracut was writing its output to /boot by default instead of /boot/efi/.... After copying the file to the correct location, the system booted successfully and I was able to run a normal zypper dup, update the entire system, and create a new boot entry with a newer kernel.

I did use sdbootutil, but I must have made a mistake somewhere, because the generated initramfs did not overwrite the old one.

The problem is now resolved, so this topic can be considered closed.

[deano_ferrari]

Thanks for te update. Glaf to read that it is resolved now. Yes, dracut defaults to /boot as its output directory. After merging /boot into the EFI partition, dracut regenerated the initramfs correctly but wrote it to the wrong location. Copying it to the active EFI-backed boot directory resolved the issue. A subsequent zypper dup likely recreated correct boot entries.