/etc/sysconfig/bootloader can be empty

[aplanas]

When the bootloader is configured by the user, or grub2-bls is used, the file /etc/sysconfig/bootloader can be present in the final image, but empty.

A workaround is fill it in disk.sh. For example:

loader_type="grub2-bls"
rpm -q systemd-boot && loader_type="systemd-boot"
if [ -s /etc/sysconfig/bootloader ]; then
    sed -i "s/^LOADER_TYPE=.*$/LOADER_TYPE=\"$loader_type\"/g" /etc/sysconfig/bootloader
else
    echo "LOADER_TYPE=\"${loader_type}\"" > /etc/sysconfig/bootloader
fi

[schaefi]

Sorry I can't follow you. Looking at the code and if I setup <bootloader name="grub2" bls="true"/> it leads to
GRUB_ENABLE_BLSCFG=true in /etc/default/grub and the code calls _setup_sysconfig_bootloader leading to a log message saying Writing sysconfig bootloader file

At least LOADER_TYPE and LOADER_LOCATION gets added or updated

So how can the file be empty ?

The provided workaround should not be needed at all. Can you be more specific or point us to an image build to reproduce it ?

[schaefi]

result of the latest TW build

localhost:~ # cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20250405"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20250405"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
# CPE 2.3 format, boo#1217921
CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20250405:*:*:*:*:*:*:*"
#CPE 2.2 format
#CPE_NAME="cpe:/o:opensuse:tumbleweed:20250405"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"

localhost:~ # cat /etc/sysconfig/bootloader 
DEFAULT_APPEND="console=ttyS0 root=UUID=28ef3047-93f4-4a5a-9797-c31a6e13c97e "
FAILSAFE_APPEND="console=ttyS0 root=UUID=28ef3047-93f4-4a5a-9797-c31a6e13c97e  ide=nodma apm=off noresume edd=off nomodeset 3 "
LOADER_LOCATION=none
LOADER_TYPE=grub2-efi
SECURE_BOOT=no

[Vogtinator]

Looking at the code and if I setup <bootloader name="grub2" bls="true"/>

What about <bootloader name="custom"/>?

[aplanas]

Sorry I can't follow you. Looking at the code and if I setup <bootloader name="grub2" bls="true"/> it leads to GRUB_ENABLE_BLSCFG=true in /etc/default/grub and the code calls _setup_sysconfig_bootloader leading to a log message saying Writing sysconfig bootloader file

At least LOADER_TYPE and LOADER_LOCATION gets added or updated

Uhm I do not think that LOADER_TYPE nor LOADER_LOCATION are populated in this case ...

[schaefi]

Uhm I do not think that LOADER_TYPE nor LOADER_LOCATION are populated in this case ...

I did a local TW based build with the following type setup

<type image="oem" filesystem="btrfs" kernelcmdline="console=ttyS0" firmware="efi" installiso="true" bootpartition="false" btrfs_root_is_snapshot="true" installboot="install">
    <bootloader name="grub2" bls="true" console="serial" timeout="10"/>
    <oemconfig>
        <oem-unattended>true</oem-unattended>
        <oem-swapsize>1024</oem-swapsize>
        <oem-multipath-scan>false</oem-multipath-scan>
    </oemconfig>
    <systemdisk>
        <volume name="home"/>
    </systemdisk>
</type>

and build that from the kiwi git checkout. The system provides the following setup

localhost:~ # cat /etc/sysconfig/bootloader 
DEFAULT_APPEND="console=ttyS0 root=UUID=3c29007b-7de8-41c5-b074-e5d0e3e476a5 "
FAILSAFE_APPEND="console=ttyS0 root=UUID=3c29007b-7de8-41c5-b074-e5d0e3e476a5  ide=nodma apm=off noresume edd=off nomodeset 3 "
LOADER_LOCATION=none
LOADER_TYPE=grub2-efi
SECURE_BOOT=no

So I cannot reproduce the described behavior

[schaefi]

btw, I can also not find any indicator that the grub tooling would support bls

localhost:~ # grep GRUB_ENABLE_BLSCFG /usr/sbin/grub2-mkconfig

...nothing. Other OS'es that supports BLS in grub (Fedora, RHEL, Ubuntu ...) has that

[schaefi]

What about bootloader name="custom" ?

If you set the bootloader to custom this means that kiwi does not produce any bootloader configuration. This also affects the changes kiwi would do to /etc/sysconfig/bootloader in case of grub as bootloader. We use the custom setting for bootloader and/or firmware usually for embedded systems which sometimes requires board specific bootloader settings which cannot be generalized in a bootloader class and implementation. This is often the case if uboot is the supported method to boot the board.

If you set custom here it's required to provide data/code as part of the image description to properly setup the loader

[aplanas]

and build that from the kiwi git checkout. The system provides the following setup

localhost:~ # cat /etc/sysconfig/bootloader 
...
LOADER_TYPE=grub2-efi
SECURE_BOOT=no

Uhmm that seems wrong too, as grub2-efi is not the selected boot loader. Should be grub2-bls.

So I cannot reproduce the described behavior

I will provide a better reproducer.

[schaefi]

Uhmm that seems wrong too, as grub2-efi is not the selected boot loader. Should be grub2-bls.

why should that be wrong ? From the docs:

The LOADER_TYPE setting is used during GRUB installation to ensure it's configured correctly for the system's architecture. 

The systems architecture is not affected if you setup grub the old way or using the bootloader spec and the new menu style. It would be a miss use of LOADER_TYPE to indicate anything about how the configuration files are structured. An EFI system with or without BLS is still an EFI system and I cannot change grub2-efi into grub2-bls because this would loose the information about the systems boot architecture

[aplanas]

Uhmm that seems wrong too, as grub2-efi is not the selected boot loader. Should be grub2-bls.

why should that be wrong ? From the docs:

The LOADER_TYPE setting is used during GRUB installation to ensure it's configured correctly for the system's architecture. 

Because grub2-bls is a different bootloader than grub2-efi. update-bootloader (perl-bootloader) recognize this bootloader from LOADER_TYPE="grub2-bls" (see https://github.com/openSUSE/perl-bootloader/tree/master/grub2-bls)

The package is a different one, and grub2-efi will not be in the rootfs nor in the ESP.

The systems architecture is not affected if you setup grub the old way or using the bootloader spec and the new menu style. It would be a miss use of LOADER_TYPE to indicate anything about how the configuration files are structured. An EFI system with or without BLS is still an EFI system and I cannot change grub2-efi into grub2-bls because this would loose the information about the systems boot architecture

It is very much affected. grub2-bls installation process is very (very) different from how grub2-efi is installed. The installation process does not involve grub2-mkconfig, grub2-install, nor editing grub.conf, for example.

But that should be a different bug, sorry for the noise. I will try to be back with the reproducer.

[aplanas]

But that should be a different bug

Maybe this can be reopened: #2497

[schaefi]

But that should be a different bug, sorry for the noise. I will try to be back with the reproducer.

Well thanks but I believe this noise is very important :) Look, many other OS'es uses BLS as the default and we don't set the LOADER_TYPE to grub2-bls on any of them because it's a setting for the system boot architecture and it's working as such on all of them. From a plain boot technology it makes a huge difference if you need boot code at some offset that you jump to (BIOS) or if you boot through a firmware and its layout requirements (EFI). Therefore the loader type setting to grub2 or grub2-efi made sense to me.

You told me that perl-bootloader consumes the loader type setting and behaves differently depending on grub2-efi or grub2-bls. Well if the system is EFI it stays EFI and a lot of actions must be the same because EFI is EFI. I can understand why perl-bootloader needs to differentiate the two things but this is a suse specific thing and it's different on other OS'es

You also told me that you are not using grub2-mkconfig in the BLS case, but other OS'es does it and there is even a variable for it available named GRUB_ENABLE_BLSCFG which kiwi checks to be available for BLS capabilities in the mkconfig scripting.

Don't get me wrong but everyone is cooking its own soup here and all this is making our lives unbelievable complicated. I'm very concerned that I won't be able to map what SUSE is doing with grub BLS into kiwi in a generic way.

Let's park this conversation. I agree it's a complete different topic