Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card
On Fri, Nov 08, 2013, Stanley Pilton wrote:
> For our dreamplugs, we want to have an identical bootloader
> configuration on each device, and have the behaviour of the system
> from the OS up defined by the content of the removable SD card, not
> the internal card. In other words, we would like to be able to change
> the SD cards over between two of the devices, and have the whole
> system, including the kernel and initrd, come across.
>
> Having the kernel on internal storage and the rest of the system on
> external storage does not allow us to do this.
That's fine; there are other similar cases where the most common default
is SD/MMC, such as Beagle/Panda, despite some revisions having NAND.
When I referred to flash being used for the kernel/initrd, it wasn't
anything mandatory, just something commonly witnessed (I guess it is
often why NAND was included in the device in the first place!).
> > 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?
>
> We are quite happy with constraints such as "it must be an ext2
> filesystem directly on a partition of the card", as long as this is
> clearly documented.
To be clear, the ext2 requirement typically comes down from U-Boot;
ideally, we'd instead allow users to install their kernel / initrd
anywhere and have a bootloader as clever as GRUB find them by scanning
all block devices and figuring out complex RAID/LVM/filesystem setups,
but we don't have this luxury on ARM. So the device manufacturer
usually picks a bootloader (often U-Boot) and some supported filesystem
(often vfat or ext2) and loads from that, then Debian tools like
flash-kernel try to cope with whatever setup was chosen.
> I think a key point is that the installer and any other software
> managing the boot files should know where to write based on where
> /boot is. In other words, I wouldn't expect the user to have to tell
> the OS twice where the boot partition is - this is already configured
> by the /boot mountpoint, isn't it?
Well, you'd think this is what /boot is for, but if you add the
constraint that the bootloader needs to be able to read /boot and that
the bootloader only speaks vfat / ext2, you might face painful
situations. For instance, you need to keep /boot mounted all the time
as to allow upgrades of the linux-image-* packages which ship files
under /boot, but if there's an unclean shutdown, your filesystem is
unclean and your device might not come up.
Using /boot to store boot related file, but then having flash-kernel
mount some "firmware area", copy just the right boot files into it, then
unmount said area has advantages.
> Working out what /boot corresponds to in bootloader terms, and thus
> configuring the bootloader correctly, then becomes the problem. But I
> think the problem should be stated this way round. In simple cases it
> should be easy. If it can't be deduced, this error needs to propogate
> up to the user.
Sure, we can put the burden on the bootloader, but we typically dont
have much control over it and it's often limited.
I'm all for using a bootloader as capable as GRUB on ARM, but I don't
think this is possible yet?
--
Loïc Minier
Reply to: