I have just tried to upgrade my kernel from 2.6.18 to 2.6.18.1, this raises a number of problems/issues and I was wondering how other people deal with them.
When you run the vmware upgrade to build vmware for the new kernel it complains that the running kernel (2.6.18) is not the same as one you're trying to upgrade to (2.6.18.1) - not surprising really! However it means you have to build the new kernel succesfully before you can upgrade vmware to it, which is a bit sort of messy at least.
Building one of my required added modules (the drivers for the RTL8168 network on the MB) it creates the new module in /lib/modules/2.6.18/kernel/drivers/net because it uses 'uname -r' to get the kernel version. This doesn't work very well when you reboot - no network.
What's the right/best way to patch the kernel to minimise these problems? I created /usr/src/linux-2.6.18.1 as a copy of /usr/src/linux-2.6.18 and applied the 2.6.18.1 patches to the new directory tree. It would seem (in view of the above problems) that this may not be the ideal way to do it. I've now changed names so that I have /usr/src/linux-2.6.18.base (as the original version) and /usr/src/linux-2.6.18 which is the patched version but then it's a bit more difficult to keep track of which version you patched to.
cl@isbd.net wrote:
[...] I was wondering how other people deal with them. When you run the vmware upgrade to build vmware for the new kernel
I deal with that by not using vmware.
[...] Building one of my required added modules (the drivers for the RTL8168 network on the MB) it creates the new module in /lib/modules/2.6.18/kernel/drivers/net because it uses 'uname -r' to get the kernel version. This doesn't work very well when you reboot - no network.
I'd hack its Makefile to stop it being so stupid and use a make variable for the target kernel version.
Hope that helps,
On Wed, Nov 01, 2006 at 02:59:33PM +0000, MJ Ray wrote:
cl@isbd.net wrote:
[...] I was wondering how other people deal with them. When you run the vmware upgrade to build vmware for the new kernel
I deal with that by not using vmware.
So what do you use instead? (I have an occasional need to run an Access database, among other things)
[...] Building one of my required added modules (the drivers for the RTL8168 network on the MB) it creates the new module in /lib/modules/2.6.18/kernel/drivers/net because it uses 'uname -r' to get the kernel version. This doesn't work very well when you reboot - no network.
I'd hack its Makefile to stop it being so stupid and use a make variable for the target kernel version.
Yes, that's possible, I just wondered if there was a 'right' way to do it. Presumably in a while the RTL5168 will be supported by the standard kernel and I won't need the custom add-on.
cl@isbd.net wrote:
On Wed, Nov 01, 2006 at 02:59:33PM +0000, MJ Ray wrote:
cl@isbd.net wrote:
[...] I was wondering how other people deal with them. When you run the vmware upgrade to build vmware for the new kernel
I deal with that by not using vmware.
So what do you use instead?
After this length of time, I'm not locked into any Microsoft Windows applications. On the rare occasion I do need something from a Microsoft application, I either convert using a native application (xls2csv, OpenOffice.org and so on, but not so easy for Access), run something under WINE or very very rarely use a client's remote desktop to get at the data.
(I have an occasional need to run an Access database, among other things)
I'd look for a way to convert it. I think it's not usually worth the costs of running Access - as well as maintenance costs like you seem to be suffering, I've had applications developed on it break on newer releases of Access, corrupt data (the JET engine bugs, years ago) and talk incompatible nonsense to database servers.
I know the above probably isn't much help, but I was asked...
On Wed, Nov 01, 2006 at 04:00:08PM +0000, MJ Ray wrote:
(I have an occasional need to run an Access database, among other things)
I'd look for a way to convert it. I think it's not usually worth the costs of running Access - as well as maintenance costs like you seem to be suffering, I've had applications developed on it break on newer releases of Access, corrupt data (the JET engine bugs, years ago) and talk incompatible nonsense to database servers.
That was the approach I tried a year or so ago, I wasted far, far, far more time than was needed simply to install Vmware and run it that way.
I tried knoda and rekall and invested quite a bit of time in trying to produce an equivalent application to my Access one. It just wasn't a sensible approach, my database is quite simple but the forms and reports are where neither knoda nor rekall could do (at least not without a huge effort) what I have in Access.
I also tried OpenOffice but again didn't really find I was making much progress towards what I wanted.
I know the above probably isn't much help, but I was asked...
It's exactly the way I tried to go but it wasn't really possible.
Hi Chris
On Wednesday 01 November 2006 13:41, cl@isbd.net wrote:
What's the right/best way to patch the kernel to minimise these problems? I created /usr/src/linux-2.6.18.1 as a copy of /usr/src/linux-2.6.18 and applied the 2.6.18.1 patches to the new directory tree. It would seem (in view of the above problems) that this may not be the ideal way to do it. I've now changed names so that I have /usr/src/linux-2.6.18.base (as the original version) and /usr/src/linux-2.6.18 which is the patched version but then it's a bit more difficult to keep track of which version you patched to.
Generally, I jump on the kernel upgrade bandwagon sometime after the primary version release and download a full tarball of the required version. As an example, my main kernel is a 2.6.17.7, although I am monitoring the 2.6.18 cycle.. Even after downloading the full tarball, I end up patching with a third party patch set, so on occasion have to deal with rejected hunks... The last time I had to deal with an incremental 2.6.xx.x kernel patch, it had to be applied to a virgin primary release. This would mean that you would need a clean, unpatched 2.6.18 tree to start from - There is little need to keep a complete tree on the build system as long as you retain the original tarball..
Once untarred and patched, the first thing to do is to check the EXTRAVERSION variable at the top of the kernel's Makefile. If you want to add an additional identifier, use the LOCALVERSION option during the config stage (and check the .config afterwards)..
As to how I track which version and source currently installed - Compiling in /usr/src/linux-yadda is deprecated in favour of a "where ever you want" policy, so I will sometimes use /tmp/linux, and always with make-kpkg. The /tmp directory gets cleaned out on each reboot, but make-kpkg will produce a set of easy to install Debian packages which will get ferreted away in a local repository..
With regards your problem compiling an RTL8168 driver... After downloading the sources direct from Realtek, it would appear that they need "adjustments" before you can compile against a 2.6.18.x kernel - MODULE_PARM has been dropped and needs to be replaced module_param_array (see http://www.atworkonline.it/~bibe/etch/index.htm for details).. You should be able to override the kernel version by passing it as a make option, e.g. `make KVER=2.6.18.1-foo`, failing that, edit the make file..
What's vmware ? <ducks>
Regards, Paul.
On Wed, Nov 01, 2006 at 08:21:35PM +0000, Paul wrote:
As to how I track which version and source currently installed - Compiling in /usr/src/linux-yadda is deprecated in favour of a "where ever you want" policy, so I will sometimes use /tmp/linux, and always with make-kpkg. The /tmp directory gets cleaned out on each reboot, but make-kpkg will produce a set of easy to install Debian packages which will get ferreted away in a local repository..
Hmm, that's one way I suppose, I'm Slackware though.
With regards your problem compiling an RTL8168 driver... After downloading the sources direct from Realtek, it would appear that they need "adjustments" before you can compile against a 2.6.18.x kernel - MODULE_PARM has been dropped and needs to be replaced module_param_array (see http://www.atworkonline.it/~bibe/etch/index.htm for details).. You should be able to override the kernel version by passing it as a make option, e.g. `make KVER=2.6.18.1-foo`, failing that, edit the make file..
No, I've got through that already, I had the RTL8168 driver working in the base 2.6.18 kernel, it's just that when built in the 2.6.18.1 area it still generated a 2.6.18 module because I built it while running a 2.6.18 kernel.
What seems to be the way is to do what I originally did which was to make a copy of /usr/linux/2.6.18 in /usr/linux/2.6.18.1 and then apply the 2.6.18.1 patch in the new area. Then you have to build the new kernel *twice*. You build it once and run it so you have a 2.6.18.1 kernel running, the second build then builds the 'custom' modules correctly (which fail in the first build).
I now have a working 2.6.18.1 kernel which even has working Jmicron PATA drivers so I now have *two* CD/DVD drives! :-)
What's vmware ? <ducks>
It's actually amazingly *simple* to install considering what it does. Apart from the need to build it under the kernel you want it to run it under 'just works'.
Hi Chris
On Wednesday 01 November 2006 21:21, cl@isbd.net wrote:
What seems to be the way is to do what I originally did which was to make a copy of /usr/linux/2.6.18 in /usr/linux/2.6.18.1 and then apply the 2.6.18.1 patch in the new area. Then you have to build the new kernel *twice*. You build it once and run it so you have a 2.6.18.1 kernel running, the second build then builds the 'custom' modules correctly (which fail in the first build).
Any third party kernel module that hard codes the kernel path to /lib/modules/`uname -r`/build and won't let you specify an alternative is severely broken (in my opinion). There *should*_always_ be a command line variable accepted so that a user can compile against a different kernel tree. How else would one expect to build for a different target kernel or even cross compile for a different architecture !
If you have to mess around building a kernel twice just for one driver, then either a bug report needs to be filed, or the h/w changed for something with a sane driver - Just my opinion of course ;-)
Regards, Paul.
/me goes looking for an adeos patch for x86_64 against a 2.6.18.x kernel - New toy on order...
On Wed, Nov 01, 2006 at 09:41:20PM +0000, Paul wrote:
Hi Chris
On Wednesday 01 November 2006 21:21, cl@isbd.net wrote:
What seems to be the way is to do what I originally did which was to make a copy of /usr/linux/2.6.18 in /usr/linux/2.6.18.1 and then apply the 2.6.18.1 patch in the new area. Then you have to build the new kernel *twice*. You build it once and run it so you have a 2.6.18.1 kernel running, the second build then builds the 'custom' modules correctly (which fail in the first build).
Any third party kernel module that hard codes the kernel path to /lib/modules/`uname -r`/build and won't let you specify an alternative is severely broken (in my opinion). There *should*_always_ be a command line variable accepted so that a user can compile against a different kernel tree. How else would one expect to build for a different target kernel or even cross compile for a different architecture !
Yes, quite, and what happens if the module is needed for the kernel to run!
I think that ultimately the RTL8168 drivers will get incorporated into the kernel so that problem will go away.
The Vmware drivers are, no doubt, expecting to be added to an existing working system rather than being built as you are building a new kernel.
If you have to mess around building a kernel twice just for one driver, then either a bug report needs to be filed, or the h/w changed for something with a sane driver - Just my opinion of course ;-)
I think with the RTL8168 it's just that they're very new, as you know I had quite a few issues with the Abit AB9 Pro motherboard simply because it's so new.
-
cl＠isbd.net -
MJ Ray -
Paul