Not being able to remove kernels generated is a flaw in the fundamental
way flash-kernel is written. We discussed this. It needs to "act" like
update-initramfs but it doesn't. Adding more and more hacks to work
around it is just that - more and more hacks.

There is one reason and one reason only here that we do it this way and
that is because having several kernel versions around is far more useful
than it is not. The only reliable and fast way to boot a system and
check that the images are correct, and correctly work around the absense
of a ramdisk (which is entirely possible in development) is that 400
byte script (let's imagine this is 20 lines of hand-typed commands on a
U-Boot shell to reproduce, which is cruel and unusual to inflict on
developers).

To fix it by "not allowing more than one bootable kernel" is a hack to
work around a missing, sorely needed feature implementation.

The reason I want this in there is because right now, we run Ubuntu. We
do not run Debian. We need Ubuntu to work. We do not want to wait around
while Canonical, Linaro or whatever gets their act together and decides
to perform an ineffectual, lackadaisical rewrite which solves absolutely
no problems whatsoever. We have had no problems in the 2 years of sales
of people running out of disk space in /boot because of "leftover
kernels". Right now, Ubuntu does not even SHIP an Efika kernel, and the
code path can never be run on any board you really care about, so I
don't see what the argument is.

We want this in because it means maintaining Ubuntu support for our
board gets much easier, and we can support customers better, and then we
can get on with the needful things which is what you are asking us to
wait for. This is a workload issue.

To answer your sed question, it is easily answered if you understand
what sed does. -i means "in place" and takes an argument to rename the
file as a backup before it edits the file in place. I would think it is
obvious what it is trying to do, what happens is basically sed takes the
$tmp.boot.script file and replaces all instances of %KERNELVERSION% in
it, in place. The original file, before this modification, is backed up
to $tmp.boot.script.bak by sed. The second call replaces all instances
of %ROOTPARTITION%, in place on the same file. It will overwrite the
previous backup, however on failure you only need to see the last backup
made to see if it did not make any of the pertinent variable changes
when debugging.

The next lines take $tmp.boot.script (which has, by now, had two
modifications made to it, and one backup is left) and make the boot.scr.
These are the important ones.

It then cleans up the files including that leftover backup (you might
want to remove that line if you want to debug it).

eval is required because without that (i.e. just writing it out as sed
-i..) the shell will not perform variable substitution inside single
quotes, which are the usual way of specifying sed arguments. sed will be
running what is written out verbatim. We obviously want to replace the
%VARIABLES% with $variables, hence the eval.

Without eval it would run

sed -i'.bak' -e's,%KERNELVERSION%,$kvers,g' $tmp.boot.script

With eval it will run

sed -i'.bak' -e's,%KERNELVERSION%,2.6.31.14.20-efikamx,g'
$tmp.boot.script

The comma seperators are so that sed does not freak out over $rootfs
being /dev/sda2 (because a forward slash is a seperator).

I maintain that this patch goes in and Genesi will deal with the fallout
of "omg too many uInitrd files in my /boot directory!" until flash-
kernel is rewritten to acceptably solve the many problems it has
architecturally. It will not break any of your SUPPORTED boards, but it
will reduce our maintenance tasks here.

I am rewriting it (flash-kernel as a concept) now, so that won't be too
long. I am bored of waiting for Canonical, Linaro and Debian developers
to fix this.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/671027

Title:
  Add Efika MX Smartbook/Smarttop support

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to