Since Grub2 always makes the latest kernel installed the default, you can change that behavior with my bash script grub2cmd, just updated to work with openSUSE 12.3:
I am compiling the 3.8-rc1 kernel right now and so I don’t know what it will work with or not, concerning nVIDIA or VirtualBox. On my next post I will let you know how that is working out.
Well for the good news. Kernel 3.9-rc1 compiles & Installs OK and it starts up OK. Further, nVIDIA proprietary video driver version 310.32 also compiles & installs against kernel 3.9-rc1 OK. But alas, VirtualBox 4.2.8 does not compile and install properly again kernel 3.9-rc1, so it looks like we got two out of three tonight. We will be looking for a patch to VirtualBox it would seem but you nVIDIA users wanting to test kernel 3.9 should be good.
On 03/03/2013 08:56 PM, jdmcdaniel3 wrote:
>
> Well for the good news. Kernel 3.9-rc1 compiles & Installs OK and it
> starts up OK. Further, nVIDIA proprietary video driver version 310.32
> also compiles & installs against kernel 3.9-rc1 OK. But alas,
> VirtualBox 4.2.8 does not compile and install properly again kernel
> 3.9-rc1, so it looks like we got two out of three tonight. We will be
> looking for a patch to VirtualBox it would seem but you nVIDIA users
> wanting to test kernel 3.9 should be good.
The fix for VirtualBox is trivial. One of the kernel headers is no longer
included by default and must be included explicitly. The patch is
So I had trouble getting your patch to patch the right file, but perhaps it was due to the code tags you placed it in did not work. I edited your message and placed the patch in code tags, but it did not help. Since I could see this is a one line patch, I recreated the patch, which seems to patch VirtualBox OK. I must boot into kernel 3.8 again and see if it works.
I pasted the above text into kwrite and saved it as the file vbox.patch in my $HOME/Documents folder. I then opened up a terminal session and typed in the following commands.
cd /usr/share/virtualbox/src
sudo patch -p0 <$HOME/Documents/vbox.patch
I will reboot next and see if it works, but I want to post the details while I had them at hand.
So the VirtualBox patch as I listed above and executed does work OK with Kernel 3.9-rc1 and VirtualBox 4.2.8, but after the patch is applied, VirtualBox will no longer compile into kernel 3.8.2 I have found and so it seems to work one way only, so beware of using this VirtualBox patch unless you are sticking with kernel 3.9.
On 03/04/2013 05:56 PM, jdmcdaniel3 wrote:
>
> So the VirtualBox patch as I listed above and executed does work OK with
> Kernel 3.9-rc1 and VirtualBox 4.2.8, but after the patch is applied,
> VirtualBox will no longer compile into kernel 3.8.2 I have found and so
> it seems to work one way only, so beware of using this VirtualBox patch
> unless you are sticking with kernel 3.9.
Sorry, I did not test with the earlier version. A version that will work for all
kernel versions is
So when I try to use your patch Larry, which I saved as vbox.patch in my $HOME/Downloads area, then I open up terminal and run these commands, here is what I get:
cd /usr/share/virtualbox/src
sudo patch -p0 <$HOME/Documents/vbox.patch
patching file vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
patch: **** unexpected end of file in patch
So I modified the patch file I had created to say this:
I again open up terminal and run these command with no error message:
cd /usr/share/virtualbox/src
sudo patch -p0 </home/james/Documents/vbox.patch
patching file vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
I can see you have a conditional statement, to be used only with kernel 3.9 and I am using your exact code fix you wrote but the patch file format is just not working for me, but I don’t understand why that is. After you make the patch, you can force a VirtualBox recompile to make sure VirtualBox will still compile by opening up terminal and executing these commands:
su -
/etc/init.d/vboxdrv setup
Stopping VirtualBox kernel modules done
Uninstalling old VirtualBox DKMS kernel modules done
Trying to register the VirtualBox kernel modules using DKMS done
Starting VirtualBox kernel modules done
If you get the same result, VirtualBox recompiling is working.
On 03/04/2013 07:36 PM, jdmcdaniel3 wrote:
>
> So when I try to use your patch Larry, which I saved as vbox.patch in my
> $HOME/Downloads area, then I open up terminal and run these commands,
> here is what I get:
>
>
> Code:
> --------------------
> cd /usr/share/virtualbox/src
> sudo patch -p0 <$HOME/Documents/vbox.patch
>
> patching file vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
> patch: **** unexpected end of file in patch
> --------------------
>
>
> So I modified the patch file I had created to say this:
>
>
> Code:
> --------------------
> Index: vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
> ===================================================================
> *** vboxhost.org/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
> — vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
> ***************
> *** 34,39 ****
> — 34,42 ----
> #include <iprt/assert.h>
> #include <iprt/thread.h>
> #include <iprt/err.h>
> + #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,9,0))
> + #include <linux/sched/rt.h>
> + #endif
> #include “internal/thread.h”
>
>
>
> --------------------
>
>
> I again open up terminal and run these command with no error message:
>
>
> Code:
> --------------------
> cd /usr/share/virtualbox/src
> sudo patch -p0 </home/james/Documents/vbox.patch
>
> patching file vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c
> --------------------
>
>
> I can see you have a conditional statement, to be used only with kernel
> 3.9 and I am using your exact code fix you wrote but the patch file
> format is just not working for me, but I don’t understand why that is.
> After you make the patch, you can force a VirtualBox recompile to make
> sure VirtualBox will still compile by opening up terminal and executing
> these commands:
>
>
> Code:
> --------------------
> su -
>
> /etc/init.d/vboxdrv setup
> Stopping VirtualBox kernel modules done
> Uninstalling old VirtualBox DKMS kernel modules done
> Trying to register the VirtualBox kernel modules using DKMS done
> Starting VirtualBox kernel modules done
> --------------------
>
>
> If you get the same result, VirtualBox recompiling is working.
What you do not see is that there are two lines at the end of the patch that
have only a single space at the beginning of the line.
When I asked about this problem in the back room it was suggested the we were missing blank lines at the end though I did not understand we needed a space there too. It makes me think we just need to use SUSE Paste (for me at least) or otherwise post it online to keep the end of the file intact. I know that you have also posted the text files into an online link, though I don’t recall what service you use to provide that here. Let me say that it is my desire to post such patches in a manner that anyone could use them and if it is OK, I shall repost your patch into SuSE Paste if not already in an online patch format.
One thing is for sure Larry, I appreciate your help with this information, like the very quick production of the VirtualBox patch, and can’t thank you enough for your assistance here.
Thanks for the link ryanbach. I have just finished installing kernel 3.9-rc2 into openSUSE 12.3 with no problem. I used our previous listed patch for VirtualBox 4.2.8 so it would compile and install into openSUSE 12.3.
I can say that anyone wishing to use dkms with VirtualBox in openSUSE 12.3, must continue to use my dkms patch to get dkms to work for VirtualBox. Same goes for my after.local file fix as after.local still does not run by default as far as I can see. Both are due to changes in the usage of systemd in openSUSE and the issues are not new to openSUSE 12.3, but just continue as before. For help with dkms and the after.local script, have a look at these blogs on the subject:
In order to handle the change in format, S.A.K.C. has been upgraded to version 2.80 and now supports both tar.xz and tar.bz2 with a link to the latest version below:
I can’t say why so many would request the format change unless its due to better compression perhaps. When I compare kernel version 3.9-rc1 at 82.0 MiB using tar.bz2 to kernel 3.9-rc2 at 67.7 MiB using tar.xz format, there is a better than 17% reduction in size, not accounting for any difference between the two versions. I suspect a lot of scripts out there will now be broken after this switch has been made. Any improvements due to reduced size will be lost on many systems due to the capacity already on hand, but saving disk space is not a bad thing to do.
If anyone has a problem with the latest S.A.K.C. and tar.xz files, please let me know.
Thanks for your comments and I understand the old format is still there, but SAKC has to handle what you get by default without removing supported for the previous default version. My SGTB bash script still outputs tar.bz2 files as well until I feel the need to make a change in the default tar format.
Thanks for the heads up Dale. I have downloaded the latest kernel-3.9-rc3 tonight, compiled the new style tar.xz file using SAKC 2.80 and all is well with the world. I do wish the new kernel did not wait to near bed time on Sunday night to come out. It does not give much time before bed to play with the latest kernel. But it does work just fine so far.
It compiled and installed like a champ on my test machine. I can say I was happy to see it come on Saturday instead on Sunday night as I can play with it on Sunday on more than one PC. And, its been a good night as I am fully upgraded to openSUSE 12.3 now and I purchased a killer CD today I am playing right now from Justin Timberlake called JT - The 20/20 Experience, special edition with two extra songs, one of which is killer called Dress On. Even though not as young as most around here, I do dig JT a lot, you got to git it.
Happy kernel testing to all in the openSUSE forum …
On 03/23/2013 11:56 PM, jdmcdaniel3 wrote:
>
> Well I find that tonight, on Saturday night, we got our next release of
> the 3.9 kernel at rc4 you can find at the following link:
>
> http://tinyurl.com/bwkfgsd
>
> You can see what Linus had to say about it here:
> https://lkml.org/lkml/2013/3/23/147
For users of rtl8192cu, rc4 has a very important patch. It will be backported to
all stable versions in the near future.
The Linux kernel can now be set up to use SSDs as cache for hard drives; Btrfs has native RAID 5 and 6 support. The kernel development team has also resolved two performance problems caused by previous changes.
On Sunday, Linus Torvalds released the fourth pre-release version of Linux kernel 3.9. In his release notes, he noted that development has not yet settled down and called for testing of the RC.
As usual, Torvalds and his the other kernel developers merged all of the major changes planned for Linux 3.9 into the kernel in the two weeks following the release of version 3.8. We are currently in the stabalisation phase and major changes during this phase are rare allowing the Kernel Log to provide a comprehensive overview of the major new features to be expected in the new Linux version, which is expected to be released in late April.
This overview will be provided by a series of articles dealing with various facets of the kernel. The series opens with a description of new features in the areas of storage technology and filesystems. Over the next few weeks, further articles will deal with graphics drivers, kernel infrastructure, networking, processor/platform support and drivers for other hardware.
And another release candidatekernel 3.9rc5 What phoronix has to sayI have to say I have it up and running for a few minutes now. I used jdmcdaniel3’s sakc to compile and install using the standard compile process and the build was fast, about the speed of turbo
That is 44 minutes as opposed to close to 4 hours
