LinuxMCE Forums
General => Developers => Topic started by: PeteK on February 13, 2009, 07:30:02 pm
-
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
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)?
-
PeteK,
could you check if
ramdisk_size=<sizeoframdisk>is the relevant parameter
-
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
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?
-
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
-
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