Yeah, I've got the part down on how to get the new driver into the initrd.img but I'll check out that page to make sure that I'm not screwing up a step. I guess a question I should ask is if the initrd.img is kernel dependant? I'm assuming the modules/drivers are to some extent, since our new cciss.o module is. I placed the new cciss.o into our exisiting initrd.img ( 2.4.21-4.ELBOOT ) and put a new vmlinuz ( 2.4.21-15 ) in there for PXE, but the kickstart still doesn't work. How would I go about rebuilding all the OTHER drivers in the initrd.img to be compatible with 2.4.21-15? Or do I even have to? Like I said, my knowledge of how the kernel modules, initrd and vmlinuz interact is hazy at best. I installed the actual 2.4.21-15 kernel on our PXE/kickstart server and booted to it and it worked fine, but so far, dropping the 2.4.21-15 compatible cciss.o into the existing initrd.img ( 2.4.21-4.ELBOOT ) and putting a new vmlinuz ( 2.4.21-15 ) into the PXE tftp area isn't working and it's starting to confuse me even more. ( If that's even possible.. ;) ) The difference between a regular initrd.img ( made via mkinitrd ) and the PXE version: 2.4.21-15 ./init_nonboot/lib/scsi_mod.o ./init_nonboot/lib/sd_mod.o ./init_nonboot/lib/cciss.o ./init_nonboot/lib/lvm-mod.o ./init_nonboot/lib/jbd.o ./init_nonboot/lib/ext3.o ./init_nonboot/bin/nash ./init_nonboot/bin/insmod ./init_nonboot/bin/vgwrapper ./init_nonboot/bin/vgscan ./init_nonboot/bin/vgchange ./init_nonboot/linuxrc 2.4.21-4 ( our PXE initrd.img from the RH3.0AS cd ) ./init/modules/module-info ./init/modules/pcitable ./init/modules/modules.dep ./init/modules/modules.pcimap ./init/modules/modules.cgz ./init/sbin/loader ./init/sbin/init ./init/etc/terminfo/l/linux ./init/etc/terminfo/x/xterm ./init/etc/terminfo/v/vt100 ./init/etc/terminfo/v/vt100-nav ./init/etc/terminfo/b/bterm ./init/etc/passwd ./init/etc/arch ./init/etc/keymaps.gz ./init/etc/screenfont.gz ./init/etc/lang-table ./init/etc/loader.tr ./init/etc/font.bgf.gz ./init/etc/pcmcia/config ./init/etc/ramfs.img ./init/.buildstamp ./init/.profile Thanks. -- sh -----Original Message----- From: Greg Dickie [mailto:greg@xxxxxxxxx] Sent: Thursday, November 18, 2004 3:59 PM To: Steven Hajducko Cc: 'anaconda-devel-list@xxxxxxxxxx' Subject: Re: Picking apart buildinstall I wouldn't use buildinstall although it is possible. You would need to regenerate your kernel-BOOT rpm with the new driver included in it, then somehow massage buildinstall to run. This will regenerate all your images. I would directly hack initrd.img. Here is the basic procedure: zcat initrd.img > initrd.ext2 mount -o loop initrd.ext2 /tmp/tt from this you can get the modules directory then follow the instructions in http://faq.linux.cz/pracovni/driver-disk-howto to see how to get your new module in there. HTH, Greg On Thu, 2004-11-18 at 15:39 -0800, Steven Hajducko wrote: > Hi, > > We've currently got a PXE/kickstart setup on RH3.0AS that works fine. > Unfortunately, the new hardware that arrived ( HP DL360's ) use a newer > array controller and the version of the driver we have doesn't work. We got > the newer driver from HP and it only works with kernel versions 2.4.21-9 and > 2.4.21-15. The kernel version we have on PXE is 2.4.21-4.ELBOOT. I need to > build a new initrd.img for PXE with the new driver and works on 2.4.21-15. > I'm not entirely sure however, how to build the initrd.img that is usuable > by PXE. It was suggested on another list that I use the anaconda-runtime > buildinstall instead of trying to figure out how to create it myself. > > Unfortunately, our setup isn't exactly standard. We don't have any 'tree' > to speak of. We have the following: > > /opt/kickstart/RedHat/RPMS > /tftpboot > > For those unfamiliar with PXE, it requires tftp to grab the initrd.img and > vmlinuz. So, that's where our initrd.img and vmlinuz are. In the RPMS dir, > we basically have every single RPM we've ever used. Often times, we have > several version of the same RPMS in there. Then, in /opt/kickstart, we have > our separate config.ks files for the types of machines we build. So I'm not > sure where exactly the 'base' of our tree would be as it doesn't exactly > resemble the typical Redhat CD and I'm figuring this is why I can't get > buildinstall to work. > > I did the hdlist and pkgorder, although I don't really need to build a > custom anaconda or anything. I just want to get buildinstall to build the > PXE initrd.img. > > The following happens when running buildinstall: > > ./buildinstall --product "RedHad Advanced Server" --comp dist-9 --pkgorder > /tmp/pkgorder.txt --version 9 --release "3.0" /opt/kickstart/ > Running buildinstall... > /opt/kickstart/buildinstall.tree.4467 /usr/lib/anaconda-runtime > /usr/lib/anaconda-runtime > Going to run buildinstall again > > Advanced/RedHat/RPMS > Usage: buildinstall [--comp <component>] [--pkgorder <file>] [--version > <version>] [--product <product>] [--release <comment>] <root> > /opt/kickstart/buildinstall.tree.4467/buildinstall --buildinstdir > /opt/kickstart/buildinstall.tree.4467 --second --pkgorder /tmp/pkgorder.txt > --comp dist-9 --version 9 --release "3.0" --product "RedHad Advanced Server" > /opt/kickstart/ > > and then it exits. > > I was wondering if anyone could help me out in identifying the parts I need > out of buildinstall to just build an initrd.img or even if that's possible. > I'm a little hazy on how the whole thing works to begin with, so please bear > with me. I'm not sure if I need a custom vmlinuz as well, but at the > moment, I put the 2.4.21-15 vmlinuz ( from the regular kernel rpm ) and our > old initrd.img with the new ccisss.o driver into /tftpboot and it's still > not working. > > Any help with this is appreciated. > > -- > sh > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Greg Dickie <greg@xxxxxxxxx> Maximum Throughput
