Comment 27 for bug 671027

 Just a note: I think this is getting off topic for this bug; we should
 only exchange on resolving this particular bug in a relatively simple
 way; flash-kernel design discussions should be held elsewhere IMO.

On Thu, Mar 03, 2011, Matt Sealey wrote:
> I was under the impression that flash-kernel, as a subordinate of
> update-initramfs or at the very least kernel postinst.d hook, is ALWAYS
> called with a version (in fact, standards state that it passes the
> kernel version as $1 AND $2 for some funky reason). There's very very
> little reason to call it with no version, and even if it was, shouldn't
> it pull "uname -r"? Otherwise it would have absolutely no idea which
> kernel to work on, and so far as I have seen after about a gazillion
> kernel installs, removes and replacements, the "vmlinux" and
> "initrd.img" symlinks either in /boot or / are some magic which doesn't
> always happen.
>
> However, vmlinux-$kvers and initrd.img-$kvers are always going to be
> there. Imagine for a second that flash-kernel is a bootloader helper
> tool like grub-install and it needs to know which kernels to pick out
> and handle. It's not useful to leave a kernel file in there
> "unversioned".

 It isn't called with a version from d-i for instance; also, some
 documentations tell people to just run "flash-kernel" unversioned. I'm
 not arguing whether it's a good or bad thing, it's just a currently
 supported interface.

> As for the kernel "mx51" subarch, mx5 is a possibility too (although an
> upstream seems to have kicked out MX51 and MX53 both working at the same
> time in the same kernel) - but so are many other combinationsm possibly
> Cortex-A9 support for the MX6 on top. As always the subarch is specific
> to the distribution and if it's not upstream, most certainly vendor-
> specific. Ours is "efikamx" and we used to have "efikasb" to
> differentiate between the two different compiles (there were horrible
> hacks which made them not build together, which are now gone). As it
> stands we can stick to "efikamx" right now. Probably the best subarch to
> go for would be "imx", which is almost too generic.. but it would work
> considering the restrictions of the distribution (armv7-a, Thumb2..).
> The suffix and therefore subarch is a distribution thing not a kernel
> mainline thing.

 You're making two points above:
 * people might be running any kernel name (which is the point I was
   making myself against subarch in general, and the reason I propose
   testing the contents of the config file instead)
 * that the current subarch concept is distribution specific; I agree
   with this point as well, but your -efikamx kernel isn't in Ubuntu, so
   by that logic, the -efikamx string should be tested in a flash-kernel
   version which lives in the same repository as your -efikamx kernel; I
   would personally prefer if you hadn't your own flash-kernel fork,
   which is why I'm proposing to test the config instead because that
   seems to be always correct, whatever the kernel extension

> Parsing kernel configs doesn't work to identify the running board. After
> all, a config file can have many boards in it. How do you parse the
> config file and THEN determine if you're running on the right system?
> You may as well skip looking in the config. What needs to be checked,
> without being too clever for it's own good is
>
> * /proc/cpuinfo Machine: line
> * suffix to the kernel version (-efikamx, -omap4, -igloo)

 I don't understand your argument; flash-kernel is currently looking at
 the /proc/cpuinfo Hardware: line and then expects a hardcoded kernel
 suffix depending on that. I think that's wrong, as you proved earlier
 in your comment: multiple kernels might work, and we can't tell just
 from the filename.
   You ask how I would parse the config, I would just grep for the
 relevent MACH config entry for the kernel we're about to install, as I
 mentioned in my earlier comment.

> Which define the subarch precisely, and the machine precisely, unless
> the vendor changes the name of the board halfway through. Flash-kernel
> already does exactly as needed here.

 I'm arguing that this approach isn't scalable, and is in fact wrong.
 :-)

> I have a patch right here but I need to test it. It puts back the
> efikamx subarch and makes our kernels versioned.

 Will flash-kernel work with -mx5, -mx51 or -imx51 kernels which might
 support the board? I'd prefer if that was the case

> I'm still a little
> confused about the deleting of kernel files though. update-initramfs
> called from postrm.d removes the initrd.img-$kvers itself - but how does
> it know it is a removal task? It never gets passed more than two
> identical kernel versions (the one it is being told to do something
> with). If update-initramfs can do it, flash-kernel can clean up
> uImage-$kvers and uInitrd-$kvers (and any backups of those versions) the
> same way. Is it an environment variable being looked for? I couldn't
> read through the code without getting eye strain but I will check into
> it.

 I'm really not keen to add support for uImage-$version/uInitrd-$version
 in Ubuntu's flash-kernel.

> I really think flash-kernel should not be a update-initramfs-called
> script, but a seperate postinst/postrm hook of it's own. It should run
> after update-initramfs (if needed) and before update-notifier is called