Alain Fauconnet wrote: > Hello readers, > > I've posted this to linux-kernel because I thought that it was more > appropriate, but it seemingly has got lost in the noise. > > I'll repost here, hoping for a clue. It's probably not specific to TSL > though. I also realise that's a pretty dirty hack over TSL 2.2. > Unfortunately I can't give TSL 3.0 a try on this box: it will be used > for full production work in a few days and our production standard O/S > is TSL 2.2. Kernel 2.6 was tried out to improve NFS client performance > (it's client of a NetApp NAS). No kind of "support" on this problem > expected of course, but just in case that rings a bell, here it is: > > This is an IBM xSeries dual-P3 1.0Ghz server box with an IBM ServeRAID > 4Mx controller and 3 * IBM 18 Gb SCSI hotswap disks. > Base O/S is Trustix 2.2, manually updated with a 2.6.13 kernel built > from source and a mkinitrd-4.1.18-2 RPM > stolen from FC3 because TSL 2.2's mkinitrd can't handle .ko modules. > > After upgrading to kernel 2.6.13, the machine stops at boot during > initrd processing. After much head-scratching I've figured out that > the "mkdevices /dev" command in the "init" script of the initrd was > looping. > Hand-editing the init script like this:
toss out the initrd, compile everything you need into the kernel, disable everything you don't need. initrds are fine for generic kernels that are supposed to boot on a wide array of boxes from the same build. once you build your own kernel, the point of an initrd disappears (imo) Cheers, -- Morten _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
