Three days ago, I’ve updated my Slackware 14.0 (32 bit) due to kernel update security advisory. However, after a reboot, my box freezes up few minutes after logging in into the desktop. I searched around and ask in the forum but end up downgrading to the original kernel version 3.2.29.
UPDATE: Since this is a security patch, I’ll be updating to a newer kernel anytime soon and will stay away from 3.2.29. However, since it would require more work, I’ll stay in 3.2.29 a bit until I have enough time to install any of the newer kernels (perhaps this coming weekend).
UPDATE: An updated dated June 3, 2013 was uploaded to Slackware mirrors and promised to fix the Intel issues with kernel 3.2.45 (3rd rebuild). Today, June 9, 2013, I have applied the patch and so far it works. I have uploaded some screenshot showing some Firefox 3d stuff.
Original post below.
Kernel patch 3.2.45
The original kernel for 14.0 was 3.2.29 and the supposed to be security patch kernel version is 3.2.45. After few days since the patch has been released, I’ve applied the patch via Slackware update. The installation went through and I’ve even updated the initrd
so I could use the generic kernel. However, during my final reboot so I could start working on the machine, it freezes up few minutes later after logging in into KDE.
I’ve tried different desktop environment (XFCE) and even bare bone window managers (blackbox, fluxbox) but same issue occurs. I suspect it was the graphics driver. My Intel Graphics 3000 may not be supported or whatsoever. I’ve read the change logs and it says that there was another update few days after the kernel patch. I’m sure I got the latest patch but I still experienced the issue described. There was even a discussion in the forum about the said issue.
Stuck due to no wifi
I’m using NetworkManager for my wifi. Since I’ve configured the wifi via NetworkManager, by default I could not connect to the internet without logging into X. I was planning to downgrade but couldn’t download due to no internet connection in runlevel 3. I’ve asked around again so I could do something to save my machine.
nomodeset
I’ve read somewhere on that forum post that we could pass nomodeset
parameter into lilo
or any boot manager so it would bypass awesome graphics features and thus allow troubleshooting (ex: can connect to the internet but with crappy graphics quality). Since I’m using lilo
, I do the following:
- Start the machine
- At boot screen, press tab
- Type in the name of the lilo entry for your linux, mine I have the following entries:
Linux
Linux3245
Windows
- After typing in the
lilo
entry, add space and type innomodeset
Linux3245 nomodeset
- Press enter
- Wait for the login manager to show up and login to the desktop manager
- Once you are able to login, you can download and install the old kernel package
Downgrade kernel
Now that I’m able to login to the desktop manager and connect to the internet, I was able to search further about the issue. However, my plan is clear – to downgrade to the original 14.0 kernel version 3.2.29. Since I already have a full copy of Slackware 14.0 including the source, the original kernel is also available in that copy. I just installed old kernel in the slackware/a
directory.
cd /path/to/slackware-14.0 cd slackware/a installpkg kernel*
Now that I have both kernel 3.2.45 and 3.2.29, I can choose to use both and play around. But I choose to just revert the default kernel to 3.2.29 and leave it as is for the next couple of months. The task is simply to re-run the mkinitrd
command, update lilo.conf
to point to the correct generic kernel, rerun lilo
and rebooted.
I know that messing around with Linux kernel is scary but it has been done and I’ve committed the same mistake over and over again. Until the next kernel trouble my friend. For now I could go back to work instead of dealing with OS problems.
Read the thread from here and you will find the solution to the problem.
Hi Ruario,
I think I have to stick with the 3.2.29 and ignore the local user kernel vulnerability. Breaking my main machine during work sucks 😀
I’ll just watch for future important updates and see if it would work on my machine.
Thanks
Ok, well Pat just issued another kernel with the other problematic commit removed. 😉
Dated June 3, 2013. I’ll take a look on this on weekend (if I’m not getting lazier).
so did it work out for you? 😉
It works, finally.
Praise Bob.