Regression in Grub menu options - user text - oem

[phillxnet]

Problem description

Grub user text, on reboot of oem type installs, has no customisation of user facing grub options text. Previously both the initial boot of the installer (still working) and all subsequent reboots and updates, would maintain the user facing text customisation applied by kiwi.

I.E. Previously generated oem installers from our relatively unchanged config would result in an initial grub screen, in our case, depending on profile related config edits (name=) of:

Rocsktor-Leap15.2-RaspberryPi4 [ OEM ]
Advanced options for Rockstor-Leap15.2-RaspberryPi4 [ OEM ]
Start bootloader from a read-only snapshot

or with no edits the first line would read:

Rocsktor-NAS [ OEM ]

But more recent kiwi-ng generated oem type installers have the above expected customisation as expected during install but upon booting into the resulting install the Grub text is reverted to the upstream 'openSUSE' text thus:

openSUSE Leap 15.2
Advanced options for openSUSE Leap 15.2
Start bootloader from a read-only snapshot

So the installer's evident grub text customisations are lost, i.e. don't persist to the resulting install, and we have inadvertent use of on openSUSE "Mark" and loss of the OEM bit.

Sorry but I haven't bisected when this regression happened but I think it may have been around 1-2 months or so ago. This issue is not profile/architecture dependant in our case as it has been replicated in our x86_64 profile, again a 'Built on openSUSE" Leap 15.2 variant.

Expected behaviour

The Grub text Kiwi-ng customisation is I am assuming intended to persist in the resulting install. This we rely upon in order that our resulting installer and installs conform to the Trademark guidelines as per:

https://en.opensuse.org/openSUSE:Trademark_guidelines

As the user facing "openSUSE" in the resulting install's grub option looks like we are claiming to be "openSUSE" which is obviously not the case. Hence the prior welcome 'capability' within kiwi-ng to have this auto customised.

Steps to reproduce the behaviour

Build an oem type image using recent kiwi-ng, the config used in this case was from our as yet unreleased in binary form:

https://github.com/rockstor/rockstor-installer

Leap 15.2 host:

sudo zypper addrepo http://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_15.2/ appliance-builder
sudo zypper --gpg-auto-import-keys refresh
sudo zypper install git python3-kiwi btrfsprogs gfxboot
git clone https://github.com/rockstor/rockstor-installer.git
cd rockstor-installer/
sudo kiwi-ng --profile=Leap15.2.x86_64 --type oem system build --description ./ --target-dir /home/kiwi-images/

The resulting installer is found to exhibit this issue's behaviour, although given the referenced config is relatively vanilla it is assumed that all oem configs share this more recent regression.

OS and Software information

• KIWI version: More recent versions exhibit this behaviour, prior ones did not. First noticed on 9.21.7-lp152.1.1 Virtualization_Appliances_Builder (arm64) but could well have appeared before that. Also seen on 9.21.7-lp152.5.7.1 x86_64 Main Update Repository. And just now on 9.21.15-lp152.1.1 Virtualization_Appliances_Builder x86_64.
• Operating system: Leap 15.2 host and target
• OBS version: OBS is not used in this case as the sighted config is stand alone and hosted on a local openSUSE Leap 15.2 instance.

Apologies if this is down to a slip up in our own kiwi-ng configuration as per the indicated repo, but we have made no relevant changes to this config (bar default name changes etc) that would impact on this to my knowledge. But I have noticed a lot of work going on in kiwi-ng re grub in this suspected regression period.

@schaefi Sorry to bring yet another grub issue up here as I know it's not one of your most favoured elements but we find ourselves in a spot re inadvertent user facing use of an openSUSE Trademark and with our own multi year 'Build on openSUSE' endeavour nearing it's binary installer download release stage I am somewhat concerned with this regression. And from what I can tell this would affect all oem type installs.

Bar some prior issue reports/pre-release-fix-confirmations, I have no working knowledge of the kiwi-ng code but I'm happy to have a go if you could point me in the right direction. Although I'm assuming/hoping here, given it's prior function, this issue is a simple regression rather than a change in how this 'capability' is intended to work..

Thanks to all involved for the kiwi-ng project. It is almost singularly responsible for our ability to have our very own custom installer at all. A key element in 'The Rockstor Project''s effort to achieve sustainability in our open source endeavour.

[schaefi]

Thanks for the detailed report. Let me explain a bit of the background. Former versions of kiwi used its own grub config template and kiwi wrote its own grub.cfg based on that template. This template mechanism allowed to customize the boot menu entry as you described but it was also lacking a lot of the functionality that is provided by the grub2-mkconfig tool chain. In addition the produced grub.cfg file by kiwi was not conform to the standard produced by grub2-mkconfig and kiwi was disconnected with any upstream and/or distribution specific change in the grub config area.

Any distribution that uses grub2 has the tooling around grub2-mkconfig integrated into their system. An update of e.g the kernel automatically triggered calling grub2-mkconfig which overwrites the formerly written kiwi version of it and affected, for example the content of the custom menu entry and more.

In short we wanted to follow the standard as it is used on all major distributions. This means kiwi should also use grub2-mkconfig to create the grub.cfg file and not its own template. The initial conversation and if we can handle all parameters as before or not was discussed here:

• Refactor BootLoaderConfigGrub2 to use grub2-mkconfig #1194

Regarding the custom menu entries we know that grub2 is moving to the grub-spec that allows for customization, but not all distributions has made that move. Therefore the mentioned limitation came in and I can only point you to the grub documentation that says the following:

• https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html

grub-mkconfig does have some limitations. ...

Because of this we don't have an opportunity to specify the name of the menu entry such that the grub2 tooling would take care for it. As soon as the distributions switch to the grub-spec there is full control but that doesn't help you now.

The real solution to the issue lives in grub2 and the adaptions done by the distribution. To help customers and because we see
your pain we have prepared an appliance description that allows to specify a custom grub menu entry by using a small patch to the grub2 tool chain and by using the /etc/grub.d/... method to configure custom additions. Please find that image description here:

• https://build.opensuse.org/package/show/Virtualization:Appliances:Images/grub-custom-menu

Take a closer look at etc/grub.d/42_custom and grub_10_linux.patch in the root.tar.gz overlay tarball.
You can use the same concept to adapt your image description such that after install the boot menu looks like you wish.
Please note for the grub menu used for the install ISO image kiwi uses a grub template and will continue to do so. This is because the install iso is a kiwi managed extension and not a user OS. Therefore we are free how to create that boot menu and you can expect this concept to stay.

I apologize if this creates a bit of an overhead on your side but I also hope you understand that we should operate within the core standard tools for the OS image and not let kiwi apply its own way.

Let me know if this helps or if we can further assist

Thanks

[phillxnet]

@schaefi Thanks for an excellent run down on the current and planed state of play. And thanks for the pointer to the example work around. Totally agree/understand it's best, if possible, to resource standard tools in upstream and in a project like kiwi, which has in effect several distros as, in part, it's upstream this is a particularly challenging task. I'll have a proper look and see if we can use this. Thanks again for all your efforts here and for providing the example work around. Much appreciated.

As soon as the distributions switch to the grub-spec there is full control ...

That's good to know. And will be a welcome standardisation of grub config.

Cheers.

I'll report back here once I've fathomed your example and had a go at it's application in our own config. It may help others facing the same issue.

[phillxnet]

@schaefi Quick update in case it helps others landing on this issue with similar requirements.

For our current purposes a simply:

#======================================
# Apply grub config
# Setup Grub Distributor option
#--------------------------------------
echo >> /etc/default/grub
echo "# Set distributor for custom menu text" >> /etc/default/grub
echo 'GRUB_DISTRIBUTOR="Rockstor NAS"' >> /etc/default/grub
echo >> /etc/default/grub

in config.sh

looks to have address the change in behaviour detailed earlier in this issue. However this may only pertain to our particular target distro of Leap 15.2. But this option is listed as a standard grub-mkconfig one.

https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html

‘GRUB_DISTRIBUTOR’
Set by distributors of GRUB to their identifying name. This is used to generate more informative menu entry titles.

Not sure of etiquette re closing this issue, or if it should be left open for others experiencing the same thing until the anticipated grub2 move to the grub-spec and kiwi-ng's possible re-adoption of customising the installed instance re grub menus.

Thanks again for your excellent project and detailed pointers re my little problem.

[schaefi]

Hi, thanks for your feedback. I think you are mentioning a very good point. Not handling GRUB_DISTRIBUTOR was explicitly requested by the following issue:

• kiwi sets GRUB_DISTRIBUTOR again #1416

If I read through the history of this issue I actually don't understand why we followed the request. If GRUB_DISTRIBUTOR is not set the menu title is created from the information from /etc/os-release but that doesn't mean other people want to set another name. Also the fact that yast doesn't set it is immaterial to the request of customers who wants another menu entry name.
The more I think about it the more I think we did a mistake at that time :)

I also think we could make both sides happy. In kiwi there is this optional attribute:

<image ... displayname="Rockstor NAS"/>

If set kiwi should set GRUB_DISTRIBUTOR or handle the value in the boot/loader/entries/*.conf (grub spec way).
Only if no such information is present we just go with the default which is taking the title from os-release

From this perspective I would say parts of #1416 should be reverted

We will discuss this on the next sprint

Thanks

[schaefi]

Not sure of etiquette re closing this issue

imho this needs to stay open. We can make the user experience better ;)