Re: Kernel problems with unionfs and Ubuntu gutsy
On 21 Feb 2008, at 3:42 pm, R. F. Grant wrote: 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. I've successfully FAI installed HP Deskpro 7800 desktops, which have a Q35 chipset, using FAI 3.1.8 with a 2.6.24 kernel. The kicker was the e1000e ethernet driver that these machines need. Neither of the above kernel options were required with that kernel (this was the 2.6.24-1-686 package from current Debian unstable, rebuilt for etch) I can't address your issues specifically but the above approach worked fine for me. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: Kernel problems with unionfs and Ubuntu gutsy
On 25 Feb 2008, at 11:07 am, Tim Cutts wrote: On 21 Feb 2008, at 3:42 pm, R. F. Grant wrote: 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. I've successfully FAI installed HP Deskpro 7800 desktops, which have a Q35 chipset, using FAI 3.1.8 with a 2.6.24 kernel. The kicker was the e1000e ethernet driver that these machines need. Neither of the above kernel options were required with that kernel (this was the 2.6.24-1-686 package from current Debian unstable, rebuilt for etch) I can't address your issues specifically but the above approach worked fine for me. I should add that the steps I took to make this sid kernel work for FAI 3.1.8 were as follows: 1) Re-build it on an etch system so that the dependencies were correct 2) Add it to our local debarchiver repository, so that apt can see it 3) chroot into the FAI NFS root on the FAI server and 3a) Install the new kernel package 3b) rebuild the initrd file to expect the root filesystem to be NFS (without this, you get a kernel panic because it can't find the root filesystem) 4) Copy the vmlinuz and initrd files out of the NFS root to the tftp directory 5) Add an initrd= stanza to the pxelinux.cfg file so that the initrd gets loaded when the nodes PXE boot I imagine some of this is already in place if you use FAI 3.2.4, because support for initrd images is designed into that version, isn't it? It's worth noting that installing Debian etch on these HP dc7800p machines still requires us to use an additional graphics card in the machines; the Q35 graphics chip requires X.org stuff way newer than what's in etch, so we just slap in an nVidia card in each machine (with the additional advantage that it's DVI; the X packages' autoprobing of the monitor resolution seems to work much better that way, especially with cheaper widescreen -- 1920x1200 -- monitors, such as the Samsung SyncMaster 245B that I have in front of me) Basically, the Linux support for recent HP deskpros is shaky to say the least. Both dc7700 and dc7800 require very recent kernels if you don't want to have to do the acpi=off hack (which has other problems - as soon as you switch off ACPI on these machines the interrupt handling goes to hell, and the mouse becomes very erratic in its responsiveness). I fear this problem is going to become widespread though - other cheap business desktops like the Dell 755 are using the same chipset now. I'm still not convinced even with the 2.6.24 kernel that everything is absolutely right - in particular the SATA disk performance seems pretty poor. But none of this is relevant to FAI so I'll shut up now. :-) Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: Kernel problems with unionfs and Ubuntu gutsy
On 25 Feb 2008, at 2:17 pm, Thomas Lange wrote: On Mon, 25 Feb 2008 13:58:09 +, Tim Cutts [EMAIL PROTECTED] said: I've successfully FAI installed HP Deskpro 7800 desktops, which have a Q35 chipset, using FAI 3.1.8 with a 2.6.24 kernel. The kicker was I think there's a problem to use this approach (building a new kernel) with FAI 3.2.4. We now need unionfs, which is broken in some version of the kernel, so the kernel would work on the hardware. This approach works for you, because you are using FAI 3.1.8 which does not need unionfs. Ah, progress. Don't you just love it? :-) Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Kernel problems with unionfs and Ubuntu gutsy
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-client3.2.4 fai-doc 3.2.4 fai-quickstart3.2.4 fai-server3.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
Re: Kernel problems with unionfs and Ubuntu gutsy
R. F. Grant wrote: 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-client3.2.4 fai-doc 3.2.4 fai-quickstart3.2.4 fai-server3.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... Hello I'm also setting up FAI to install new Ubuntu distributions. Currently I'm working on Hardy Heron. The ubuntu kernels (gutsy, hardy) have problems mounting unionfs over FAI nfsroot. Therefore I use plain Debian Etch kernel on my TFTP server to boot my install clients. I also build my nfsroot from Debian Etch bootstrap. On the install clients I do install ubuntu kernels which work as expected. Regards, Eymen Alyaz
Re: Kernel problems with unionfs and Ubuntu gutsy
On Thu, 21 Feb 2008 15:42:45 +, R. F. Grant [EMAIL PROTECTED] said: Anyway, I finally managed to build a kernel that would boot the new hardware. It would be nice to put the packages containing the kernel and unionfs modules on the web (maybe the FAI web pages), so people can also use it. Do you have normal kernel packages build by make-kpkg? -- regards Thomas
