Hey

On Thu, Mar 03, 2011, Matt Sealey wrote:
> Okay I have some problems with the support committed to flash-kernel,
> namely
> * it doesn't differentiate between kernel versions, so uImage and
> uInitrd will overwrite any older uImage and uInitrd version. This is
> unfriendly and it is impossible to tell at a glance (without using
> mkimage to list the details) what version of the kernel it is

 This is a limitation of flash-kernel; it would probably be best to move
 discussions on evolving the design of flash-kernel elsewhere; I took
 some notes of possible flash-kernel improvements at the Emdebian sprint
 last week; see http://wiki.debian.org/FlashKernelRework

 You can call flash-kernel with a kernel version, or none in which case
 /vmlinuz or /boot/vmlinuz gets used (and corresponding initrd.img); in
 any case, the last call wins.

> * if uInitrd doesn't already exist, it will not be created as the
> entire creation part is wrapped in an if [ -f /boot/uInitrd ]. What
> should happen is
> 
> if [ -f /boot/uInitrd ]; then
>    cp /boot/uInitrd /boot/uInitrd.bak
> fi
> 
> # create uInitrd here regardless

 Makes sense; the rest of the code uses mv, but I agree with the comment

 Would you or Marcin be tempted to offer a patch for this?

> Actually, apart from the last one I'm willing to live with what happens
> here, as it makes cleanup of kernels much easier. But, it does beg a
> question, if I dpkg --purge a kernel image, update-initramfs will remove
> the initrd.img-${kver} - why can't flash-kernel remove kernel files?

 There should only be one uImage on your system, and I guess it makes
 sense to keep it even if you remove the last kernel installed on your
 system.  Perhaps you meant the vmlinux-* files?  These are removed by
 dpkg when removing the linux-image-* .debs which ship them.

> Also why can't we ship a boot.script which you can use sed to insert the
> kernel version (cp boot.script /tmp/boot.script; sed -i
> -e's/KVERSION/${kver}/' /tmp/boot.script; mkimage blah -d
> /tmp/boot.script /boot/boot.scr; rm -f /tmp/boot.script), and create
> versioned uInitrd and uImage files?

 That could be a flash-kernel improvement; currently it:
 * doesn't allow having more than one kernel ready to boot
 * doesn't cleanup files it generates in boot

 This feature would be specific to systems booting from SD, which are
 increasingly common.  I would prefer seeing this feature developed in
 upstream (Debian's) flash-kernel before we add it in Ubuntu though.
 The delta is large enough as it is  :-)

On Thu, Mar 03, 2011, Matt Sealey wrote:
> Additional comment: Loic, PLEASE can we put back "efikamx" subarch
> support? It would be a legacy hack but it will mean our current kernels
> work. I don't want to have to build a vendor-specific package and track
> it for the sake of 2 lines. Neither Maverick nor Natty has or will have
> an "mx51" subarch kernel so the fix has basically caused a nightmare AND
> a breakage, for the sake of "doing it right" not "keeping what works,
> working".

 mx51 is the computed subarch of the Linaro mx51 kernel; back then I
 thought it supported efikamx smartbook too, even if minimally.

 As I wrote to you in a direct email, I don't like subarch checks in
 general; I would fancy if we could check the config instead (grep -Fx
 CONFIG_MACH_MX51_EFIKAMX=y /boot/config-$version).

 This check would only be possible if a version is passed to
 flash-kernel, or would be skipped entirely.

 Would that be helpful?

   Cheers,
-- 
Loïc Minier