I like the fact that slackware doesn't auto-update the grub.cfg with updates. I multiboot a few distos and use slackware grub as the main bootloader by editing the grub.cfg for a customized grub menu and I don't have to worry about my grub.cfg edits getting written over by an update.

2 members found this post helpful.

@LuckyCyborg I understand what you said.
Look my opinion: I m a farmer.I was clever and good in school as kid. But I dont have university studies because
I was from a poor family... I got my first pc when I was 25. I worked one year to pay its price. Those days was first time out windoz xp. I never liked but without internet connection ... thats what I had...
From windows I learned nothing. Just clicks...
The first day that isdn internet came to our place I pay for that and the second day I boot linux.
No documentation, no nothing, I had big problems... until I hear about a new distro, ubuntu
I was for some years one of best ubuntu supporters in my country. Because in easy way I installed linux in my pc and it was easy working and I had support from lot people in forums, irc etc...
From 1 to 100 I learned 10 about linux from ubuntu. And that distro was the reason to stay in linux....
Because things was easy and I had support for everything from the community.

But I was in 10 for years... until I found slackware. I installed Slackware first time because I wanted to be a hacker
well I never became a hacker but I never uninstalled slackware also!
First year in slackware from from 10 to 100 , I learned 40 !!! and that because of Slackware.
Now I think I m ok with my learns about (60-70) and always I m learning something from all of you...

I want to say that some things is not easy in Slackware because that is the philosophy of the project!
To be KISS and complicate together. To boot and not booting.
It was the only distro for me , a man without studies, to help me learn something with this philosophy...!

I really want the same with you for bootloader and the future of slackware, and yes for our BDFL is not more than one hour work to make this and others more easy for users...
what can I say is: He dont want to do it for some reason(s) or its not the time yet...
Thats slack! The Slack we all love
The best linux disto ever!.

ps(funny): for those guys who said that slackware can boot and not boot at the same time, ask them to do this at their linux-distros: run Gnome43 and KDE PLASMA at the same time together in their famous distros in bare metal not VM...

2 members found this post helpful.

Oh, yeah? And what does the Slackware installer by pushing in the front of unsuspectful user the liloconfig or eliloconfig configuration screens? This is not a software PUSH in the users mouth? Or in the case of LILO and ELILO case is just "justice" ?

With all respect, I for one I believe that we should end with those truly double standards and do what it should be done: a grub2config script to be made and the Slackware installer to show it to the users. I do not advocate the removal of elilo and lilo - but those who want them can find them easily, without being pushed on every installation.

Like I said, I have already invented something like this, and it's NOT a great altering of pkgtools. Basically, it's just about touching (yep, it's empty) a file: /install/slack-noupgrade when a package is made, then when the package is installed, a new particular line is inserted in the package record file. Finally, the upgradepkg is modified a bit, to check for this particular line in the package record file.

When this like is found, it does NOT remove the processed package, but in only installs (in parallel) the new one. So, instead of install-new/remove-old/install-new will do only install-new package.

That's all and it's not specific to the kernel packages.

The trick to have a consistent kernel package is another: the generic kernel and it's modules to be shipped in a single package, with saying goodbye to the huge kernel. This way, with a package containing both the kernel and its modules, any time you install or remove it, you can just call the update-grub script.

Exactly. And in the removal scripts too.

Following other distros in their quest for profit and chain users into one specific solution seems like oppression to me.
I'm well used to compiling vfat/exfat and ext2/ext3/ext4 inside the kernel, so not sure why all the drama.
And a package doinst could simply do a 'vmlinuz' and /opt/vmlinuz-$VERSION and then move old 'vmlinuz' to /opt/vmlinuz-$VERSION.bak instead of relying on symlinks no?
But I'm fine with how it works right now, no complaints so I don't suggest nothing. It's probably up to those who have complaints to develop own solutions.

In fact, the (auto-)generation of /boot/grub/grub.cfg is controlled on every word and line by the scripts from /etc/grub.d and /etc/default/grub

The recommended way (by the GRUB2 authors) for having a "customized grub menu" is to use those scripts and the associated config file.

In fact, you should NEVER edit /boot/grub/grub.cfg by hand, as it's said at its beginning.

Yes, not in other distros because the grub.cfg gets overwritten with updates, unless you take extra steps to prevent it from happening, with slackware it isn't an issue, the only other disro where it isn't an issue if one can call it a distro is linux-from-scratch

Edit from the grub manual:

With all respect, you do it wrong! Heck, did you ever read the famous file /etc/grub.d/40_custom ?

Yep, there you can add as much many custom entries as you like, all preserved when grub-mkconfig is executed.

Or even simpler, just put you custom entries into a file named /boot/grub/custom.cfg and it will be used as is, thanks to /etc/grub.d/41_custom script.
And I do not talked about "os-prober" and any other auto-magic.

I for one, I do not believe in auto-magic, but on NOT making people to do mechanical repetitive tasks better done by a machine.

Generating an initrd based in a /etc/mkinitrd.conf file or looking in /boot directory for kernel files are things which could be done well by a machine, avoiding situation as described by OP.

But when that "one specific solution" is named LILO or ELILO, that's "freedom" , right?

What I love the Slackers' newspeak...

In fact, that's exactly the problem: that "one specific solution" proposed as bootloader by the Slackware installer to OP.

Do you really believe that the OP loves ELILO with passion? That he chosen ELILO out of love for it?

I don't think so, he installed ELILO just because this "one specific solution" was proposed by the Slackware installer.

You are right, I did read it before upgrading and yes a warning there could be helpful.

This is a surprise to me however it makes me love Slackware more through all above kind advices, thank you all.

I have downloaded this package however my whole /boot/efi/EFI directory is missing now which means no elilo.conf file, so I have a question: How did the computer boot successfully without elilo.conf file?

Oh I have a USB stick that has the Slackware 15.0 (kernel version is 5.15.19 too), I used this USB to install the system, can I boot into the computer from this USB stick and fix the problem?

None of the packages, installer, kernel or otherwise, create dependency on LILO scripts.
GRUB2 includes exploitable scripts, which became a dependency of kernel packages in other distributions, creating a new attack vector where previously there were none.
So I disagree, LILO is optional part of the install process, and you're pushing (for few years now) to include remotely exploitable features.

1 members found this post helpful.

The fact that you can't mount the /boot/efi partition, does not mean that that partition is empty. It isn't.

The files are there including that elilo.conf, so you can boot the system with the old kernel, just that they aren't accessible for you.

I hate when that happens.
Yes, I'm well aware of the the 40_custom and custom.cfg files.

And how the heck arrived the OP to install ELILO?

You don't see that he has no idea how it works, so his personal preference toward it is excluded?

My wild guess: because that ELILO configuration was proposed by the Slackware installer.

Out of curiosity, you are kind to show me what parts of /etc/grub.d scripts or any other scripts included by GRUB2 have remotely exploitable features?

Unless you can show me to lines on scripts those exploits, what you say are "unconfirmed claims" to scare the uninformed people, gracious ignoring that there are people who can read Bash scripts. BTW, I speak Bash too.

Heck, those "remotely exploitable features" in Bash scripts, that's what I will call News...

yes, if you updated the /boot/initrd.gz before rebooting, at the console mount the root partition to /mnt, mount the efi partition to /mnt/boot/efi, copy the generic kernel from /mnt/boot/ to /mnt/boot/efi/EFI/Slackware/vmlinuz and the initrd.gz from /mnt/boot/ to /mnt/boot/efi/EFI/Slackware/. If you didn't run mkinitrd before rebooting, you will need to chroot into the system from the usb to fix.

1 members found this post helpful.

OK Captain Obvious, but he was given option not to install LILO or ELILO at all.
For all we know, he could've easily opted to chroot into install and setup a PLOP bootloader.
How is that forcing ELILO on him, when he selected ELILO by choice and installed it by choice?
But if the doinst.sh did run GRUB scripts while installing the kernel, it would no longer be his choice.
How do you not understand this? You only act Cpt. Obvious but are actually Lt. Roll in disguise.

And regarding the possible exploit, sure any script can create one but it doesn't mean the kernel package has to create one too.