0

I'm running a VPS with Alma Linux 8.8.0 with WHM/cPanel and 60 or so users, multiple websites etc.

I'm regularly seeing these in the server 'messages' log:

Nov 16 11:39:01 ark grub2-set-bootflag[312712]: Error setuid(0) failed: Operation not permitted
Nov 16 11:39:01 ark systemd[312226]: grub-boot-success.service: Main process exited, code=exited, status=1/FAILURE
Nov 16 11:39:01 ark systemd[312226]: grub-boot-success.service: Failed with result 'exit-code'.

This seems to have been a known issue with grub in the past - I found this developer discussion from 2020 where a resolution is discussed:

https://bugs.mageia.org/show_bug.cgi?id=27269

They suggest changing a line in file

/usr/lib/systemd/user/grub-boot-success.service

From:

ExecStart=/usr/sbin/grub2-set-bootflag boot_success

To:

ExecStart=/usr/bin/pkexec /usr/sbin/grub2-set-bootflag boot_success

But later in the discussion say that this resolution triggers a password input request (which is no good to me as this is a system run command) and go on to mention that this bug has been resolved.

My system is running GRUB2:

[root@myserver systemd]# grub2-install --version
grub2-install (GRUB) 2.03

Questions:

a) Should I upgrade Grub to 2.06 (which I believe is the latest version) and if so how can I safely do this - of course I don't want anything at all to risk my system becoming unbootable.

b) Should I edit those files to the 'correct?' alternate line or will that just make the system need password input? (I tried it and saw in the log Nov "Main process exited, code=exited, status=127/n/a" meaning 'command not found')

c) Should I do nothing and it'll be fine?

Many thanks!

1 Answer 1

0

I've built a fix for this which is not 'ideal', and I don't know if it's needed, but it works (and removes the errors from the log).

In the file:

/usr/lib/systemd/user/grub-boot-success.service

Change:

ExecStart=/usr/sbin/grub2-set-bootflag boot_success

To:

ExecStart=touch ./grubbootsuccessflag

This works because the grub-boot-success.service is being run within the filesystem of the user that logged in, and thus triggering the two-minute timeout prior to the running of this service. This 'flag' file is then created in the user's home directory, owned by that user.

Then create a cron task to run the following batch script as root every minute:

removed=$(find /home/ -name 'grubbootsuccessflag' -delete -print)
if [[ -n "$removed" ]]; then
    /usr/sbin/grub2-set-bootflag boot_success
    echo "BOOT SUCCESS $removed"
fi

(thanks to https://stackoverflow.com/users/9072753/kamilcuk for this script)

This script searches all user home directories (and inefficiently, ALL other directories in '/home/') for the flag which if found, is deleted, and then the command that was not working in the 'service' is then run by root with full setuid(0) permissions.

Notes:

  • This could be made more efficient - searching the entire 'home' folder and subfolders every minute for this match is not ideal.
  • I'm unsure if a re-boot of the actual server itself also will create a 'grubbootsuccessflag' somewhere other than the 'home' folder.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .