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.