Hi all, We recently got some new PCs with more recent hardware. The existing FAI setup we had no longer worked with the new hardware - presumably because the fai kernels we were using (Fai 3.1.8) did not contain the necessary drivers.
I began setting up a new FAI server from scratch on a new PC (so as not to break the existing FAI server which still works for all our older PCs). The fai versions I am using are: fai-client 3.2.4 fai-doc 3.2.4 fai-quickstart 3.2.4 fai-server 3.2.4 The PC I am installing the server on is running Ubuntu Feisty: Linux 2.6.20-16-generic #2 SMP Tue Feb 12 05:41:34 UTC 2008 i686 GNU/Linux I am trying to install Ubuntu Gutsy onto the client PCs (since the Gutsy kernel contains the necessary hardware drivers). Doing a manual install of Gutsy on a new PC works just fine. The trick, then, seems to be getting a correctly functioning kernel for FAI to use. As far as I can tell, the requirements are: 1) Must be able to run the hardware (so at least 2.6.22) 2) Must be patchable so that unionfs will work After trying many kernels, I also find an extra annoyance. The new PCs contain Intel Q35 motherboards which contain a known bug: they will not boot from a regular kernel unless you add pci=nommconf or acpi=off. There is a patch that is supposed to fix this for 2.6.24 kernels, although I have not had much luck with this. Anyway, I finally managed to build a kernel that would boot the new hardware. I built it by: - installing a new PC with Ubuntu Gutsy by hand - downloading the 2.6.24.2 kernel source - downloading the correct unionfs patch for this kernel (unionfs-2.2.4_for_2.6.24.2.diff.gz) and applying it (no error messages) - copying the existing kernel config file from Gutsy's 2.6.22 kernel (and running make menuconfig to add unionfs to the kernel) and using it to build a new 2.6.24 kernel Installing this kernel on the new PC, it booted up fine as long as I included the comment pci=nommconf in the boot parameters. (I tried the kernel patch to fix the mmconf problem, but that kernel refused to boot.) Anyway, I then installed the newly created 2.6.24.2 kernel in the nfsroot on the fai server, and then copied the linux-image and initrd files to /srv/tftp/fai. I tweaked the config file in pxelinux.cfg to refer to this new kernel. Then I set fai going. (We run a dhcp server to kickstart FAI with a network book. This all seems to work just fine.) Fai starts up, finds the correct kernel, and begins loading drivers. (If I do not include the pci=nommconf bit in the pxelinux.cfg file then it just hangs almost immediately, but it seems to start working in the usual way if I do include it). However, it then crashes out with a kernel panic: Kernel panic - not syncing: Attempted to kill init! This occurs just after loading drivers for USB, Sata drives and the CD drive. I have also tried building a kernel from the Ubuntu gutsy archive (2.6.22-14.52)and managed to apply the unionfs patch (albeit with some error messages). This will also boot the new hardware (with the pci=nommconf option) but crashes in the same way when booting with FAI. Interestingly, this kernel will *occasionally* boot an older pc into FAI, but more often than not it hangs just before loading the unionfs stuff. (I have been unable to reproduce building this kernel as well - it always crashes out during the build of the unionfs stuff, so I'm not sure what magic I used the first time round.) So, the questions: - If a kernel will boot the PC in normal circumstances, is it unreasonable to assume that it should also just work as the fai kernel? (assuming unionfs is correctly working, of course...) - Is adding a boot tag pci=nommconf in the fai pxelinux.cfg file likely to causeproblems? - Are there any known problem in trying to use FAI to install ubuntu gutsy (from a feisty server) - Does anyone have any idea how to resolve this problem? I can, of course, provide any other information required. Fai does not get far enough to start producing logs, though... Sorry for the long post - just trying to explain what has been a long and frustrating process thus far... Regards, Richard Grant University of Leicester