Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card
Hey
Sorry for being late to the party, thanks for waiting for me! :-)
On Sat, Nov 02, 2013, Martin Michlmayr wrote:
> > On most platforms flash-kernel generally prefers to mount the device
> > dynamically, for those sorts of reasons. At least that's how I remember
> > one of the f-k folks explaining it to me.
>
> No, that's not very common at all (although I see there are two other
> devices now that do this). The most common way is either to write
> directly to flash (for machines that boot from flash), or to put the
> files under /boot, under the assumption that /boot is where the device
> boots from (and d-i has checks to make sure this is the case, although
> d-i cannot check for everything).
So let's tackle cases one by one.
First something to keep in mind is that for many platforms there is a
factory installed U-Boot and a Debian one is available; at the moment,
the assumption of which U-Boots are supported are not clearly
documented, except on the (nice) web pages from Martin or other Google
juice.
Concerning devices with flash storage (assuming there is an initrd and
perhaps even DTB flash partition and that the Debian kernel and initrd
will git in the stock partitions...), it's best to just write the
files there, no need to write an interim file to /boot that is going to
be ignored anyway. So flash-kernel should just generate the kernel
(potentially with machine-id prepended, dtb appended, u-boot wrapping
etc.) and initrd in /tmp, write them to flash, and remove the tmp files.
Concerning devices where U-Boot grabs boot files from a filesystem,
there are many variations in different platforms. Usually, the factory
default is to read files from a hardcoded U-Boot device name and
filesystem type, e.g. "fatload mmc 0 uImage". In some slightly more
clever U-Boot configs, there is some kind of scanning (either for a boot
script or for a kernel image) in the form of "iterate over all MMCs,
then iterate over all partitions, then iterate over all filesystems and
try to load file xyz".
There are three issues with these setups; first, this is all very
fragile, with a lot of variation and doesn't allow fancy things like
reading kernel/initrd from RAID, LVM, LUKS etc. or filesystems not
supported by U-Boot.
Second, some U-Boot hardcode the filesystem type or only support
dumb filesystems such as FAT or ext2. This is problematic because
keeping ext2 mounted might result in unrecoverable corruption if the
device crashes with unsynced changes (since U-Boot doesn't know how to
deal with a filesystem that needs fsck-ing) and because sometimes we
have symlinks in /boot.
Third, the boot location is often space constrained and don't allow
piling up old kernels. e.g. a 40MB MMC partition but you've piled up 5
kernels.
With this in mind, I initially opted to list actual boot devices in the
flash-kernel database (Boot-Device: /dev/sda1) using the expected
factory-supported / Debian-supported/recommended U-Boot boot device.
This would be mounted temporarily, only relevant files would be
updated there, and then it would be unmounted. This avoided the
filesystem corruption issue, avoided the symlink issue and avoided the
limited space issue nicely.
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) and to also
offer a mode where this would be computed based on /boot.
> If people think it's too late to change the behaviour now, I think it
> would be good to at least add a simple message like
> Creating boot files on /dev/sdaX
> to make it cleaer what's going on.
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?
Cheers,
--
Loïc Minier
Reply to: