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.
Greetz
I'd have said SNAFU, but the truth is that I really don't recall this mess being "normal" in Slackware since v7. This kind of mess is what I expect from Ubuntu, not Slack.
Here's what happened. I was running Slackware-Current 12/10/10 and wanted to move up to Current 1/10/11. I read and followed the UPGRADE.txt including running "telinit 1". The system had 2 working kernels menued in Lilo, a custom 2.6.35.10 symlinked to "/boot/vmlinuz", and a custom 2.6.36 fully declared in lilo.conf and labelled Current.
The "upgradepkg --install-new" installed a "new" kernel which would only have required a simple deletion, but somehow and for some silly reason my lilo.conf was overwritten and lilo run so that when I selected "Current" instead of my nice 2.6.36, long story short, I got a badly working kernel where my keyboard didn't work.
Why would "upgradepckg --install-new" install an older kernel, and more importantly, instead of merely as an added option, override and ruin my existing, working lilo? On one level it wasn't huge problem thanks to a Slax-Remix LiveCd but I'm sure it would have tripped up a few users and it just seems so unnecessary.
Slax is overhauling to add pacman and I see some people even here leaning toward more automated package management in Slackware. What gives? Is Slackware headed down this path? Please, Joe, just tell me it ain't so.
Regards
killRant
EOF
I think when you install/upgrade a kernel it creates the symlink in /boot to point at the new kernel, hence booting a different one to your custom.
Best practise I find is to put the full kernel version in lilo.conf and avoid symlinking vmlinuz to it, since it will be overwritten to point to the stock kernel.
And if you didn't know already, upgradepkg doesn't take any notice of whether or not you are going up or down a version, it will just install whatever you point it at, as it should.
The "upgradepkg --install-new" installed a "new" kernel which would only have required a simple deletion, but somehow and for some silly reason my lilo.conf was overwritten and lilo run so that when I selected "Current" instead of my nice 2.6.36, long story short, I got a badly working kernel where my keyboard didn't work.
I've never heard of upgradepkg replacing lilo.conf and then running lilo. If it did indeed do as you say, then that's something new and very un-slackware like, and somewhat disturbing.
Greetz
and for some silly reason my lilo.conf was overwritten and lilo run
There is not a single (official, anyway) package install or upgrade that will create or modify /etc/lilo.conf, or run lilo. Something else happened, and I suspect it wasn't anything we did.
There is not a single (official, anyway) package install or upgrade that will create or modify /etc/lilo.conf, or run lilo. Something else happened, and I suspect it wasn't anything we did.
Thank you for confirming that this seems to be something other than base design or a shift in pardigm. It is likely due to my ignorance of how Lilo functions, in that it has always been my understanding that "/sbin/lilo" must be run to "activate" any new kernel. I probably wasn't very clear since it was puzzling and I tried to keep my post short.
Since someone else incorrectly assumed my problem came from an "image = /boot/vmlinuz" mixup, I should be absolutely clear it was not. There are two menuitems available when Lilo runs and I am certain I chose "Current" which corresponded to "image = /boot/vmlinuz-2.6.36" ... as I said, fully declared.
It probably is good to stop here because I don't wish to belabor the point unless someone asks for more info. The event, whatever caused it, wasn't a big deal and I only posted the thread to emphasize how important it can be, even for old Slackers, to get "all their ducks in a row" and protect their data before any system upgrade. The second reason is probably due to my own paranoia from dealing with so many Linux users on other forums who think that manual dependency resolution is too much work with little or no value. I sing Slackware's praises to anyone who will listen and a few that won't and had just a few days ago read about Slax's change of direction. I know they aren't necessarily connected but I am painfully aware of how Linux is changing already having seen a few sites already that post a Ubuntu package not accompanied by a source tarball. That is a trend I despise, so I might be a little gunshy.
Slackpkg's goal is to keep your system pure Slackware, and installs/upgrades upstream packages. When there is a kernel upgrade it installs it in the default Slackware manner. That is, /boot/vmlinuz will be linked to the installed huge kernel. Slackpkg will then ADVISE you to run lilo and offers to run lilo for you. But you must answer yes.
If you don't want to track Slackware's upstream kernels, blacklist them in /etc/slackpkg/blacklist.
This file even contains this text
Quote:
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below
#
#kernel-ide
#kernel-modules
#kernel-source
#kernel-headers
Here's the function that calls lilo from slackpkg post-functions.sh
Code:
lookkernel() {
NEWKERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
if [ "$KERNELMD5" != "$NEWKERNELMD5" ]; then
if [ -x /sbin/lilo ]; then
echo -e "\n
Your kernel image was updated. We highly recommend you run: lilo
Do you want slackpkg to run lilo now? (Y/n)"
answer
if [ "$ANSWER" != "n" ] && [ "$ANSWER" != "N" ]; then
/sbin/lilo
fi
else
echo -e "\n
Your kernel image was updated and lilo is not found on your system.
You may need to adjust your boot manager(like GRUB) to boot appropriate
kernel."
fi
fi
}
I never run upgradepkg on the kernel-* packages. I use installpkg to add the new kernel and modules alongside the old one (they co-exist just fine), run mkinitrd, edit lilo.conf and add a new entry and then run /sbin/lilo to update it. I then reboot on the new kernel. After the reboot and once I know everything is fine and I don't need the old ones, I removepkg the old kernel packages.
Doing it this way has never let me down.
I don't use slackpkg, but if I did, I'd certainly blacklist the kernel packages and do them manually.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.