LinuxQuestions.org - Grub 2.12 feedbacks

LinuxQuestions.org (/questions/)

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Grub 2.12 feedbacks (https://www.linuxquestions.org/questions/slackware-14/grub-2-12-feedbacks-4175732263/)

Quote:

Originally Posted by Daedra (Post 6473474)

Sure, here is the 09_slackware_linux file I use.

What a great idea, why didn't I think of this. ;) :doh: keeps thing simple.

Quote:

Originally Posted by Daedra (Post 6473474)

Sure, here is the 09_slackware_linux file I use.
https://raw.githubusercontent.com/md...lackware_linux

I also use it
I was looking for this line

Code:

linux=$(echo "$mylist" | version_sort -r | head -n 1)

Thanks ;-)

Quote:

So(re)move the .orig or the .new, case occurring.

Using chmod -x will do the trick without renaming files. :)

Quote:

Sure, here is the 09_slackware_linux file I use

I'm sure Pat is tinkering with the grub.d scripts, but I was hoping to see some kind of glimpse of something similar. For example, a simple patch that avoids adding an initrd line with the huge kernels:

Code:

--- /etc/grub.d/10_linux

+++ /etc/grub.d/10_linux_slackware

@@ -227,7 +227,7 @@

  done

 

  initrd=

-  if test -n "${initrd_early}" || test -n "${initrd_real}"; then

+  if test -n "${initrd_early}" || test -n "${initrd_real}" && test -z `echo $basename | grep huge` ; then

    initrd="${initrd_early} ${initrd_real}"

 

    initrd_display=

Another annoyance with /etc/grub.d/10-linux is the presumption of creating menuentry items based on the kernel file date stamp (version_find_latest function in /usr/share/grub/grub-mkconfig_lib). This makes sense outside Slackware because almost all other distros retain multiple versions of kernel packages as fallbacks. The most recent kernel is presumed to be the one desired at the beginning of the menu list. This presumption is a tad messy with Slackware because of the huge kernel and alphanumeric sorting. When updating or installing kernel packages with a package manager, the huge kernel is always installed after the generic kernel. The huge kernel then is seen as the most "recently installed" kernel. While the generic kernel now is similar to the huge kernel, many people likely will still use an initrd. The default boot selection can be changed in /etc/default/grub, but this "most recently installed" presumption seems to work against Slackware.

I am hoping that updating the initrd gets automated. Not to argue that "we should do this too," but this is automated in every other distro I have seen. Perhaps this can be done with the generic doinst.sh script rather than grub scripts. I accept that automation is not the normal approach in Slackware, but the days of "Remember to update lilo.conf" are now behind us. For myself, I still tend to be cautious with kernel packages by installing new packages rather than upgrading, but automating some things like this is what most of the "bell curve" type users expect.

Just observing and commenting, not demanding anything. :) Much of this has been hashed elsewhere. Although I have used GRUB for more than 20 years, I long have maintained my grub.cfg manually with my own scripts because of the anomalies and presumptions of how most other distros function. Hopefully, how Pat decides to patch the grub scripts will get merged back upstream.

Quote:

Originally Posted by lostintime (Post 6473631)

Using chmod -x will do the trick without renaming files. :)

Yes, thanks for the heads-up. I have corrected the quoted post, also mentioning that only the .orig scripts are run by grub-mkconfig if executable, not the .new ones.

I took the plunge, grub-2.12 working ok on bare metal (BIOS computer) and 3 VirtualBox machines, two are BIOS, one is EFI.

For the BIOS machines (both metal and VM) , only 00_header and 09_slackware (a modified 10_linux) are set to execute ran 'grub-install /dev/sda' for good measure and then 'grub-mkconfig -o /boot/grub/grub.cfg'.

For the EFI machine, not as smooth. 'grub-install /dev/sda' results (sometimes only with the last line):

Code:

Installing for x86_64-efi platform.

EFI variables are not supported on this system

EFI variables are not supported on this system

grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

I seems with VirtualBox EFI, (this applied with 2.06 also) the --removable option to grub-install works. I found this explanation here.

Quote:

The --removable option can be used to install GRUB's PE32+ executable to the \EFI\BOOT directory of the ESP with name BOOTX64.efi (making its full pathname /efi/EFI/BOOT/BOOTX64.efi if the ESP is mounted at /efi). This is only recommended when installing to a removable medium, or when installing on a computer with limited UEFI firmware that does not support boot entries with arbitrary pathnames very well.

Using 'grub-install /dev/sda --removable' does the job:

Code:

Installing for x86_64-efi platform.

Installation finish. No error reported.

In /etc/grub.d I set to execute 00_header 09_slackware 25_bli 30_uefi-firmware, the rest not.

The one things I noticed between 2.06 and 2.12 are:
2) Even though I have these set in /etc/default/grub, Console is now set to 128x48, it was set to 100x37. This is only with the EFI VM.

Code:

GRUB_GFXMODE=800x600x32

GRUB_GFXPAYLOAD_LINUX=800x600x32

With both 2.06 and 2.12 I wish I could set my boot menu to 800x600 with the EFI VM apparently this cannot be done. Works with the BIOS VM machines. Why? My host monitor resolution is 1360x768.

Please do not install /etc/grub.d/25_bli as is.

Follow-up of post #13

When installing the package in -current (and mine, currently ...) as /etc/grub.d/25_bli is a new file, 25_bli.new is converted to 25_bli.

However this script includes this code snippet:

Code:

cat << EOF

if [ "\$grub_platform" = "efi" ]; then

  insmod bli

fi

EOF

So if the user reboots without having run grub-install (which by default copies all modules to /boot/grub/x86_64.efi if booted in EFI mode or using the option -target x86_64.efi) insmod fails because the module is not available, so booting fails too.

To avoid that I suggest to either keep the .new extension when installing the package, or get rid of it (which could hurt a few systemd fans).

This will probably render unnecessary to run grub-install just after having installed the package, I will test to check.

It took me a way too long time to find the origin of the issue, my excuse being that I will be 75 very soon :(

Happy New Year!

Quote:

Originally Posted by chrisretusn (Post 6473773)

For the EFI machine, not as smooth. 'grub-install /dev/sda' results (sometimes only with the last line):

Code:

Installing for x86_64-efi platform.

EFI variables are not supported on this system

EFI variables are not supported on this system

grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

I seems with VirtualBox EFI, (this applied with 2.06 also) the --removable option to grub-install works. I found this explanation here.

Using 'grub-install /dev/sda --removable' does the job:

Code:

Installing for x86_64-efi platform.

Installation finish. No error reported.

I had the same problem in VirtualBox EFI.
The problem was with efivars filesystem.

Code:

mount -t efivarfs none /sys/firmware/efi/efivars

Quote:

Originally Posted by teoberi (Post 6473798)

I had the same problem in VirtualBox EFI.
The problem was with efivars filesystem.

Code:

mount -t efivarfs none /sys/firmware/efi/efivars

I would think for Slackware current that was fixed in March 2023: https://git.slackware.nl/current/com...739fbf08d5aeba

Quote:

Originally Posted by Didier Spaier (Post 6473788)

When installing the package in -current (and mine, currently ...) as /etc/grub.d/25_bli is a new file, 25_bli.new is converted to 25_bli.

However this script includes this code snippet:

Code:

cat << EOF

if [ "\$grub_platform" = "efi" ]; then

  insmod bli

fi

EOF

It's 01:07 in 2024 for us. Happy New Year!

For me 25_bli was installed as "25_bli" since there was no existing 25_bli with the execute bit set. For my EFI machine, I left it as it, for my BIOS systems I just removed the execute bit.

Since this was an upgrade to grub, I went with running grub-install.

Quote:

Originally Posted by Didier Spaier (Post 6473788)

This will probably render unnecessary to run grub-install just after having installed the package, I will test to check.

Bad luck. I tested in a Qemu VM (that comes handy with the ability to take and restore snapshots), upgrading from the previous grub package to a new one without the file /etc/grub.d/25_efi, after the upgrade the VM rebooted to the firmware setup menu. Chrooting from an installer and running grub-install fixed that, but only if writing a boot entry in the firmware's NVRAM (not with the option --no-nvram of the grub-install command.

Maybe this is liked to specific context when upgrading, but I think it's safer to run grub -install in doinst.sh, the target drive being the one mounted as /boot/efi in /etc/fstab. Caveat: I didn't test yet the case where the system is installed in a removable device.

I upgrade grub to test it , only rare here is on konsole i see this messages

Quote:

version_find_latest() is deprecated. Use version_sort() instead.
version_test_gt() is deprecated. Use version_sort() instead.

That variables arrives from a file in grub package...

Quote:

/usr/share/grub/grub-mkconfig_lib

says variable is deprecated, but he is the provider ... nice joke.

I think i have some residual files from old grub package ....i continue investigating this.

EDIT: After delete all my files under /etc/grub.d and reinstall grub from /testing , all is okey.

Rebuikt grub2.12 package for Slint64-15.0 to avoid "boot fails aftre upgrade"

The hint from Arch in post #5 is good, however not everyone reads the messages displayed when upgrading.

For this reason I have rebuilt the package (sources here) that now installs a file /usr/sbin/post-upgrade-grub, run at the end of doinst.sh and pasted below:

Code:

#!/usr/bin/bash

cd /

# Re-install GRUB if possible.

grubefi() {

    # Is /boot/efi mounted? then EFIMOUNTED is the path to the EFI partition, else null.

    EFIMOUNTED=$(findmnt -no source /boot/efi)

    # If /boot/efi is not mounted, mount it

    [ ! "$EFIMOUNTED" ] && mount /boot/efi

    unset EFI

    if [ -d /sys/firmware/efi ]; then

        # Is /sys/firmware/efi/efivars mounted?

        EFIVARSMOUNTED=$(findmnt /sys/firmware/efi/efivars)

        # If /sys/firmware/efi/efivars is not mounted, mount it.

        [ ! "$EFIVARSMOUNTED" ] &&  mount -t efivarfs none /sys/firmware/efi/efivars

        EFI=yes

    fi

    # we will replace the last installed Slint OS loader in the ESP, if any.

    # There should be one, but you never know.

    find /boot/efi/EFI -name "slint*" -exec  ls -1t -d {} +|sed "s;.*/;;"|head -n1 > "$BOOTLOADERID"

    blid=slint-$(cat "$SLINTVERSION")

    [ -s "$BOOTLOADERID" ] && blid=$(cat "$BOOTLOADERID")

    if [ "$EFI" ]; then

        echo grub-install --bootloader-id="$blid" /dev/"$DRIVENAME"

        grub-install --bootloader-id="$blid" /dev/"$DRIVENAME"

        echo "$?" > "$RETEFI"

    else

    echo grub-install --bootloader-id="blid" --target=x86_64-efi --no-nvram /dev/"$DRIVENAME"

        grub-install --bootloader-id="$BOOTLOADERID" --target=x86_64-efi --no-nvram /dev/"$DRIVENAME"

        echo "$?" > "$RETEFI"

    fi

}

grublegacy() {

    # We reinstall GRUB in Legacy mode unless the root partition be in a GPT

    # and there be no BIOS boot partition in the drive of the root partition.

    PARTTYPE=$(lsblk -lno pttype "$DRIVEPATH"|head -n 1)

    # How many BIOS Boot partitions in this drive?

    BIOSBOOTCOUNT=$(lsblk -lno name,parttypename "$DRIVEPATH"|grep -c 'BIOS boot$')

    [ "$PARTTYPE" = "gpt" ] && [ "$BIOSBOOTCOUNT" -eq 0 ] && return

    echo grub-install --target=i386-pc "$DRIVEPATH"

    grub-install --target=i386-pc "$DRIVEPATH"

    echo "$?" >"$RETLEGACY"

}

# Main

LANG=C

RETEFI=$(mktemp)

RETLEGACY=$(mktemp)

BOOTLOADERID=$(mktemp)

SLINTVERSION=$(mktemp)

unset blid

cut -d" " -f 2 /etc/slint-version >"$SLINTVERSION"

# Grub needs to be reinstalled in the drive of the root partition, if installed there.

# If grub is not installed in this drive, bail out, as another OS loader than ours is used

[ ! -f /boot/grub/grub.cfg ] && exit

[ ! -d /boot/grub/x86_64-efi ] && [ ! -d /boot/grub/i386-pc ] && exit

# We will reinstall GRUB in drive of the root partition

# Find the path of the root partition, the name and path of its drive. 

ROOTPART=$(findmnt -lno source /|sed 's;[[].*;;')

DRIVENAME=$(lsblk -lno pkname "$ROOTPART")

DRIVEPATH=/dev/$DRIVENAME

# Is /boot/efi listed in /etc/fstab?

EFILISTED=$(grep /boot/efi /etc/fstab)

echo 0>"$RETEFI"

echo 0>"$RETLEGACY"

# We only reinstall. A Slint system has had GRUB installed during its installation

# then /boot/grub/x86_64-efi and/or /boot/grub/i386-pcs should exist.

[ "$EFILISTED" ] && [ -d /boot/grub/x86_64-efi ] && grubefi

[ -d /boot/grub/i386-pc ] && grublegacy 

if [ ! "$(cat "$RETEFI")" = 0 ]; then

    echo "!!!WARNING!!! installing GRUB in EFI mode failed!"

    echo "Please find the issue and solve it before rebooting!"

fi

if [ ! "$(cat "$RETLEGACY")" = 0 ] && [ ! -d /sys/firmware/efi ] ; then

    echo "!!!WARNING!!! installing GRUB in Legacy mode failed!"

    echo "Please find the issue and solve it before rebooting!"

fi

[ "$(cat "$RETEFI")" = 0 ] && [ "$(cat "$RETLEGACY")" = 0 ] && /usr/sbin/update-grub

  rm  "$RETEFI" "$RETLEGACY" "$BOOTLOADERID" "$SLINTVERSION"

A few edits would be needed for Slackware and I realize that automatizing such tasks does not fit too well with Slackware, but here goes. Anyway the script could be adapted to then shipped in Slackware, even if not run by doinst.sh

Incidentally this makes useless to remove 25_bli from /etc/grub.d.

I have just uploaded this package as shown on top of our main ChangeLog.

Quote:

Originally Posted by Didier Spaier (Post 6474257)

A few edits would be needed for Slackware and I realize that automatizing such tasks does fit too well with Slackware, but here goes. Anyway the script could be adapted to then shipped in Slackware, even if not run by doinst.sh

Yes, but if something or everything goes wrong after the upgrade, the things also need to be automatized in case of rollback. Actually, this is not the case

Quote:

Originally Posted by marav (Post 6474264)

Yes, but if something or everything goes wrong after the upgrade, the things also need to be automatized in case of rollback. Actually, this is not the case

What can be wrong after the upgrade, other than a system not booting? If the system where the upgrade occurred does not boot (which the script attempts to avoid) usually solving the issue needs to first mount the root partition from another installed system or an initramfs (installer or live system), do the usual bind mounts, chroot, mount what needs to be mounted from there then type commands depending on the context and the issue. What part of this can be automatized? Further, is there cases where the package should be downgraded (is that what you mean by "rollback")? This can't be completely ruled out but then I hardly see how to automatize this rollback, as a script would first need to locate the previous package to be re-installed.