LinuxQuestions.org
Visit Jeremy's Blog.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-30-2023, 09:46 AM   #16
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,972

Rep: Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551

Quote:
Originally Posted by Daedra View Post
Sure, here is the 09_slackware_linux file I use.
What a great idea, why didn't I think of this. keeps thing simple.

Last edited by chrisretusn; 12-30-2023 at 09:48 AM.
 
Old 12-30-2023, 09:57 AM   #17
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,362

Original Poster
Rep: Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075
Quote:
Originally Posted by Daedra View Post
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 ;-)
 
Old 12-30-2023, 02:55 PM   #18
lostintime
Member
 
Registered: Dec 2021
Posts: 192

Rep: Reputation: Disabled
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.

Last edited by lostintime; 12-30-2023 at 03:10 PM.
 
2 members found this post helpful.
Old 12-30-2023, 03:37 PM   #19
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,058

Rep: Reputation: Disabled
Quote:
Originally Posted by lostintime View Post
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.
 
Old 12-31-2023, 07:49 AM   #20
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,972

Rep: Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551
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.
 
1 members found this post helpful.
Old 12-31-2023, 09:01 AM   #21
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,058

Rep: Reputation: Disabled
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!

Last edited by Didier Spaier; 12-31-2023 at 09:03 AM.
 
Old 12-31-2023, 09:58 AM   #22
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers)/Windows 11/Ubuntu (workstations)
Posts: 608

Rep: Reputation: 350Reputation: 350Reputation: 350Reputation: 350
Quote:
Originally Posted by chrisretusn View Post
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
 
Old 12-31-2023, 10:58 AM   #23
Windu
Member
 
Registered: Aug 2021
Distribution: Arch Linux, Debian, Slackware
Posts: 590

Rep: Reputation: Disabled
Quote:
Originally Posted by teoberi View Post
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
 
Old 12-31-2023, 11:05 AM   #24
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,972

Rep: Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551Reputation: 1551
Quote:
Originally Posted by Didier Spaier View Post
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.
 
1 members found this post helpful.
Old 12-31-2023, 05:19 PM   #25
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,058

Rep: Reputation: Disabled
Quote:
Originally Posted by Didier Spaier View Post
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.
 
Old 12-31-2023, 06:05 PM   #26
USUARIONUEVO
Senior Member
 
Registered: Apr 2015
Posts: 2,335

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
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.

Last edited by USUARIONUEVO; 12-31-2023 at 06:45 PM.
 
Old 12-31-2023, 06:27 PM   #27
USUARIONUEVO
Senior Member
 
Registered: Apr 2015
Posts: 2,335

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
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.

Last edited by USUARIONUEVO; 12-31-2023 at 08:01 PM.
 
Old 01-02-2024, 05:20 PM   #28
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,058

Rep: Reputation: Disabled
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/
 
Old 01-02-2024, 06:04 PM   #29
marav
LQ Sage
 
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,362

Original Poster
Rep: Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075Reputation: 4075
Quote:
Originally Posted by Didier Spaier View Post
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
 
Old 01-03-2024, 03:11 AM   #30
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,058

Rep: Reputation: Disabled
Quote:
Originally Posted by marav View Post
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.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Infinite Grub Loop: GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB... beeblequix MEPIS 2 11-02-2013 10:56 PM
Any feedbacks on Tiscali? Zippelin General 6 05-01-2008 06:23 PM
Booting my new ubuntu install = "GRUB GRUB GRUB GRUB GRUB" etc. dissolved soul Ubuntu 2 01-13-2007 12:55 PM
wbel feedbacks pcandpc General 4 05-28-2005 10:19 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:20 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration