Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #51289 > unrolled thread

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Vagrant Cascadian <vagrant@debian.org> - 2015-11-12 02:00 +0100
    Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Ian Campbell <ijc@hellion.org.uk> - 2015-11-12 11:00 +0100
      Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Ben Hutchings <ben@decadent.org.uk> - 2016-01-25 16:30 +0100
        Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Ben Hutchings <ben@decadent.org.uk> - 2016-02-04 17:00 +0100
          Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Vagrant Cascadian <vagrant@debian.org> - 2016-02-24 23:40 +0100
            Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Vagrant Cascadian <vagrant@debian.org> - 2016-02-25 00:10 +0100
              Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Rick Thomas <rbthomas@pobox.com> - 2016-03-04 19:40 +0100
                Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs Ben Hutchings <ben@decadent.org.uk> - 2016-04-17 02:30 +0200

#51289 — Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Multipart message — attachments visible in raw view] — view raw

On 2014-09-30, Ben Hutchings wrote:
> On Tue, 2014-09-30 at 08:19 +0100, Ian Campbell wrote:
>> On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote:
>> > However, at the moment initramfs-tools won't include PHY drivers even in
>> > that configuration.
>> 
>> I spent some time last week hunting for a sysfs link between a device
>> and the phys which it is using, without success. Do you have any ideas?
>
> I suspect they're not visible there yet.
>
> I think you could include all PHY drivers (drivers/phy and
> drivers/usb/phy) when MODULES=most, and only the currently loaded
> drivers if MODULES=dep.
>
> USB non-generic PHY drivers don't appear in the device model at all
> (ugh!) so in the MODULES=dep case you may have to bodge it by checking
> for modules with names beginning with "phy-" (check both /sys/module
> and /lib/modules/$(uname -r)/modules.builtin).

Would definitely like to see this, with a recent install on a Wandboard
Dual with a USB2 sata disk for the rootfs. It installed fine with
jessie's debian-installer, but failed on initial boot.

I worked around it by adding to /etc/initramfs-tools/modules:

  ci_hdrc_imx
  phy_mxs_usb

I haven't yet verified if only adding "phy_mxs_usb" instead of both will
work.

Had a similar problem with an Odroid-XU4 install (which isn't yet
supported by debian-installer), and worked around it similarly, although
haven't narrowed down exactly which modules are needed, though I
suspect one or both of:

  phy_exynos_usb2
  phy_exynos5_usbdrd


Something that pulls in all the phy-* modules would likely fix the issue
in a generic way, rather than playing whack-a-mole with various phy
types.


live well,
  vagrant

[toc] | [next] | [standalone]

#51293

On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
> On 2014-09-30, Ben Hutchings wrote:
> > On Tue, 2014-09-30 at 08:19 +0100, Ian Campbell wrote:
> > > On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote:
> > > > However, at the moment initramfs-tools won't include PHY drivers
> > > > even in
> > > > that configuration.
> > > 
> > > I spent some time last week hunting for a sysfs link between a device
> > > and the phys which it is using, without success. Do you have any
> > > ideas?
> > 
> > I suspect they're not visible there yet.
> > 
> > I think you could include all PHY drivers (drivers/phy and
> > drivers/usb/phy) when MODULES=most, and only the currently loaded
> > drivers if MODULES=dep.
> > 
> > USB non-generic PHY drivers don't appear in the device model at all
> > (ugh!) so in the MODULES=dep case you may have to bodge it by checking
> > for modules with names beginning with "phy-" (check both /sys/module
> > and /lib/modules/$(uname -r)/modules.builtin).
> 
> Would definitely like to see this, with a recent install on a Wandboard
> Dual with a USB2 sata disk for the rootfs. It installed fine with
> jessie's debian-installer, but failed on initial boot.
> 
> I worked around it by adding to /etc/initramfs-tools/modules:
> 
>   ci_hdrc_imx
>   phy_mxs_usb
> 
> I haven't yet verified if only adding "phy_mxs_usb" instead of both will
> work.
> 
> Had a similar problem with an Odroid-XU4 install (which isn't yet
> supported by debian-installer), and worked around it similarly, although
> haven't narrowed down exactly which modules are needed, though I
> suspect one or both of:
> 
>   phy_exynos_usb2
>   phy_exynos5_usbdrd
> 
> 
> Something that pulls in all the phy-* modules would likely fix the issue
> in a generic way, rather than playing whack-a-mole with various phy
> types.

I think Ben essentially did this in #762042[0], which ends up adding any
phy-* which are currently loaded to the initramfs. That change appears to
be in v0.119 while Jessie has v0.120 so perhaps something else is going on.

ci-* isn't covered by this logic, so that might be it in the first case.
What is ci-*?

Ian.

[0] 6ba2e937271770576fb88f4e16cb5adb3094517b in intiramfs-tools.git

[toc] | [prev] | [next] | [standalone]

#52424

[Multipart message — attachments visible in raw view] — view raw

On Thu, 12 Nov 2015 09:49:33 +0000 Ian Campbell <ijc@hellion.org.uk> wrote:
> On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
[...]
> > Would definitely like to see this, with a recent install on a Wandboard
> > Dual with a USB2 sata disk for the rootfs. It installed fine with
> > jessie's debian-installer, but failed on initial boot.
> > 
> > I worked around it by adding to /etc/initramfs-tools/modules:
> > 
> >   ci_hdrc_imx
> >   phy_mxs_usb
> > 
> > I haven't yet verified if only adding "phy_mxs_usb" instead of both will
> > work.
> > 
> > Had a similar problem with an Odroid-XU4 install (which isn't yet
> > supported by debian-installer), and worked around it similarly, although
> > haven't narrowed down exactly which modules are needed, though I
> > suspect one or both of:
> > 
> >   phy_exynos_usb2
> >   phy_exynos5_usbdrd
> > 
> > 
> > Something that pulls in all the phy-* modules would likely fix the issue
> > in a generic way, rather than playing whack-a-mole with various phy
> > types.
> 
> I think Ben essentially did this in #762042[0], which ends up adding any
> phy-* which are currently loaded to the initramfs. That change appears to
> be in v0.119 while Jessie has v0.120 so perhaps something else is going on.
> 
> ci-* isn't covered by this logic, so that might be it in the first case.
> What is ci-*?

Thaose are the chipidea USB controller drivers, which should get found
through sysfs.

Please can you clear out /etc/initramfs-tools/modules (temporarily) and
run:

    sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp >mkinitramfs.log 2>&1

Then send the log so we can see how this is going wrong.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.

[toc] | [prev] | [next] | [standalone]

#52575

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-02-03 at 15:43 -0800, Vagrant Cascadian wrote:
> On 2016-01-25, Ben Hutchings wrote:
> > On Thu, 12 Nov 2015 09:49:33 +0000 Ian Campbell <ijc@hellion.org.uk> wrote:
> > > On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
> > [...]
> > > > Would definitely like to see this, with a recent install on a Wandboard
> > > > Dual with a USB2 sata disk for the rootfs. It installed fine with
> > > > jessie's debian-installer, but failed on initial boot.
> > > >  
> > > > I worked around it by adding to /etc/initramfs-tools/modules:
> > > >  
> > > >   ci_hdrc_imx
> > > >   phy_mxs_usb
> > > >  
> > > > I haven't yet verified if only adding "phy_mxs_usb" instead of both will
> > > > work.
> ...
> > > I think Ben essentially did this in #762042[0], which ends up adding any
> > > phy-* which are currently loaded to the initramfs. That change appears to
> > > be in v0.119 while Jessie has v0.120 so perhaps something else is going on.
> > >  
> > > ci-* isn't covered by this logic, so that might be it in the first case.
> > > What is ci-*?
> > 
> > Thaose are the chipidea USB controller drivers, which should get found
> > through sysfs.
> > 
> > Please can you clear out /etc/initramfs-tools/modules (temporarily) and
> > run:
> > 
> >     sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp >mkinitramfs.log 2>&1
> > 
> > Then send the log so we can see how this is going wrong.
> 
> Attached is a log of the above command with /etc/initramfs-tools/modules
> cleared out.

Oh, so the MODULES=most case is bust and we need to list more host
controller drivers (or include all modules under drivers/usb/host/).
How about MODULES=dep; does that work now?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth

[toc] | [prev] | [next] | [standalone]

#53023

[Multipart message — attachments visible in raw view] — view raw

On 2016-02-04, Ben Hutchings wrote:
> On Wed, 2016-02-03 at 15:43 -0800, Vagrant Cascadian wrote:
>> On 2016-01-25, Ben Hutchings wrote:
>> > On Thu, 12 Nov 2015 09:49:33 +0000 Ian Campbell <ijc@hellion.org.uk> wrote:
>> > > On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
>> > > > Would definitely like to see this, with a recent install on a Wandboard
>> > > > Dual with a USB2 sata disk for the rootfs. It installed fine with
>> > > > jessie's debian-installer, but failed on initial boot.
>> > > >  
>> > > > I worked around it by adding to /etc/initramfs-tools/modules:
>> > > >  
>> > > >   ci_hdrc_imx
>> > > >   phy_mxs_usb
>> > > >  
>> > > > I haven't yet verified if only adding "phy_mxs_usb" instead of both will
>> > > > work.
>> ...
>> > > I think Ben essentially did this in #762042[0], which ends up adding any
>> > > phy-* which are currently loaded to the initramfs. That change appears to
>> > > be in v0.119 while Jessie has v0.120 so perhaps something else is going on.
>> > >  
>> > > ci-* isn't covered by this logic, so that might be it in the first case.
>> > > What is ci-*?
>> > 
>> > Thaose are the chipidea USB controller drivers, which should get found
>> > through sysfs.
>> > 
>> > Please can you clear out /etc/initramfs-tools/modules (temporarily) and
>> > run:
>> > 
>> >     sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp >mkinitramfs.log 2>&1
>> > 
>> > Then send the log so we can see how this is going wrong.
>> 
>> Attached is a log of the above command with /etc/initramfs-tools/modules
>> cleared out.
>
> Oh, so the MODULES=most case is bust and we need to list more host
> controller drivers (or include all modules under drivers/usb/host/).
> How about MODULES=dep; does that work now?

MODULES=dep appears to pull in the necessary drivers on a recent stretch
install on a wandboard solo, using initramfs-tools 0.123, but
MODULES=most still requires manually including them in
/etc/initramfs-tools/modules.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#53024

[Multipart message — attachments visible in raw view] — view raw

On 2016-02-24, Vagrant Cascadian wrote:
> On 2016-02-04, Ben Hutchings wrote:
>> Oh, so the MODULES=most case is bust and we need to list more host
>> controller drivers (or include all modules under drivers/usb/host/).
>> How about MODULES=dep; does that work now?
>
> MODULES=dep appears to pull in the necessary drivers on a recent stretch
> install on a wandboard solo, using initramfs-tools 0.123, but
> MODULES=most still requires manually including them in
> /etc/initramfs-tools/modules.

And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard dual
with initramfs-tools 0.120.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#53104

On Wed, 24 Feb 2016 15:06:27 -0800 Vagrant Cascadian <vagrant@debian.org> wrote:
> On 2016-02-24, Vagrant Cascadian wrote:
> > On 2016-02-04, Ben Hutchings wrote:
> >> Oh, so the MODULES=most case is bust and we need to list more host
> >> controller drivers (or include all modules under drivers/usb/host/).
> >> How about MODULES=dep; does that work now?
> >
> > MODULES=dep appears to pull in the necessary drivers on a recent stretch
> > install on a wandboard solo, using initramfs-tools 0.123, but
> > MODULES=most still requires manually including them in
> > /etc/initramfs-tools/modules.
> 
> And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard dual
> with initramfs-tools 0.120.
> 
> 
> live well,
>   vagrant

would it make sense to ensure that MODULES=most is always a superset of MODULES=dep?  Could this be done by running MODULES=dep first, then running MODULES=most and delivering the union of the two sets?

Thanks!
Rick

[toc] | [prev] | [next] | [standalone]

#53642

[Multipart message — attachments visible in raw view] — view raw

On Thu, 3 Mar 2016 16:49:21 -0800 Rick Thomas <rbthomas@pobox.com> wrote:
> On Wed, 24 Feb 2016 15:06:27 -0800 Vagrant Cascadian <vagrant@debian.org> wrote:
> > On 2016-02-24, Vagrant Cascadian wrote:
> > > On 2016-02-04, Ben Hutchings wrote:
> > >> Oh, so the MODULES=most case is bust and we need to list more host
> > >> controller drivers (or include all modules under drivers/usb/host/).
> > >> How about MODULES=dep; does that work now?
> > >
> > > MODULES=dep appears to pull in the necessary drivers on a recent stretch
> > > install on a wandboard solo, using initramfs-tools 0.123, but
> > > MODULES=most still requires manually including them in
> > > /etc/initramfs-tools/modules.
> > 
> > And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard dual
> > with initramfs-tools 0.120.
> > 
> > 
> > live well,
> >   vagrant
> 
> would it make sense to ensure that MODULES=most is always a superset
of MODULES=dep?  Could this be done by running MODULES=dep first, then
running MODULES=most and delivering the union of the two sets?

We could do, but I think it's a useful feature that MODULES=most is
hardware-independent and I don't want to change that.

I've gradually been moving the behaviour of MODULES=most toward
including entire classes of drivers and I'd prefer to handle this the
same way.

Ben.
 
-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web