Kernel problems with unionfs and Ubuntu gutsy

[R. F. Grant]

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