Today’s Kernel update seems to have completed successfully and without incident 
For me now: 2.6.37.6-0.5-desktop
yep,especially my first after upgrading to gnome3.0
will kernel updates through desktop managers like gnome 3 into a tizzy ?
For me it looks OK too. Only thing is/was that I found preload-kernel-something eating up all the CPU power when I entered the KDE desktop. Its gone now, though.
No reason why it should
I confess I typically prefer to LOOK 1st to see what was updated (ESPECIALLY in a kernel), before updating … I note this in the kernel-default change log for this 2.6.37.6 kernel (ie all updates since openSUSE-11.4’s last kernel (the original)):
SUSE Paste - change log of 2.6.37.6 kernel
I’m not clear if that paste will show up (I may need to repaste) as susepaste did not like my paste for some reason and labeled me a spammer !
That’s quite long but it shows how the kernel is incrementally updated, and presumably tested along the way with the various updates.
The summary change history here is a bit easier to read (as it indicates lots of security patches and many ( ~60 ) bug reports addressed) : pastebin - summary of changes in openSUSE-11.4 kernel
I plan to update my 2 PCs running 11.4 (in test partitions) later tonight.
I had to remove preload on my box
It only runs at boot and soon drops out. It makes booting faster. A consequence on my box is a slower boot altogether.
But yes, it can hog the CPU at the login screen and just as the desktop settles down.
Not sure if it was related but I have suddenly got an openSUSE Education splash screen between Grub and login. The other splash screens are as before.
Not happening here JH.
I updated to the 2.6.37.6-0.5-default kernel on my Intel Core i7 920 PC (with an Asus P6T Deluxe V2 motherboard and nVidia GTX260 graphics).
07:00.0 VGA compatible controller [0300]: nVidia Corporation GT200 [GeForce GTX 260] [10de:05e2] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:82cf]
After updating I rebooted to run level 3 (with ‘nomodeset’ specified) and rebuilt the proprietary 270.41.06 video driver manually (ie what they call ‘the hardway’ which is NOT hard). Previous I was running KDE4 successfully with the 260.19.36 version of the nVidia driver). Note I also have yast > System > /etc/sysconfig Editor > System > Kernel > NO_KMS_IN_INITRD equal to “yes” (which was necessary for the 260.xx.xx version build previous).
After a successful rebuild (no errors) of the proprietary driver, I rebooted to KDE4 and found myself with the nouveau driver and NOT the proprietary video driver ! Checking the /var/log/Xorg.0.log file I noted the error message indicating the nvidia proprietary driver failed to load, and X fell back to the nouveau driver.
THAT was not expected.
I rebooted again, and again specified ‘nomodeset’ when rebooting, and when in run level 3 I ran midnight commander and blacklisted the ‘nouveau’ driver in the /etc/modprobe.d/50-blacklist.conf file. Of course instead of using midnight commander this could also be done with the command (with root permissions):
echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf
Then I once again rebuilt the 270.41.06 proprietary video driver. No error messages again when rebuilding. I then restarted the PC.
This time when the PC booted properly to KDE4 I noted the nVidia proprietary driver booted ok and special desktop effects were functioning.
Its a bit strange (to me) that when going from the 260.19.36 to the 270.41.06 that I would have to blacklist the nouveau driver with the 270.41.06 when that was not needed for the 260.19.36.
Anyway, its all ‘history’ now. The 2.6.37.6 kernel is running ok with the nVidia 270.41.06 proprietary driver and this nVidia GTX260 graphics device.
I updated another PC to the 2.6.37.6-0.5-default kernel (this time on my old athon-1100 (an MSI KT3 Ultra motherobard) with nVidia FX5200 graphics.
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV34 [GeForce FX 5200] [10de:0322] (rev a1)
After updating I rebooted to run level 3 (with ‘nomodeset’ specified as a boot code) and rebuilt the proprietary 173.14.28 video driver manually (ie what they call ‘the hardway’ which is NOT hard). Previous I was running LXDE with the same 173.14.28 version of the nVidia driver). Note I also have yast > System > /etc/sysconfig Editor > System > Kernel > NO_KMS_IN_INITRD equal to “yes” (which was necessary for the 170.14.28 version with previous kernel). And I did not have ‘nouveau’ blacklisted as it had not been required before.
After a successful rebuild (no errors) of the proprietary driver, I rebooted to but the PC failed to reach X with LXDE desktop. Instead the boot fell back to a full screen asii mode. Checking the content of the /var/log/Xorg.0.log file indicated the error “Failed to load the NVIDIA kernel module”.
THAT was not hoped for (but after my Core i7 hiccup with the GTX260 and the proprietary nVidia driver it was expected).
I ran midnight commander and blacklisted the ‘nouveau’ driver in the /etc/modprobe.d/50-blacklist.conf file. Of course instead of using midnight commander this could also be done with the command (with root permissions):
echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf
Then just to be on the safe side (in case some kernel modules did not unload properly upon the failed boot to X), I again rebooted to run level 3 (with ‘nomodeset’ as a boot code) and when once again in run level 3, I once again rebuilt the 173.14.28 proprietary video driver. No error messages again when rebuilding. I then restarted the PC.
This time when the PC booted properly to LXDE with the proprietary nVidia driver.
It appears to me now that with this 2.6.37.6 kernel the probability is higher that users who wish to install the proprietary nvidia driver, may be forced to blacklist the driver in the 50-blacklist.conf file.
For those with bleeding edge kernels in laptops, I’ve come across this Phoronics article regarding power regression in kernel 2.6.38 and 2.6.39.
On Sat, 30 Apr 2011 00:06:01 +0530, john hudson
<john_hudson@no-mx.forums.opensuse.org> wrote:
>
> Not sure if it was related but I have suddenly got an openSUSE Education
> splash screen between Grub and login. The other splash screens are as
> before.
>
that’s something to do with branding, i believe. i’ve got the education
repo enabled too, and (a rather long) while ago, my boot splash turned
into that project’s. i have some applications from edu. installed, and one
of them must have pulled in the branding as dependency, or recommended, or
whatever. didn’t disturb me, i rather liked the splash, but eventually
openSUSE took over again. i don’t really care what those few seconds on
startup look like.
this time i was a little apprehensive re. the kernel update, since
virtualbox actually has been working since i switched to a new
motherboard. i’ve heard stories earlier that some kernel updates didn’t go
well with different vbox versions at least in the beginning.
after installing 2.6.37.6-0.5-desktop though, and running
“/etc/init.d/vboxdrv setup”, virtualbox 4.0.6 runs fine.
–
phani.
An interesting article. Makes me wonder why the kernels are consuming more power.
hmm for me this Kernel update was nothing special as in Ubuntu you get Kernel-updates quite often. I was already wondering why there is no Kernel Update in openSUSE…
Looking at the changelog, I mean I have no clue about all this, this looks like a huge update. Lots of stuff fixed…
Everything worked for me on the Desktop. No issues with the Nvidia driver (I have installed it via yast from the nvidia repo) and no other issues.
On the Laptop (update is running now) there was some trouble with Kpackagekit, but nothing related to the Kernel update. Its right now installing the new Kernel lets see, but I think everything will be fine (its just an Intel graphics)
There is also an update to openSUSE-11.3’s kernel, from the 2.6.34.7 to the newer 2.6.34.8 (fixes a number of security aspects).
I updated the kernel on my mother’s PC in Canada (I live in Europe) where her PC is running a 64-bit openSUSE-11.3 and had the older 2.6.34.7 kernel. I take over her desktop remotely using vnc when I do such an update. I also carefully check her openSUSE /boot/grub/menu.lst file BEFORE and AFTER the kernel update (BEFORE rebooting the PC) to ensure the new menu.lst file makes sence. If I mess up the update, Canada is a long way from Europe, and I do not know ANYONE who live close to where she lives who knows Linux who could help her if I were to break things. Hence I am very cautious.
Her PC has AMD Radeon HD 4200 graphic hardware, where I only have the open source radeon driver running on that PC. I don’t want to mess with a proprietary graphic install when I am doing things remotely many thousands of miles away.
Anyway, the update on openSUSE-11.3 from the 2.6.34.7 to the 2.6.34.8 was successful . I did have to rebuild her virtual box host (as she runs winXP client in virtual box) with the command:
/etc/init.d/vboxdrv setup
but this is easy to do as VirtualBox tells one to do so (when it fails to run after the kernel update). Her Virtual Box (with winXP client) runs find now after sending that.
====
I also updated 64-bit openSUSE-11.3 KDE on my main PC (with nVida GTX 260 hardware) from the 2.6.34.7 to the 2.6.34.8 kernel. When I rebooted after the update, I typed “nomodeset 3” at the grub boot menu so as to go to run level 3 with modsetting disabled. I then rebuilt the proprietary nVidia 270.41.06 driver the manual way (also called "the hardway (which is not hard) " ). I have not blacklisted the ‘nouveau’ driver with this kernel/driver combination on 11.3 (although I do have KMS disabled) and the PC booted fine afterward to the 2.6.34.8 kernel.
Again, I had to rebuild Virtual Box using the same command noted above.
In all cases after the kernel install, wired, wireless, sound, webcam, worked ok.
This regression noted in the 2.6.38 to 2.6.39 kernel, has lead to Phoronix improving their benchmarks so as to be able to better detect problems with power management in laptops. This lead to the discovery of another Power Management problem when going from the 2.6.34 to 2.6.35 kernel, which makes me speculate that openSUSE-11.4 (with its 2.6.37 kernel) ‘might’ have less capable power management than openSUSE-11.3 (with its 2.6.34 kernel). Article is here: [Phoronix] Another Major Linux Power Regression Spotted](http://www.phoronix.com/scan.php?page=article&item=linux_kernel_regress2&num=1)
Here are some words out of that article:
With this expanded round of power testing, the Linux 2.6.37 to Linux 2.6.38 regression is still shown, but it also uncovered a very noticeable differentiation in power consumption between the Linux 2.6.34 and 2.6.35 kernels too. Under idle on this test system, it equates to a 20% difference in power consumption and then the 2.6.37/2.6.38 regression tacks on another 6% in this particular test profile.
… The pre-2.6.35 kernels are all running at right around the same power level within a reasonable milliwatt range of each other on the various tests. … However, with the Linux 2.6.35 kernel, the power consumption goes up noticeably.
I’m still running openSUSE-11.3 (with its 2.6.34 kernel) on my Dell Studio 1537 laptop (where I did not update as I was waiting for the situation wrt the Intel 5300 AGN wireless problems with KDE4 on 11.4) and this power management possible regression has me now adding another factor to my 11.3 to 11.4 update decision.
I may just keep this laptop on 11.3 until openSUSE-12.1 or even openSUSE-12.2.
Happened to me, too. Had to change theme in Yast /etc/sysconfig editor (/system/boot/theme) to “openSUSE” and run mkinitrd.
there is another issue with the new Kernel, which I would like to mention. In /etc/filesystems somehow the entry
ntfs
got lost. Result: you can not mount external USB drives with ntfs filesystem. This happened to me with 2 computers.
solving this issue is easy. Just press Alt+F2, type
kwrite
type your root password and then open /etc/filesystems from the open menu in Kwrite. Then enter “ntfs” into the file, but before the star = * in the file. Save it and done. Mounting the drives should work then again.
This ntfs issue is well reported on since the kernel update
Thanks though