You are not logged in.
Pages: 1
just curious if there will be a package for this in unstable in the near future? i wouldn't mind testing out the new kernel. of course i would not want it as a replacement for my current stock kernel.
AKA uknowme
I am not your friend
Offline
Yeah... I wouldn't mind playing around with that kernel as well... but, as a personal policy, I like to wait a few releases before upgrading to a new minor kernel and I wouldn't mind the option...
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
well and manybe some /abs/kernels
2.4 series
2.6 series
wolk
and something like that just maybe
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU/ d- s: a- C L U P+ L+++ E--- W+
N 0+ K- W-- !O !M V-- PS+ PE- V++ PGP T 5 Z+ R* TV+ B+
DI-- D- G-- e-- h! r++ z+ z*
------END GEEK CODE BLOCK------
Offline
I think it's more a question of how to add custom kernels without blowing away your original one. I've been brainstorming this one a little bit, but it's difficult to figure out.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
You can use this PKGBUILD (http://www.chez.com/orelien/archlinux/PKGBUILD.kernel)
Just set the pkgextraver field to whatever you want, for instance: "-custom", and makepkg will generate a "kernel-custom-2.4.21-1.pkg.tar.gz" pkg, installing the following files:
/boot/vmlinuz-2.4.21-custom
/boot/System.map-2.4.21-custom
/lib/modules/2.4.21-custom/{modules}
/usr/src/linux-2.4.21-custom/include/{headers}
Also update to the rc.sysinit script to handle the new layout:
kernel_version=`uname -r`
[ -h /boot/System.map ] && rm /boot/System.map
[ -f /boot/System.map-$kernel_version ] && ln -s /boot/System.map-$kernel_version /boot/System.map
[ -h /usr/src/linux ] && rm /usr/src/linux
[ -d /usr/src/linux-$kernel_version ] && ln -s /usr/src/linux-$kernel_version /usr/src/linux
Then, you can also set the pkgextraver to "", in order to rebuild the default arch kernel with the same layout, so that it does not conflict with other kernel pkgs
Offline
I used that for my current kernel. I was thinking more system-wide (like how do you handle packages like pcmcia-cs and wlan-ng?). A note or two... my system exists without the System.map symlink... my impression is that the different system map name is actually compiled into the kernel... that source link is a good one though... though I don't know if it's all that needed, you'd think that people would know which source directory their kernel was built with (and, IIRC, /lib/modules/`uname -r`/build points to the right place no matter what).
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
like how do you handle packages like pcmcia-cs and wlan-ng
Sorry I don't use these ones, so I didn't get your point...
kernel pkg is not marked as a dep, and from the filelist they don't depend on the kernel layout.
Can you be more specific?
In fact, my main concern is about i2c or lm_sensors packages, for instance, that need to be built against a specific kernel. These pkgs include user-space modules that can be built outside the kernel tree. So, it would require to build as many different i2c pkgs as installed kernel pkgs...
system map name is actually compiled into the kernel
Yes, that was for legacy purpose, and some other apps other than the kernel itself are using the System.map, and I'm not sure if they can all find it without a symlink...
/lib/modules/`uname -r`/build points to the right place
Sure. In fact I was thinking about apps that are looking for headers directly into /usr/src/linux directory.
Offline
pcmcia-cs and wlan-ng are just two examples of kernel packages. If you compile pcmcia-cs in a certain way you'll get kernel modules, for sure with wlan-ng. i2c and lm_sensors are probably the same. How do you handle multiple versions of these packages for different kernels? That's where I see the biggest difficulty.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
For i2c & lm_sensors, the trick is to get i2c & lm_sensors modules to be compiled inside the kernel pkg itself, by patching kernel sources.
But, as you mentionned it, it can't be considered as a system-wide solution.
Offline
Having a seperate version for each officially supported kernel is an option (like pcmcia-cs-vaio and pcmcia-cs-scsi), but an ugly one. Every time you change something that's related to all the kernels, you have to recompile all packages... and that's ugly...
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
ls /usr/abs/kernels/
kernel kernel-scsi kernel-wolk kernel2.5
[jlvsimoes@routty jlvsimoes]$ uname -r
2.4.20-wolk4.3s
hehe ugly is my midle name
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU/ d- s: a- C L U P+ L+++ E--- W+
N 0+ K- W-- !O !M V-- PS+ PE- V++ PGP T 5 Z+ R* TV+ B+
DI-- D- G-- e-- h! r++ z+ z*
------END GEEK CODE BLOCK------
Offline
Pages: 1