Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card

[Ian Campbell <ijc@hellion.org.uk>]

On Thu, 2013-11-07 at 17:43 +0100, Loïc Minier wrote:
>     Hey
> 
> Sorry for being late to the party, thanks for waiting for me!  :-)

Sorry for being even later...

>   The long-term plan was to allow overriding the Boot-Device: by the
> end-user (and Ian's patches allow this, albeit I'm afraid they bind us
> to keep the database format backwards-compatible forever)

Yes, I hadn't considered this aspect, sorry.

In principal there is nothing to say that /etc/f-k/db has to have the
same syntax as /usr/lib/f-k/db, but that is splitting hairs a bit
because it does require us to keep the existing parser around or add
other compat code, which is certainly a burden.

We could invent a separate syntax for /etc/f-k/db but that adds
basically the same burdens I think, although perhaps it could be more
restrictive and therefore less of a burden. Is it worth it though?

Is an f-k rewrite or db schema change really on the cards? It seems to
have reached the point of maturity with only little incremental bits
required.

Grub on uboot is now looking like a reasonable proposition, at least for
armhf devices, and should probably be what we move towards. I'm not sure
how/if f-k fits into that model. To some extent the problems solved by
f-k are the same ones as would need to be solved to get grub arm-uboot
loaded. I'm currently undecided on whether this means extending f-k to
know about loading /boot/grub/arm-uboot/core.img (which is already a
uImage formatted thing) as a kernel or teaching grub-install (or some
other grub-tool) platform specific stuff in the manner of flash-kernel.

> Improved log was a good idea; I've just added one now (1e53a60); maybe
> we can work on improved use cases; perhaps we want some
> /etc/flash-kernel/boot-device override file that could be an UUID=, a
> LABEL= or a /dev pathname (much like fstab) that would be created by
> users or by flash-kernel-installer?
> 
> Which devices would this be particularly useful on right now and what
> formats do we want to support first and foremost?  How do we detect the
> device U-Boot will look after?

The mapping from Linux device (or UUID, or LABEL) to the u-boot name
(scsi X:Y, mmc A:B etc) is the big issue with u-boot AFAICT. There's
just no standard scheme.

Once you get into handling separate boot vs boot on / it gets even
nastier -- since the path to the kernel can have /boot on it or not.

This is particularly problematic on systems where there is no dedicated
flash for the kernel so you want to boot out of a regular partition,
e.g. systems where the normal preference would be write a /boot/boot.scr
to load the kernel (or grub). I think writing the correct thing
automatically while allowing for the user's partitioning preferences is
going to turns out to be pretty tricky, if not close to impossible :-(.

There does seem to my eye to be a trend towards more "hackable" devices
(i.e. ones with a serial console), which turns this into at worst a
documentation problem. And on the ARM server side I hope/expect that the
majority will be using EFI (which has standard interfaces) and that
those which do use uboot will have a serial console (again, at worst a
docs problem).

Ian.