Hi
Earlier this evening I was presented with some security updates, including an update to the kernel. I clicked to allow them to install. The kernel update stops at a login prompt, but doesn’t seem to recognise any of my username / password combinations. Any ideas ? Can I back out of this update or am I screwed ?
Usually the auto-updates only require that you enter the root password.
Else go to yast2>software>online update and choose the updates you want to install.
It might help if I explain a little further. After the downloads for the updates had completed, I was asked to reboot. When the system restarted it went into a command line mode; spent about 10 minutes presumably upgrading stuff and then halted at a command line login prompt. This prompt will not accept my userid / password. If I power off, then on restart it goes through the whole process again. So - I am currently unable to complete this update nor get back to the desktop. All a bit concerning for something that I didn’t even request in the first place 
Is this “command line” mode the usual console shell or is it by any chance saying something about “fsck”? If something on your disks needs fixing, fsck will take some time, and then ask for your input, which fits your symptoms. If your reboot shows a green screen, try pressing F2 once booting starts so you can see the console diagnostics.
In my case I don’t even get to the command line and therefore can’t get into the system to investigate. After applying the kernel update, all I get on reboot is a long series of messages complaining about iptables, and another about not being able to load modules (fatal), and the system hangs.
I’ve tried twice, and had to restore from backup each time. This is openSuSE 11.1 64-bit, KDE 4.2.9X, running on a Core 2 Quad desktop. The kernels concerned are 2.6.27.23-0.1 (installed) and 2.6.27.25-0.1 (available).
Any chance you can post a list of the modules involved? A kernel upgrade always screws up certain modules that were added manually after you installed your previous kernel. In my case, for example, I have to reinstall my wifi drivers, webcam and soundcard. In your case it might be something else and giving a list of things it fails on might help.
Did you try the fail safe startup? It should allow you to at least get to your command prompt since it doesn’t load much. It should be in the grub menu.
What I got was soemthing like modprobe: FATAL: could not load /lib/modules/2.2.27-0.1-default/modules.dep: No such file or directory.
and this:
iptables v 1.4.0: can’t initialize iptables table ‘filter’ & more, plus the suggestion “Perhaps iptables or your kernel needs to be upgraded”.
And then a hang without ever getting to a command prompt.
Thanks for the suggestion about failsafe. But before I chance my arm and try again, I observe the following and wonder what it means, if anything.
The installed kernel is 2.6.27.23-0.1. The available kernel is 2.6.27.25-0.1. What I don’t understand that opening the file list for the new kernel in
YaST2 shows (typically) /lib/modules/2.6.27.23-0.1-default/[etc etc]. That seems odd - I’d have expected the subdirectory to be referenced to 2.6.27.25, but then I don’t know enough about it to be sure.
The failsafe might get you in to a command prompt or even a desktop. If you that you can use yast or zipper to reinstall the old kernel. That’s what I meant with the failafe.
Has this machine ever done a kernel update successfully? Mine went smoothly except for the before mentioned hardware. My grubline has the kernel image as:
image=/boot/vmlinuz-2.6.27.25-0.1-default, initrd=/boot/initrd-2.6.27.25-0.1-default
The failing modules looks to me like the update went wrong, it deleted the old kernel but didn’t put back the new one properly. Another option for you is running the repair option from a opensuse 11.1 DVD. This might also help you.
It looks like you are linking to the old kernel modules.
You modprobe to link to the new kernel modules.
If you can boot with a live system, you can either create a link to the new modules (2.6.27.23-0.1) or copy the new modules to the old directory (2.2.27-0.1).
I think the update is probably doing an incremental update. It will perform the next delta when it is next run.
OK - found it!
The updated kernel & sources had been installing OK all along, except that when grub’s menu.lst was overwritten it pointed (wrongly) to an 11.0 root partition on another disc. So when it tried to boot, of course it couldn’t find the right modules (and much else, I should imagine).
Dead simple, really. Turns out the only incremental thing was my understanding. Live and learn.
Thanks for the commments everyone.
Glad you got it sorted!
Hi
Would someone be able to flesh out a bit more detail regarding the fix that RobinJK applied in the post above? As the initiator of this thread, I haven’t yet managed to install this kernel update. It took me a couple of weeks to get back to a stable pre-update system from my backups. But now I’m ready for it again (I guess I’ve got to do it some time). But I’m still none the wiser as to how to complete. Makes me all nervous just thinking about it
Thanks
I don’t know about your problem, but reference RobinJK’s solution, I think I can offer a bit.
When your PC boots, the BIOS instructions will redirect one’s PC to the PC’s MBR (master boot record) which may then send one to the Active partition. Typically for PC’s that use the Linux Grub boot manager, when redirected by the MBR to the Active partition, the grub boot manager on that partition will run and it will grab its information from the file /boot/grub/menu.lst on same partition, where the menu.lst has the information that is displayed by the boot manager so one can then choose the boot partition in order to boot the PC to different operating systems.
The information in the menu.lst often has the boot information written such that for each Linux OS, it is specific to a kernel version.
So if the menu.lst information is kernel specific, then when one updates the kernel, the information in that file menu.lst kernel information needs to be updated. The rpm should have a script ( ? ) inside that is run during the install that updates the menu.lst, pointing to the updated kernel version.
When one has multiple openSUSE Linux boot partitions on a PC, there will be multiple entries in the menu.lst file, pointing to the different openSUSE versions. Say one can boot to both openSUSE-11.1 and 11.0, and hence there is an entry in the menu.lst pointing to openSUSE-11.1 old kernel, and one pointing to the openSUSE-11.0 old kernel.
So it appears in some cases, where one has multiple openSUSE versions on the same PC, that the script can get confused, and it updates the openSUSE-11.0 entry, pointing to the openSUSE-11.0 partition to a new kernel version that does not exisit in the openSUSE-11.0 partition (as the kernel in the 11.0 partition is still the 11.0 partition). But the 11.1 partition now has the new 11.1 kernel and the menu.lst still points to the old 11.1 kernel (which is no longer present).
Hence the PC can no longer boot to 11.0 nor 11.1.
Clear as mud?
Its actually a lot more simple than it sounds, but I’m horrible at writing these things down, and I could do a better job with a piece of paper and a face to face description.
Thanks, oldcpu
Now you’ve explained it, it doesn’t sound like the problem I had. In my case all I had was a single Opensuse 11.1 partition (I think its 11.1 - how can you find out ?) which just wouldn’t reboot during the kernel update. Maybe I’ll just have to try again with this kernel update when I’ve got plenty of time and some good backups taken.
Thanks, anyway. I’ll be back with an update 