Re: Backporting 2.4.23 kernel packages
Matthew Grant [EMAIL PROTECTED] wrote: On Fri, 2003-12-05 at 18:41, Andrew Pollock wrote: Where I'm working, we have Debian stable deployed on a number of boxes. For hardware support reasons, we've had to grab newer kernels from testing, and have been reasonably successful at not dragging in half of testing with them. We're going to want to upgrade everything to 2.4.23 ASAP, but I'd prefer not to drag in half of unstable with this upgrade. So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Is it as simple as taking the source package and building it in a stable pbuilder chroot, or is there more black magic involved with kernel packages? Simple. Just take the kernel-source-2.4.34.tar.bz2 tar ball out of the sid system and recompile using make-kpkg under woody, using the apporiate config file If you are using alsa you need a backport of alsa-source, the version in woody does not compile aginst 2.4.23 anymore (up to 22 it worked fine). cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Wed, Dec 10, 2003 at 09:32:16AM +1100, Brian May wrote: I believe the kernel raid1 autodetection only works if raid1 is compiled into the kernel. In anycase, initrd images generated from mkinitrd in Debian do not autodetect. It is possible to invite the autodetection from initrd using the appropriate ioctl. Our not too elegant solution is available here: http://debian.caesar.elte.hu/dists/woody/itk/source/initrd-raid-autorun_0.2.dsc http://debian.caesar.elte.hu/dists/woody/itk/source/initrd-raid-autorun_0.2.tar.gz This contains a script which hooks the automagically generated ramdisk during the build phase. Gabor
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Wed, Dec 10, 2003 at 09:26:39PM +1100, Herbert Xu wrote: If you don't have the underlying devices there RAID autodetection will not work. Well, if you have no devices, you cant detect them. However, on boot you most likely do have the devices. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
Brian May [EMAIL PROTECTED] wrote:
IIRC, There is a parameter to mdadm (--scan?) that could be used for
this, but when I asked the initrd maintainer I was given a good reason
why it was not used (sorry; I can't remember what this was now; it might
simply be that the mdadm code is unreliable, inefficient, or buggy).
The reason is that we need hotplug support or something similar
before RAID autodetection will make sense.
If you don't have the underlying devices there RAID autodetection
will not work.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Backporting 2.4.23 kernel packages
Simple. Just take the kernel-source-2.4.34.tar.bz2 tar ball out of the sid system and recompile using make-kpkg under woody, using the apporiate config file On Fri, 2003-12-05 at 18:41, Andrew Pollock wrote: Where I'm working, we have Debian stable deployed on a number of boxes. For hardware support reasons, we've had to grab newer kernels from testing, and have been reasonably successful at not dragging in half of testing with them. We're going to want to upgrade everything to 2.4.23 ASAP, but I'd prefer not to drag in half of unstable with this upgrade. So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Is it as simple as taking the source package and building it in a stable pbuilder chroot, or is there more black magic involved with kernel packages? Thanks Andrew -- === Matthew Grant/\ ^/\^ [EMAIL PROTECTED] /\ A Linux Network Guy /~~\^/~~\_/~\___/~~\/**\ ===GPG KeyID: 2EE20270 FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270== signature.asc Description: This is a digitally signed message part
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
Brian May [EMAIL PROTECTED] writes: On Sun, Dec 07, 2003 at 02:02:10PM +1100, Russell Coker wrote: The recent versions of the package have significant problems if you want to convert to or from devfs. The Debian mkinitrd has become too complex to manage so I have chosen not to bother. This seems strange, perhaps the process is not entirely obvious, but I wouldn't have thought it be too difficult. However, I have been disappointed with the initrd script for Debian in that support for autodetecting software RAID1 is poor (read: non-existant), and while RAID1 will work if the harddisks are plugged in exactly the same way each time, the fact remains that the configuration is hardcoded in the initrd script so if you move all harddisks on one RAID set to different busses (for instance), it will stop working. This is distinct from the autodetection in the kernel that is capable of automatically scanning all harddisks on all busses to find RAID devices. Why can't you use the kernel autoconfig or does that only work with build-in drivers? So yes, maybe initrd/initramfs is the way of the future (I have read proposals that would make loading modules in an initramfs compulsory for all systems), but I think there are still a few issues that need to be resolved first. Loading the modules won't help you getting raid or lvm configured. MfG Goswin
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Tue, Dec 09, 2003 at 06:31:19PM +0100, Goswin von Brederlow wrote: This is distinct from the autodetection in the kernel that is capable of automatically scanning all harddisks on all busses to find RAID devices. Why can't you use the kernel autoconfig or does that only work with build-in drivers? I believe the kernel raid1 autodetection only works if raid1 is compiled into the kernel. In anycase, initrd images generated from mkinitrd in Debian do not autodetect. IIRC, There is a parameter to mdadm (--scan?) that could be used for this, but when I asked the initrd maintainer I was given a good reason why it was not used (sorry; I can't remember what this was now; it might simply be that the mdadm code is unreliable, inefficient, or buggy). -- Brian May [EMAIL PROTECTED]
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Sun, Dec 07, 2003 at 02:02:10PM +1100, Russell Coker wrote: The recent versions of the package have significant problems if you want to convert to or from devfs. The Debian mkinitrd has become too complex to manage so I have chosen not to bother. This seems strange, perhaps the process is not entirely obvious, but I wouldn't have thought it be too difficult. However, I have been disappointed with the initrd script for Debian in that support for autodetecting software RAID1 is poor (read: non-existant), and while RAID1 will work if the harddisks are plugged in exactly the same way each time, the fact remains that the configuration is hardcoded in the initrd script so if you move all harddisks on one RAID set to different busses (for instance), it will stop working. This is distinct from the autodetection in the kernel that is capable of automatically scanning all harddisks on all busses to find RAID devices. So yes, maybe initrd/initramfs is the way of the future (I have read proposals that would make loading modules in an initramfs compulsory for all systems), but I think there are still a few issues that need to be resolved first. -- Brian May [EMAIL PROTECTED]
Re: Backporting 2.4.23 kernel packages
On Sat, 6 Dec 2003 08:35, Andrew Pollock [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 11:08:53PM +1100, Russell Coker wrote: I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? It only depends on coreutils|fileutils, so there's no problems in that regard. What about modutils and initrd-tools? What is needed for initrd-tools? I've given up on using initrd's for kernels I compile. As for modutils, that's probably a bug in kernel-package that it doesn't list dependencies. Add the following to your /etc/apt/sources.list file to get Brian's back-ports of modutils and all other things: deb http://www.microcomaustralia.com.au/debian/ stable main -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backporting 2.4.23 kernel packages
On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote: On Sat, 6 Dec 2003 08:35, Andrew Pollock [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 11:08:53PM +1100, Russell Coker wrote: I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? It only depends on coreutils|fileutils, so there's no problems in that regard. What about modutils and initrd-tools? What is needed for initrd-tools? I've given up on using initrd's for kernels I compile. Ah, there's the catch. I don't (usually). I'd like to take the source of a kernel-image-2.4.23 package and do whatever's necessary to get it to install on a woody system without having to drag in half of sarge/sid to satisfy dependencies. This is where I was going with my initial posting. Sorry if this wasn't clear. At present, for say 2.4.22, I've taken the kernel-image-2.4.22-3-686 package from sarge, along with whatever dependencies required, and installed on it woody. Problem is, more often than not, modutils or initrd-tools has a libc6 dependency, and well, everything goes downhill from there... As for modutils, that's probably a bug in kernel-package that it doesn't list dependencies. Add the following to your /etc/apt/sources.list file to get Brian's back-ports of modutils and all other things: deb http://www.microcomaustralia.com.au/debian/ stable main Thanks. Andrew
Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote: What is needed for initrd-tools? I've given up on using initrd's for kernels I compile. That's sad. initrd saved my bacon more than once. ;-) If you like to compile vanilla kernels, either find the Debian cramfs-initrd patch or use romfs. Then change mkinitrd.conf(5) to look like this: MKIMAGE=genromfs -d %s -f %s I've had problems with BUSYBOX=yes, so I don't include it. (I should have debugged it -- had to do w/mount and /etc/fstab, but I didn't have the time.) mkinitrd is pretty good about finding your required modules, but it sometimes doesn't get it right. Always mount the romfs file and make sure the modules are there and will be loaded (/etc/modules). Good luck! -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpCWQVvYCpps.pgp Description: PGP signature
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Sun, 7 Dec 2003 12:02, Chad Walstrom [EMAIL PROTECTED] wrote: That's sad. initrd saved my bacon more than once. ;-) If you like to Initrd broke my systems more than once. The recent versions of the package have significant problems if you want to convert to or from devfs. The Debian mkinitrd has become too complex to manage so I have chosen not to bother. compile vanilla kernels, either find the Debian cramfs-initrd patch or use romfs. Then change mkinitrd.conf(5) to look like this: MKIMAGE=genromfs -d %s -f %s MKIMAGE='genromfs -f /dev/fd/1 -d %s | gzip -9 %s' The above is a better option. mkinitrd is pretty good about finding your required modules, but it sometimes doesn't get it right. Always mount the romfs file and make sure the modules are there and will be loaded (/etc/modules). I know, that's why I wrote a Perl script to get the right modules and also create a modules.dep file which has only the necessary data (attached). This saves ~40k for modules.dep alone and much more by avoiding unneeded modules. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page copy-needed-modules Description: Perl program
Re: Backporting 2.4.23 kernel packages
On Fri, 5 Dec 2003 16:41, Andrew Pollock [EMAIL PROTECTED] wrote: So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Why not just use a machine running unstable to do the compile? I use unstable machines to compile all my kernels, they install and run fine on woody systems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backporting 2.4.23 kernel packages
On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote: On Fri, 5 Dec 2003 16:41, Andrew Pollock [EMAIL PROTECTED] wrote: So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Why not just use a machine running unstable to do the compile? I use unstable machines to compile all my kernels, they install and run fine on woody systems. I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? Andrew
Re: Backporting 2.4.23 kernel packages
On Fri, 5 Dec 2003 18:30, Andrew Pollock [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote: On Fri, 5 Dec 2003 16:41, Andrew Pollock [EMAIL PROTECTED] wrote: So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Why not just use a machine running unstable to do the compile? I use unstable machines to compile all my kernels, they install and run fine on woody systems. I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? It only depends on coreutils|fileutils, so there's no problems in that regard. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backporting 2.4.23 kernel packages
In article [EMAIL PROTECTED], Russell Coker [EMAIL PROTECTED] wrote: On Fri, 5 Dec 2003 18:30, Andrew Pollock [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote: On Fri, 5 Dec 2003 16:41, Andrew Pollock [EMAIL PROTECTED] wrote: So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Why not just use a machine running unstable to do the compile? I use unstable machines to compile all my kernels, they install and run fine on woody systems. I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? It only depends on coreutils|fileutils, so there's no problems in that regard. Hmm, last week I compiled a 2.4.23 kernel on my unstable desktop, created a kernel-image package with make-kpgp, and it didn't install on a plain woody machine. The depmod part failed. On the 'stable' machine, I updated to modutils from Adrian Bunk's sarge-to-woody backport archive, and then it suddenly worked. Mike.
Re: Backporting 2.4.23 kernel packages
On Fri, 5 Dec 2003 23:32, Miquel van Smoorenburg [EMAIL PROTECTED] wrote: Hmm, last week I compiled a 2.4.23 kernel on my unstable desktop, created a kernel-image package with make-kpgp, and it didn't install on a plain woody machine. The depmod part failed. On the 'stable' machine, I updated to modutils from Adrian Bunk's sarge-to-woody backport archive, and then it suddenly worked. I've just noticed that all my woody machines have a modutils backport from Brian May. Maybe this is a bug in kernel-package whereby it's not adding correct dependencies? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backporting 2.4.23 kernel packages
#include hallo.h * Andrew Pollock [Fri, Dec 05 2003, 03:41:14PM]: Is it as simple as taking the source package and building it in a stable pbuilder chroot, or is there more black magic involved with kernel packages? AFAIK you need at least updated modutils and procps. And you should use the default compiler in Woody to build it, otherwise your customers may be not able to build additional kernel modules. MfG, Eduard. -- CHS hobbies: Linux, IRC - ehm ja - get a life! ij life? wasn das? CHS ij: das is das problem vor dem du stehst wenn du im urlaub ohne computer bist ij CHS: urlaub? noch son unbekanntes wort...
Re: Backporting 2.4.23 kernel packages
Andrew Pollock [EMAIL PROTECTED] writes: On Fri, Dec 05, 2003 at 05:59:40PM +1100, Russell Coker wrote: On Fri, 5 Dec 2003 16:41, Andrew Pollock [EMAIL PROTECTED] wrote: So, I was wondering how to go about taking the source package for 2.4.23-686 (and the SMP version) and backport them to stable? Why not just use a machine running unstable to do the compile? I use unstable machines to compile all my kernels, they install and run fine on woody systems. I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? Andrew No. The manually added versioned depends are there for a reason. MfG Goswin
Re: Backporting 2.4.23 kernel packages
On Fri, Dec 05, 2003 at 11:08:53PM +1100, Russell Coker wrote: I presume I can lower the dependencies on things like modutils and whatnot down to the versions that are in stable with no ill-effects? It only depends on coreutils|fileutils, so there's no problems in that regard. What about modutils and initrd-tools?
