SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Last edited by lostintime; 12-30-2023 at 03:10 PM.
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.
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.
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!
Last edited by Didier Spaier; 12-31-2023 at 09:03 AM.
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.
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.
Happy New Year!
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.
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.
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.
Last edited by Didier Spaier; 01-03-2024 at 02:46 AM.
Reason: s/does fit too well/does not fit too well/
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.