Well I see that today we have the next kernel version 3.5 posted at The Linux Kernel Archives for download. dale14846 was kind enough to alert me this morning that the next kernel version had been posted and was ready for testing. I was able to download and compile kernel 3.5-rc1 without any errors. I am using the kernel 3.4 config file for this purpose. I am happy to report that the nVIDIA driver 295.53 works like a champ so far with kernel 3.5, but alas, VirtrualBox 4.1.16 does not compile properly and will not work with kernel 3.5-rc1 and so expect issues in running the VirtualBox VM until someone posts some kind of fix for it. Another curious thing was that kernel 3.3.7 is still the latest stable kernel shown and for now, so kernel 3.4 has went away from the main page. You can still get kernel 3.4 using my SGTB bash script if you need it.
Here are some useful bash scripts and other links for your usage.
In another bit of good news, yesterday I was able to properly compile a kernel source file in openSUSE 12.2 using SAKC which means the kernel installation script for the latest openSUSE version has been fixed for us. Yea!! I will have to try out kernel 3.5 in openSUSE 12.2, but I have not done so thus far. As always, I want to hear any and all comments you can make for the latest kernel 3.5. Please do not be bashful and let us hear from you for any and all comments on kernel installation and testing.
On my first attempt using make, make modules_install, install I kept getting throown into a rescue mode right after the line
kvm disabled by bios
On my second attempt using sakc My computer booted into the kde desktop although the (kvm disabled by bios) did appear
I did a make initrd to check something I noticed on my first attempt that said the xen block wasn’t found.
This time the failed kernel’s mkinitrd showed a slew of warnings
Resume device: /dev/disk/by-id/ata-WDC_WD2500BPVT-22ZEST0_WD-WX91A4135270-part2 (/dev/sda2)
find: `/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/scsi': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/thermal/thermal_sys.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/thermal/thermal_sys.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/thermal/thermal_sys.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/thermal/thermal_sys.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/i2c/algos/i2c-algo-bit.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/gpu/drm/drm.ko': No such file or directory
WARNING: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/gpu/drm/drm_kms_helper.ko': No such file or directory
modprobe: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/gpu/drm/i915/i915.ko': No such file or directory
modprobe: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/usb/storage/usb-storage.ko': No such file or directory
WARNING: no dependencies for kernel module 'usb-storage' found.
modprobe: Could not read '/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/hid/hid-logitech-dj.ko': No such file or directory
WARNING: no dependencies for kernel module 'hid-logitech-dj' found.
Kernel Modules: thermal processor fan video button
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/thermal.ko needs unknown symbol thermal_zone_device_unregister
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/thermal.ko needs unknown symbol thermal_zone_device_update
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/thermal.ko needs unknown symbol thermal_zone_unbind_cooling_device
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/thermal.ko needs unknown symbol thermal_zone_bind_cooling_device
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/thermal.ko needs unknown symbol thermal_zone_device_register
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/processor.ko needs unknown symbol thermal_cooling_device_register
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/processor.ko needs unknown symbol thermal_cooling_device_unregister
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/fan.ko needs unknown symbol thermal_cooling_device_register
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/fan.ko needs unknown symbol thermal_cooling_device_unregister
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/video.ko needs unknown symbol thermal_cooling_device_register
WARNING: /dev/shm/.KqCZFM/mnt/lib/modules/3.5.0-rc1-2-desktop/kernel/drivers/acpi/video.ko needs unknown symbol thermal_cooling_device_unregister
So I don’t know for sure, but since VirtualBox will not compile, the same issue may be killing KVM/Xen as well perhaps. We will just have to see if any more information comes to light on this subject here.
While the [FONT=inherit !important]Linux[/FONT]](http://www.phoronix.com/scan.php?page=news_item&px=MTExMjk#) 3.5-rc1 kernel was tagged on Saturday, the announcement didn’t come out until today. Regardless, the Linux 3.5-rc1 kernel is now available with lots of interesting changes.
On 06/03/2012 09:06 PM, jdmcdaniel3 wrote:
>
> So I don’t know for sure, but since VirtualBox will not compile, the
> same issue may be killing KVM/Xen as well perhaps. We will just have to
> see if any more information comes to light on this subject here.
The VirtualBox issue is due to an entry point in the kernel named do_mmap()
being changed to no longer make it available from outside code. A
nearly-equivalent routine named do_mmap_pgoff() can be used; however, it is not
exported.
I have contacted the developer that made the changes to inform him that VB uses
these routines, and asking him what the best approach will be to fix the problems.
This problem is not the same as reported by Dale. His error messages are due to
the ‘make modules_install’ step not finishing correctly.
> I have contacted the developer that made the changes to inform him that VB uses
> these routines, and asking him what the best approach will be to fix the problems.
I have heard back (already). This fix will not be easy, and I will be sending it
to the VB developers, rather than trying to fix it myself.
Thanks Larry for the information. I am hoping a fix by one side or the other will be forth coming before Kernel 3.5 is released. It a real problem for me as I use VB all of the time and so it just not going to allow me to do more than a passing run of kernel 3.5 at present. Do we know what problem or enhancement with the kernel was being fixed by the these latest kernel modifications that killed the VB kernel drivers from loading?
> Thanks Larry for the information. I am hoping a fix by one side or the
> other will be forth coming before Kernel 3.5 is released. It a real
> problem for me as I use VB all of the time and so it just not going to
> allow me to do more than a passing run of kernel 3.5 at present. Do we
> know what problem or enhancement with the kernel was being fixed by the
> these latest kernel modifications that killed the VB kernel drivers from
> loading?
You are a little pessimistic on how long it takes to fix these things. As you
will see below, a motivated community geets things done relatively quickly.
The “problem” being fixed was that the memory mapping API expressed by the calls
do_mmap() and do_munmap() are extremely difficult to use correctly; therefore,
they are being removed from public view. Internal users were switched to a
different API. VBox should switch to the wrapper codes in vm_mmap() and
vm_munmap(), which are quite a bit easier to use correctly.
This analysis was provided by Al Viro, who made the kernel change, and he
concludes that VBox likely uses the original calls incorrectly, but he is not
sure. Their code is not structured in a manner that makes it easy to understand,
which is one of the reasons that the VBox modules are not included in the kernel.
I was prepared to kick the problem on to VBox, but I got mail this AM from
Manual Lauss. He has a patch (http://mlau.at/files/vbox-4116-35rc0.patch), that
fixes the compile problem. His statement was “Not completely convinced that it’s
correct, but all my VMs do work with it.”
I have not done much in the way of testing yet, but the patch does allow me to
build the VBox kernel module. YMMV.
I must admit Larry that my pessimism has more to do with what I expect at my work when software problems come up though I was also thinking about how long Oracle would take to release a fix for VirtualBox and that was based on how long it took nVIDIA to get its act together, which for now, apparently it did. I do know that the kernel developers are working hard to make a better kernel. The issue with modifying existing kernel code and just what that does to those that try to use it from the outside is less clear. And by that I mean, its hard to know why certain program commands might have been used. The actual persons that wrote it may even be gone by now. I, like a lot others are concerned about the actual result of your coding as opposed to matching publish program methods. Changing the existing kernel code is like changing the ground rules from which you have been using. We know of course it would be better for Oracle to be working from the inside with free and published code, but for a lot of companies, they just can not let go of something they feel belongs to them. Its a rational that in the long run costs them more in effort than any supposed loss of intellectual properties. In the end though, my life is made easier by using the free VirtualBox product and I hope they can continue to support the Linux kernel as they have done up to now.
Now, for this patch, are we patching the VirtualBox drivers and if so, how is it applied? Please go slow cause not all of us are kernel (or anything else) developers. And as always, your efforts are greatly appreciated.
On 06/04/2012 05:16 PM, jdmcdaniel3 wrote:
>
> Now, for this patch, are we patching the VirtualBox drivers and if so,
> how is it applied? Please go slow cause not all of us are kernel (or
> anything else) developers. And as always, your efforts are greatly
> appreciated.
It is a patch for the VBox code. As usual, one uses the patch utility to apply
the correction. Install patch, and see ‘man patch’ for details on how to use
this utility. I usually use the quilt utility, which is a lot more flexible.
With it, one can apply patches, update them, and then remove the modifications.
Install quilt and see ‘man quilt’ on how to use.
The kernel API is constantly changing, and most updates are to make some aspect
of the kernel be faster, more robust in resisting hardware or software errors,
or easier to use. The rule is that if you make such a change, you are
responsible for fixing any kernel component that is affected. Out-of-kernel
drivers are exempt from the rule.
The VBox driver is not coded in a way that will allow it to be included in the
kernel. It seems to work, but the code is ugly! From what I have read, VBox has
refused to to make the effort to revise the driver. As a result, they will need
to make these periodic changes, but that seems to be a conscious decision.
When I try to patch the correct file using patch, I get the following error message:
james@LinuxMaster:/usr/src/vboxhost-4.1.16> patch --input=/home/james/Documents/vbox-4116-35rc0.patch
can't find file to patch at input line 9
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Make VirtualBox-4.1.16 kernel modules work again on kernels 3.5rc0+
|(after Al Viro removed do_mmap()/do_munmap() from public view).
|
|Manuel Lauss, 20120603
|
|diff -Naurp vboxdrv.old/r0drv/linux/memobj-r0drv-linux.c vboxdrv/r0drv/linux/memobj-r0drv-linux.c
|--- vboxdrv.old/r0drv/linux/memobj-r0drv-linux.c 2012-01-19 13:37:00.000000000 +0100
|+++ vboxdrv/r0drv/linux/memobj-r0drv-linux.c 2012-06-03 09:17:16.417650091 +0200
--------------------------
File to patch:
Its not evident to me what this says is wrong. This is what line nine says:
The file /usr/src/vboxhost-4.1.16/vboxdrv/r0drv/linux/memobj-r0drv-linux.c is present. So, once again, some small detail you need to know keeps it from working it would seem.
Linus Torvalds published the first Linux 3.5 release candidate on Saturday night, although the official release email wasn’t sent until Sunday afternoon. As usual, the first RC of the new kernel version signals the end of the merge window phase at the beginning of the development cycle, during which nearly all of the major changes are made. Aside from a few stragglers, the function set Linux 3.5-rc1 offers should be almost identical to the one in the 3.5 kernel, which is expected to be released in late July or early August.
In the approximately two weeks since Linux 3.4 was released, the kernel developers have integrated features such as uprobes (userspace probes). These can be used by Systemtap and the kernel’s own perf tracing tool to analyse the runtime behaviour of userspace programs. Other important additions to Linux 3.5 include some patches to internal logging functions, championed by Udev maintainer Kay Sievers, which should improve the structured analysis of event logs.
> Its not evident to me what this says is wrong. This is what line nine
> says:
>
>
> Code:
> --------------------
> @@ -491,9 +491,7 @@ DECLHIDDEN(int) rtR0MemObjNativeFree(RTR
> --------------------
>
>
> The file
> /usr/src/vboxhost-4.1.16/vboxdrv/r0drv/linux/memobj-r0drv-linux.c is
> present. So, once again, some small detail you need to know keeps it
> from working it would seem.
You need to keep track of your current working directory and the strip
parameter. In this case, you should be in /usr/src/vboxhost-4.1.16/
and use the switch “-p0”, i.e. strip 0 slashes. The resulting patch command
would be “patch -p1 < path-to_patch_file”.
As the man page says
-pnum or --strip=num
Strip the smallest prefix containing num leading slashes from each
file name found in the patch file. A sequence of one or more adjacent
slashes is counted as a single slash. This controls how file names
found in the patch file are treated, in case you keep your files in a
different directory than the person who sent out the patch. For example,
supposing the file name in the patch file was
/u/howard/src/blurfl/blurfl.c
setting -p0 gives the entire file name unmodified, -p1 gives
u/howard/src/blurfl/blurfl.c
without the leading slash, -p4 gives
blurfl/blurfl.c
and not specifying -p at all just gives you blurfl.c. Whatever you end up
with is looked for either in the current directory, or the
directory specified by the -d option.
Thanks Larry for your help with the patch command. Using the -p0 does not seem intuitive to me and I did not get from the man help that using at least a -p0 was required. I had already changed to the proper folder name. The bottom line is I have patched the VirtualBox source and VirtualBox did compile just fine. Can I assume this patch is for version 4.1.16 only, the most current?
For anyone else wishing to make this same modification in order to use kernel 3.5-rc1 and VirtualBox 4.1.16 at the same time, here is the basics of the commands:
1. Open A terminal session.
2. Download the VirtualBox Patch file: **wget -nc http://mlau.at/files/vbox-4116-35rc0.patch -O $HOME/Downloads/vbox-4116-35rc0.patch**
3. Change to the VirtualBox Folder:** cd /usr/src/vboxhost-4.1.16**
3. Run the VirtualBox Patch File: **sudo patch -p0 --input=$HOME/Downloads/vbox-4116-35rc0.patch**
4. Recompile the VirtualBox File: **sudo /etc/init.d/vboxdrv setup**
The last step would be done after you have loaded the new kernel or it will be done automatically if you have installed dkms. If you want to use dkms with openSUSE 12.1, have a look at this blog on the subject.
On 06/05/2012 07:56 PM, jdmcdaniel3 wrote:
>
> Thanks Larry for your help with the patch command. Using the -p0 does
> not seem intuitive to me and I did not get from the man help that using
> at least a -p0 was required. I had already changed to the proper folder
> name. The bottom line is I have patched the VirtualBox source and
> VirtualBox did compile just fine. Can I assume this patch is for
> version 4.1.16 only, the most current?
It is for 4.1.16, but the same patch will likely be correct for any 4.1.X. The
kernel module vboxdrv changes a lot less than other parts of the VBox system.
I compiled it using SAKC without a problem and VirtualBox 4.1.16 reloaded just fine with the patch Larry gave us and the nVIDIA 295.53 also loaded just fine both with the SANDI script. On a separate note I broke my right arm today and its kind of hard posting a reply here. I sure could use some help with other kernel testers keeping an eye on the kernel releases. Any help would be appreciated.
It seems that the problem with the openSUSE Firewall has come back in a different form and once again, I find Samba will not work when the openSUSE Firewall is enabled. Previously in kernel 3.4, we needed to add the following kernel configuration to get the Firewall and Samba to work together:
CONFIG_NETFILTER_XT_TARGET_LOG=m
Now, I see this parameter is set, but the same old problem result has come back again. Disabling the Firewall allows Samba to work properly it would seem. Unlike the problem before, being able to turn the Firewall on and off at will does work properly. So, its hard to know for sure just what the problem might be. Any other comments would be helpful to hear if indeed you see the same problem or not. I see this issue on three PC’s, but they are all configured the same by me. Since we are creatures of habit, we tend to extend the same issue over and over if its a user setup problem. So, your input is needed if you use Samba and have kernel 3.5-rc2 loaded from any source. Let your voice be known.
As you