This is a solved problem, but thought I’d post my experience in case it helps others.
I shut down normally yesterday, without installing any updates. Today, when I booted, the GRUB screen had lots of little penguins on it, doing amusing things. On start-up, updates were ready and, when installed, required a re-start. When I did, my XServer failed to start, stating that it couldn’t find my nVidia module.
I managed to get the system working by replacing the xorg.conf file with an old back up (in /etc/X11/), after logging in as root. The nVidia control app didn’t work, and I had to follow the instructions at NVIDIA driver not being used; failed to load NVIDIA kernel - openSUSE Forums - thanks to caf4926 for the help! I had to go through the nVidia install the “hard” way - but it worked, and the instructions were easy enough to follow (“hard” refers to the number of steps, not the difficulty level).
Everything on the display front is working now.
I then had a problem with my VirtualBox, in that it wouldn’t start, giving me a kernel compilation error. Fortunately, the on-screen instructions worked and everything seems fine on the system again.
Does anyone know what happened? I’m pretty sure I hadn’t done anything; however, the problems started after the upgrade.
As gminnerup noted, this sort of thing is standard with virtual box after a kernel update.
In essence, any driver that has been specifically compiled against an existing kernel version, has a reasonable chance of NOT working after a kernel update (as the locations in the new kernel are different than those in the old kernel).
Typically, this can impact:
proprietary graphic driver (although the openGL and vesa often survive a kernel update)
proprietary wireless driver (which can be miserable if wireless is one’s only means of connecting to the internet);
audio driver
webcam driver (if proprietary)
virtual software packages (such as virtual box or vmware)
Unfortunately sometimes the /boot/grub/menu.lst file is not properly setup afterward, or other important aspects in the kernel rpm installation do not seem to be executed, which can cause users major problems in trying to boot. I usually backup my /boot/grub/menu.lst file before installing the new kernel, and then I compare the updated /boot/grub/menu.lst file with the backed up /boot/grub/menu.lst file, looking for obvious mistakes in the updated file.
I also usually wait a week or more before I update my kernel, and I also ensure I have the drivers for the new kernel already waiting in a directory on my PC, for local installation after the kernel update.
More experienced users can also install the new kernel while retaining the older kernel, such that one can dual boot between different kernel versions.
If it is any consolation, almost all Linux distributions suffer from this very disruptive problem, when there is a kernel update. (ie misery loves company).
Yes, I know what happened. It’s quite a story but I’ll try to simplify things a bit.
The linux kernel makes your machine work, drivers are part of, or directly connected to the kernel.
Some hardware manufacturors don’t want to put their driver techniques in the open, therefore they are not included in the kernel. NVidia and ATI are famous for it. So you install the driver and insert it “in the running kernel”. In case of NV and ATI you then tell the X-server, it takes care of graphics display, to use it through configuring it in /etc/X11/xorg.conf That’s one
Some software, VirtualBox, VMware for examples, need their own kernel-modules to be loaded for functioning well. These modules are created / compiled during install of the software, and usually are loaded on boot of the host system.
Now, when you install a new kernel, the old kernel, including the added drivers and modules, is removed. The new kernel does not yet have these.
So now, in the case of the video cards, your X-server is trying to use a driver that’s no longer there and the new kernel doesn’t have it yet. Therefore it crashes and returns you to the console, showing a login prompt. Makes sense, doesn’t it.
And, in the case of the V* examples, the modules that were to be loaded on boot have disappeared and the new kernel does not have them. In VMware starting VMware is enough, it recreates the needed modules for the new kernel, loads them and goes on. VirtualBox doesn’t do that AFAIK. Reinstalling the packages forces creation of the needed modules, a reboot guarantees the loading of needed modules.
Summarizing: a new kernel does not have the post-install added drivers and modules. So they have to be reinstalled.
Hope this clears things a bit. If you have any questions…
This recent update has added duplicate menu items to mine, all pointing to the same kernel version. Went into YaST to try and delete them but found that they’re subtly different so I didn’t dare (tried to copy and paste but it didn’t work from that screen). Don’t want to hijack this threat but if you know how to get rid of them I’d appreciate it…
As to keeping older kernels, I seem to remember Ubuntu doing that by default, and listing them in the Grub menu so you could easily revert to the previous kernel in case of any update problems.
… in case one is looking for the Penguins, here is an old wiki that could use an openSUSE-11.0 or 11.1 user to test, to see if the methodology described still works in 11.0 / 11.1: Animated Penguin GRUB Splash Screen - openSUSE
>
> oldcpu;1997578 Wrote:
>>
>> Unfortunately sometimes the /boot/grub/menu.lst file is not properly
>> setup afterward, or other important aspects in the kernel rpm
>> installation do not seem to be executed, which can cause users major
>> problems in trying to boot. I usually backup my /boot/grub/menu.lst
>> file before installing the new kernel, and then I compare the updated
>> /boot/grub/menu.lst file with the backed up /boot/grub/menu.lst file,
>> looking for obvious mistakes in the updated file.
>>
>
> This recent update has added duplicate menu items to mine, all pointing
> to the same kernel version. Went into YaST to try and delete them but
> found that they’re subtly different so I didn’t dare (tried to copy and
> paste but it didn’t work from that screen). Don’t want to hijack this
> threat but if you know how to get rid of them I’d appreciate it…
> As to keeping older kernels, I seem to remember Ubuntu doing that by
> default, and listing them in the Grub menu so you could easily revert to
> the previous kernel in case of any update problems.
>
>
I usually use Kate or Kwrite to edit the menu.lst file. Be sure to start the
editor as root or you will not be able to save the modifications.
