Score:0

OpenSUSE transactional server boot partition and efi

cn flag
mip

I have following problem with OpenSUSE transactional server. By mistake it was configured with /boot being ext4 partition on a dedicated drive, which also contains /boot/efi. I have noticed that /boot is also created on root btrfs / partition and actually that one is being used by GRUB and transactional-update. So to the ordinary user or process ext4 /boot is visible, but when you unmount it normally hidden btrfs /boot shows up...

I would gladly get rid of the crippled ext4 version of /boot, but the other one (the one with btrfs) does not have /boot/efi subdirectory. Because /boot/efi must be special FAT32 partition it has to be a separate partition and I need a mount point. But transactional server prevents me from modifying directory layout, so I can't create boot/efi directory in btrfs /boot. Any ideas how to make the system healthy other than complete reinstall?

paladin avatar
id flag
The volume, where your btrfs-rootfs is installed on, which kind of partition table does it use? MSDOS or GPT? Could ypu provide more information about your system? Especially why are you unable to create a directory under /boot ? PS as far as I know, a mounted EFI partition is not required to be able to boot from, cause your EFI-BIOS is reading the EFI-partition, completly bypassing any OS.
paladin avatar
id flag
PS are you sure about your btrfs filesystem not being a btrfs style raid? Why do you even want to change your running system? Some older kernel cannot boot directly from btrfs. Make sure your kernel which is used at boot time is sufficant.
cn flag
mip
@paladin it's GPT. The problem is not with the boot itself - you are correct that the partition does not need to be mounted at this point. Problem is with GRUB config tools as they have to see `boot/efi` when updating boot configuration. Yes, `btrfs` is on RAID partition. This is the deal with transactional server that it needs `btrfs` even for `/boot`. I know it sounds strange, but the server has apparently created its own `/boot` silently without my knowledge, while doing transactional update.
cn flag
mip
It refuses to recognize `ext4` partition mounted as `/boot` (in fstab) and recently I've learnt that transactional server must have `/boot` on btrfs. E.g. when I do `transactional-update grub.cfg` or `transactional-update bootloader` it will pick `btrfs` version of `/boot`, where it keeps recent kernel....
cn flag
mip
@paladin I forget to tell you why I can' create directory under `/boot`. This is another perk of transactional server. It utilizes `btrfs` to writes changes to a new snapshot, so that update does not affect running system. You can also always move to previous states, like on a virtual machine. This is especially good for rolling release distro like OpenSUSE Tumbleweed. Whole filesystem is read-only (except of directories like `/etc` or `/home`). You can update it only through snapshots for this `transactional-update` program exists.
Score:1
id flag

Regarding to your comments I would suggest the following, unusual.

Please take note that you should yourself test these "ideas" as this is not a 100% instruction in how to fix your problem but just a general idea for you how to do!

These system changes should be well noted and documented by you, so that no system admin in future is wondering "what the fuck?".

  1. Umount your ext4-/boot and your fat32-/boot/efi filesystem, so that you are happy with your btrfs only filesystem. Remove them also from automount (disabling in fstab or etc.).

  2. Now you have 2 options, either you are brave enough to create a new btrfs subvolume, which would give you a nice result, or you mount your EFI partition into /home/.EFI and you would always have to manually reconfigure GRUB!

    Cool option A: Create a btrfs subvolume as follow: btrfs subvolume create /boot/efi.

    Crazy option B: Create a directory in your /home as so mkdir /home/.EFI && chown root. /home/.EFI && chmod 700 /home/.EFI && echo "lol, I'm crazy"

  3. When you are going with cool option A, I've some good news for you. Just mount your efi filesystem into that directory/subvolume (/boot/efi) and do an update-grub and after that do an grub-install /dev/sdX where sdX should be your boot device. Also add your efi filesystem to your fstab for automount.

  4. When you are crazy you do the crazy option B. You mount your efi filesystem to /home/.EFI. Also add this to your fstab for automount, if possible, otherwise don't do an automount. Do also an update-grub and follow it with a grub-install --efi-directory=/home/.EFI /dev/sdX where sdX should be your boot device.

Remark: Your boot device should be the device which has the efi filesystem.

PS it's possible to have multiple copies of the efi filesystem on different devices (for redundancy), but you need to tell it to grub. Usually this happens automatically, but in your case it might be a bit more complicated

PPS btrfs subvolumes are usually not snapshotted, but for the efi filesystem, this is usually not needed - please test your entire system, especially the snapshot functionality, after adding a subvolume

paladin avatar
id flag
**This is not tested, and this might even not work ^^**
cn flag
mip
Thanks for the idea, I will test.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.