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.
Get slackpkg to run lilo or eliloconfig after a Kernel Update so there will no be kernel panic if the laptop loses power or user forgetting to run it.
This seems easy on the surface, but it is nigh on impossible to achieve on a distribution wide scale. The permutations of bootloader, huge kernel, generic kernel with mkinitrd handled by mkinitrd.conf or directly. whether the user wants to replace the existing or retain the previously working configurations become too great.
The pfficial 'slackpkg' tool defaults to outputting a reminder and leaves it to the user. On balance, I think this is best.
I accept the argument that making slackpkg smarter to avoid problems such as forgetting to run mkinitrd and lilo can be a boon.
The design of slackpkg allows for local customisation of the lookkernel() function. This is an example which I have used successfully for many years on systems using lilo running the generic kernel with an initrd.
Only the users who require this handholding process may want it, but that leaves each user with potential bugs.
Exactly! So why not have a script that everyone can use (and find/fix bugs in) that is included with the distro, and maybe even be a part of slackpkg? If it is not mandated to use it (I don't know how they could mandate it), those who want this handholding (many want it, few require it) can use it and others can ignore it.
Quote:
Originally Posted by elcore
By that definition, it's also package manager job to handle BIOS.
How do you figure? Installing Slackware updates doesn't affect the BIOS. UEFI booting is only one that requires interaction with the motherboard's firmware, and it does not ever need to be "tampered" with once it is pointed to the EFI stub. The EFI bootloader handles any updates after that without requiring updates to the firmware. With legacy booting, you need to update the MBR, which is not the BIOS, to point to the new kernel/initrd sectors.
Quote:
Originally Posted by elcore
Anyway, boot sectors aren't packages, and package distribution software should not tamper with them for security reasons.
The installer is "tampering" with them, so why shouldn't the updater? The installer creates an initrd and does the proper steps to ensure a proper boot at the end (either running lilo or registering the EFI stub to the firmware). If the installer does it, why not the updater? (The installer doing those functions is optional and I'm not saying that using this potential functionality should be mandatory when using slackpkg.)
Quote:
Originally Posted by elcore
Of course there's people like debian council who think it is, but it's offtopic here since Slackware generally does not hold users' hands.
What is slackpkg if not holding users' hands? Users could just download the patches/ directory and run upgradepkg on packages themselves. Why do we have {install,upgrade}pkg? Those hold hands when we could just untar the packages on the root directory. Why even have packages? Users can run the build scripts themselves? Why even have build scripts when users can use the build systems from the programs themselves?
Every single level of automation will have someone complain and someone happy. Some will complain it is doing too much while others will complain it's not doing enough. Slackware has always been awesome in this regard by giving those who want it more automation but staying out of the way for those that don't want automation. I don't see anything bad with adding proper kernel update support to slackpkg as long as it remains optional. Those who have been asking for it for years will be happy. Those who don't want it can simply leave it disabled. I don't see this as anything other than a win-win.
Installing Slackware updates doesn't affect the BIOS.
Well as it turns out, it does not affect the boot sector either, and IMO it shouldn't affect it for obvious reasons.
If it did affect it, it'd be kinda hard to ignore it.
Quote:
Originally Posted by bassmadrigal
I'm not saying that using this potential functionality should be mandatory when using slackpkg.
Then, we agree on something. But see how it was suggested and for what reasons.
To fix a forgetful user, and a power failure, it'd have to be run automatically.
Which is a bad idea, and don't take my word for it, ask an auditor why it's bad to bolt low level disk access to networked program.
Those aren't contradictory. They aren't even really related. If further automation is added to slackpkg, it will likely be optional for users to want to use it.
How is that related to Slackware updates don't affect the BIOS? They don't... ever. There isn't even a possibility of it to affect the BIOS if additional functionality was added to slackpkg.
Quote:
Originally Posted by elcore
Well as it turns out, it does not affect the boot sector either, and IMO it shouldn't affect it for obvious reasons.
If it did affect it, it'd be kinda hard to ignore it.
Are you missing where it would be optional? Just as updating kernels through slackpkg is optional?
Quote:
Originally Posted by elcore
Then, we agree on something.
You misunderstand again. If functionality to properly and fully update kernels and allow a reboot is added to slackpkg, it should not be mandatory to use. Just like it isn't mandatory to update kernels through slackpkg... but the functionality is there, and I have no issues with functionality being added to slackpkg to enable updating elilo or lilo, as long is its use is optional.
Quote:
Originally Posted by elcore
But see how it was suggested and for what reasons.
To fix a forgetful user, and a power failure, it'd have to be run automatically.
Oh, you mean "automatically" like running slackpkg upgrade-all? Or maybe it could even be a separate slackpkg upgrade-kernel command to ensure users don't accidentally upgrade their kernel (but if it is handled properly by slackpkg, there should be no issue with upgrading the kernel).
Not to mention pretty much all modern systems support UEFI and that doesn't need low level disk access to update the boot process. It just needs to copy the new kernel (and optionally initrd) to the EFI partition and ensure the config is pointing to it (which is easy if it's always named the same). Once eliloconfig is ran during installation, it never needs to be run again (provided you don't change the location to the EFI stub).
And for those running legacy, why is it ok for the installer to have low level disk access but not the updater? You already showed that some low level disk access is handled outside of the installer (partitioning), so why are you ok with some low level disk access in the installer and not in the updater?
How is that related to Slackware updates don't affect the BIOS? They don't... ever. There isn't even a possibility of it to affect the BIOS if additional functionality was added to slackpkg.
Of course they don't affect it, even though the updater could theoretically download a BIOS image and execute code to flash it.
Only reason why I even mentioned BIOS is because you insisted that it's package manager job to handle boot sectors.
My argument is that those sectors are just like BIOS, as far as package manager is concerned, and nothing more.
Quote:
Originally Posted by bassmadrigal
why is it ok for the installer to have low level disk access but not the updater?
Both the installer and cfdisk are usable without network access. A major bug in those two could be (at most) local privilege escalation.
Even a minor bug inside the updater with such a vulnerable feature is instantly a remote privilege escalation, which is much worse.
Quote:
Originally Posted by bassmadrigal
It just needs to copy the new kernel (and optionally initrd) to the EFI partition and ensure the config is pointing to it (which is easy if it's always named the same)
Congrats, you just described what the guy who originally suggested making slackpg vulnerable needs to do to fix his problem.
And also, more or less the thing I suggested to him in the first place, which you previously called "a unique solution".
let me chime in... The requests from jostber in this post was:
Quote:
Get slackpkg to run lilo or eliloconfig after a Kernel Update so there will no be kernel panic if the laptop loses power or user forgetting to run it.
I understand that the idea is that (maybe optionally) after a kernel upgrade a new initrd adapted to the new kernel be built and a corresponding boot entry be written in the boot menu, whichever it be. This feature that most distributions provide since a long time would make happy many Slackware users, I assume. I don't think we need to go into the implementation details at this point, but that's just my opinion.
Last edited by Didier Spaier; 05-20-2022 at 01:59 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
