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.
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 wiki.debian. org/FlashKernel Rework
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://
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 ${kver} /' /tmp/boot.script; mkimage blah -d
> kernel version (cp boot.script /tmp/boot.script; sed -i
> -e's/KVERSION/
> /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 MACH_MX51_ EFIKAMX= y /boot/config- $version) .
general; I would fancy if we could check the config instead (grep -Fx
CONFIG_
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