Author Topic: 0810 Upgraded 2.6.27-11 initrd.img not added to diskless FileSystem  (Read 4107 times)

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Devs--

I'm not 100% certain, but the target for 0810 seems to be to allow LMCE to be integrated into the standard aptitude-based package management system (unlike previous versions of pluto/LMCE).  If this is the case, I've noticed a potential issue.  Though the normal software upgrade process, a new kernel (version 2.6.27-11) was installed on the core.  This kernel appears to be too big to tftp to the MDs.  I'm not sure what the config is of the kernels automatically upgraded through aptitude, but it looks like this one has debugging info enabled.

According to http://wiki.linuxmce.org/index.php/Upgrading_the_Kernel

Quote
Your initrd-img file should be about 10MB. If it is around the 40MB mark you compiled your kernel with debugging support. The tftp server will refuse to transfer files this large. As a result, all MDs will fail to boot. If you absolutely must use a debugging kernel then there are options you can pass to tftp to make it ignore this limit.

I haven't been able to find a flag to pass to tftpd yet to disable this.

This brings to mind another question.  If upgrading the kernel on the core is allowed, what is the expectation for the MDs?  Should their file systems be rebuilt (with new kernel, headers, etc)?



« Last Edit: February 14, 2009, 08:05:20 am by PeteK »

Marie.O

  • Administrator
  • LinuxMCE God
  • *****
  • Posts: 3675
  • Wastes Life On LinuxMCE Since 2007
    • View Profile
    • My Home
Re: 0810 Upgraded 2.6.27-11 initrd.img too big for tftp to core?
« Reply #1 on: February 13, 2009, 10:44:56 pm »
PeteK,

could you check if
Code: [Select]
ramdisk_size=<sizeoframdisk>is the relevant parameter




PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: 0810 Upgraded 2.6.27-11 kernel cannot boot MD
« Reply #2 on: February 14, 2009, 07:37:40 am »
Posde--

I was a little hasty yesterday in identifying this as a size issue.   
Following the steps in the wiki, I ran /usr/pluto/bin/Diskless_BuildDefaultImage.sh which looks to correctly set up the /tftpboot/default directory correctly, as the MD boots initially.

I think the problem occurs when the file system is generated using the current 0810 method of changing architecture and selecting 'Rebuild Image'
In /tftboot/<device num>  initrd.img and vmlinuz are correctly set up as symlinks to /usr/pluto/diskless/<device num>/boot

and here are the contents of /usr/pluto/diskless/<device num>/boot

Code: [Select]
linuxmce@dcerouter:/usr/pluto/diskless/75/boot$ ls -l
total 22964
-rw-r--r-- 1 root root  507665 2008-11-04 13:00 abi-2.6.27-7-generic
-rw-r--r-- 1 root root   91364 2008-11-04 13:00 config-2.6.27-7-generic
lrwxrwxrwx 1 root root      56 2009-02-13 22:03 initrd.img -> /usr/pluto/diskless/75/boot/initrd.img-2.6.27-11-generic
-rw-r--r-- 1 root root 8514033 2009-02-08 14:17 initrd.img-2.6.27-7-generic
-rw-r--r-- 1 root root 7785478 2009-01-26 16:35 initrd.img-2.6.27-9-generic
-rw-r--r-- 1 root root 1029585 2008-11-04 13:00 System.map-2.6.27-7-generic
-rw-r--r-- 1 root root 1029585 2009-01-26 16:34 System.map-2.6.27-9-generic
-rw-r--r-- 1 root root    1073 2008-11-04 13:02 vmcoreinfo-2.6.27-7-generic
lrwxrwxrwx 1 root root      53 2009-02-13 22:03 vmlinuz -> /usr/pluto/diskless/75/boot/vmlinuz-2.6.27-11-generic
-rw-r--r-- 1 root root 2244464 2008-11-04 13:00 vmlinuz-2.6.27-7-generic
-rw-r--r-- 1 root root 2244304 2009-01-26 16:34 vmlinuz-2.6.27-9-generic


Note that vmlinux and initrd.img point to what should be the 'correct' files (based on the core's running kernel version).  However, those files aren't installed in the diskless image's file system.  Looking at Diskless_InstallKernel, it looks like it tries to point to the correct files based on 'uaname -r.' However, Diskless_CreateFS.sh, which is run right before Diskless_InstallKernel, unpacks the "/usr/pluto/install/PlutoMD-$Moon_Architecture.tar.bz2" archive to create the file system, which doesn't contain the new kernel.

I guess a solution to this would be for Diskless_InstallKernel.sh to copy the 'correct' kernel (that being the result of 'uname -r') into the diskless MD directory before creating the symbolic link.  However, I'm not sure how to handle kernel moduels and mixed architecture environments with this solution.

What do you think?
« Last Edit: February 14, 2009, 09:06:42 am by PeteK »

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: 0810 Upgraded 2.6.27-11 initrd.img not added to diskless FileSystem
« Reply #3 on: February 14, 2009, 09:05:07 am »
To follow up, looking at /usr/pluto/install/PlutoMD-i386.tar.bz2, it has kernel files and modules for 2.6.27-7 and 2.6.27-9, but kernel headers for 2.6.27-11.  Is this an oversight in building the tarball?

In any case, I think my original question about how to handle MD image creation in light of updatable kernels is still a valid one.

Thanks for reading,
-PeteK

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: 0810 Upgraded 2.6.27-11 initrd.img not added to diskless FileSystem
« Reply #4 on: February 16, 2009, 06:18:41 pm »
So to work around this issue, should I recompile the modules in the MD for the new kernel?  The other option is to add the kernel headers for one of the older kernels (-7 or -9) and copy one of those kernels over.  I need the headers to properly compile the nvidia driver package.

Thanks!
-Pete