I noticed that too but it isn't the problem, since as ponce pointed out the files are the same. For pure tidiness I also fixed the symlink, though as expected it did not fix the issue.

I'm going to try some of the suggested ideas. I'll report back later.

TobiSGD: Would this work on non-standard resolutions? I've got a 1024x600 netbook display. If necessary I could plug in a 1920x1080 monitor over a VGA cable, too. Just not sure if either of those resolutions would be usable with the video= setting.

That's what I've got, too. Exact same.

This is pretty bad. I upgraded because this security issue sounded pretty serious (I've seen several other distros releasing kernel patches this morning), and now I don't even have a usable system. This kinda blows.

Why can't Slackware install and support multiple kernels in lilo's boot menu instead of clobbering over the old one? I've seen other distros support multiple kernels, like Gentoo and Ubuntu. Should this be suggested to Patrick and the team, in case this happens again, or is this one of those things Pat already made a decision against a while back? I know if there's a reason for not doing something in Slackware, it's usually a good reason, so I'm not sure if it would be worth recommending or not.

Huh.

Well, OK, but (1) didn't and (2) did -- must be magic? Dang thing's sitting there mumbling to itself and working just fine.

I'll try the laptop that I don't use too often and see what happens there (again, these are Slackware 14.0 stable, stock SMP kernel -- the one that's working is a 32-bit, the laptop is 64-bit and I'll see if it fries it brains).

Sigh.

As far as I know Eldarby (someone correct me if I'm wrong here), you can put as many kernel images as you want in /etc/lilo.conf, it just isn't automatic like with GRUB/GRUB2 (I personally hate GRUB, it's so complicated, so many *.conf files).

1 members found this post helpful.

As long as you don't have potential hostile local users with remote shell access, there is no reason for panic. It's "just" a local privilege escalation issue. In the usual desktop scenario, it is just as dangerous as the possibility to "root" your smartphone.

I was also affected by this 'upgrade' but I found a solution.
I found this: https://bugzilla.kernel.org/show_bug.cgi?id=58511
When I reverted this patch ( https://git.kernel.org/cgit/linux/ke...20ec5778d1f311 ) and recompiled/installed kernel modules, it works again.

deleted

Same issue here. I thought I screwed something up when I installed it onto my netbook since I had to take it apart to put in a new wireless card. Good to know a patch has been created, so 3.2.46 should fix it.

This seemed to be a good time to have a slightly outdated local mirror, hehe (though now that I think about it, 3.2.29 packages should still be in the updated archive as 3.2.45 should be in /patches.) I was able to downgrade safely back to the old 3.2.29 packages, something that would seem dangerous to do on (ahem) more sophisticated distros. Chalk one up for the Slackware package management system!

1 members found this post helpful.

Yeah, but it kinda sucks to remember that you forgot to run lilo after a kernel upgrade immediately after you pressed "enter" to the "shutdown -r now" command.

It still sucks to remember that you forgot to run the grub-mkconfig command after a kernel upgrade immediately after you pressed "enter" to the "shutdown -r now" command, but you can interactively fix your boot so you *can* run the bloody thing when the system comes up.

Since I've got my root directory on an LVM over a RAID array, the slackware install disk doesn't help a whole lot to reboot in that environment. Oh, you *can* do it, but it's a real PITA. Bog knows that I've done it enough times. :-/

This is why you install new kernels alongside the old kernel and keep an entry in lilo.conf pointing to the old kernel. You can pass -o to mkinitrd to name the initrd something other than initrd.gz so you can have multiple initrds available too. Of course, doing this breaks slackpkg (and pkgtools) because it finds multiple packages with the same name, but blacklisting the kernel packages in slackpkg and making sure to always installpkg/removepkg explicit kernel versions rather than the more generic 'kernel-generic', for example, and never upgradepkg'ing kernels, allows this to be painless. Even if you forget to run lilo, you have the old kernel version to fall back on.

1 members found this post helpful.

At least slackpkg will prompt you to run LILO after a kernel upgrade. :-)

Would be more user-friendly if kernel updates were handled conservatively.

My work-around is not using upgradepkg. I use installpkg, copy and edit the existing grub menu.lst items for the new kernel version. That way I can reboot safely should the new version cause headaches.

Not to mention there is always a punch list when updating a kernel: update nvidia, virtualbox, and lirc kernel modules, and compare the previous and new rc.modules-* files. I forgot to perform that last one today and I spent time scratching my head why I had no sound in one of my machines after the update.

Perhaps in addition to the "Remember to update lilo" message, the slackpkg reminder could print something like "Remember to update lilo/grub, third-party kernel modules such as nvidia, virtualbox, and lirc, and review the new rc.modules files for necessary changes.

When all is calm and I'm comfortable the new kernel and updated kernel modules are functioning correctly, then I use removepkg to remove the previous kernel version and modules, and update the grub menu.lst.

I've tried to prepare a testing kernel-generic (remember you need an initrd!) package (it includes also the stuff in the kernel-modules one inside) with the patch reverted.

If anybody having the black screen problem with an intel GPU on slackware-14.0 32bit can test it...

http://ponce.cc/slackware/testing/ke...686-2ponce.txz

2 members found this post helpful.

@ponce: Thanks ponce. That was really nice of you to make available. You are also one of the few here who has developed enough trust that I (and probably others) would consider taking a binaries for such a key package. That said, I still haven't noticed any problems with using the 3.8.13 kernel from current (and indeed I have noticed some improvements) so I'll probably stick with it for now. However, if I do encounter problems (and assuming Pat doesn't provide another kernel) yours will be next on my list.