Re: Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote:
> On Thu, 2014-09-25 at 23:20 +0100, peter green wrote:
> > Karsten Merker wrote:
> > >> Browse online:
> > >> http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/templates-arch
> > >>
> > >> Adding -arm@ and -boot@ for possible comments/insight.
> > >>
> > >
> > > I suppose the reason for MODULES=dep being the default on arm*
> > > might be that some armel systems boot their kernel and initrd
> > > directly from an onboard flash chip with a size of only a few MB,
> > > so an initramfs built with modules=most might be uninstallable on
> > > them due to lack of space.
> > >
> > Which makes sense for armel, many load their boot files from fixed size
> > blocks of flash and flash space is a MAJOR issue (and major thorn in the
> > kernel teams side) and you will generally need a new kernel if you move
> > to a different device anyway.
>
> Another possible reason for using MODULES=dep would be that disk access
> from the boot loader is very slow (this is the case on Google Compute
> Engine for example).
>
> > On the other hand for armhf i'm not sure it makes sense, most armhf
> > systems i'm aware of load their kernels/initrds from filesystems so
> > space is not such and issue and with the new armmp kernels having a
> > modules=most initrd would presumablly allow one to move to different
> > hardware with just swapping out the bootloader.
>
> Assuming that armhf is not constrained by flash partition sizes (we
> certainly don't have any size limit configured for the kernel image yet)
> or very slow I/O, I support using MODULES=most by default.
I agree. I'm not aware of any armhf platforms with size constraints or
cripplingly slow boot time I/O. I think if either of those show up the
answer would be to fix the bootloader to run with caches on, support a
better boot device etc etc.
Unless there are objections I'll make the change in base-installer.
> However, at the moment initramfs-tools won't include PHY drivers even in
> that configuration.
I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042 about
this sort of thing on xgene, and today I updated it because arndale is
affected too.
As I say there I'm planning to send a patch to load an appropriate set
of phy drivers when running with modules=most.
That won't solve modules=dep though. The only solution I can think of
right now for that is to extend the existing hidden_dep handling with a
scheme which maps each module to be loaded to a list of other modules
which should be included (e.g. ahci_platform => { a bunch of phy
drivers }). Hardly the most elegant thing in the world, could perhaps be
improved by looking at the set of currently loaded drivers, but that has
pitfalls too.
Ian.
Reply to: