|Summary:||Installation mediums stuck at "(none) login:"|
|Product:||Gentoo Release Media||Reporter:||Tom Wijsman (TomWij) (RETIRED) <tomwij>|
|Component:||InstallCD||Assignee:||Gentoo Release Team <release>|
|Severity:||normal||CC:||bkohler, codier, dwfreed, gentoo, john_r_graham|
|Package list:||Runtime testing required:||---|
Description Tom Wijsman (TomWij) (RETIRED) 2013-06-01 16:51:24 UTC
According to Watchman DONAHUE at http://forums.gentoo.org/viewtopic.php?p=7320504#7320504 there have been at least three reports that installation mediums are stuck at "(none) login:", could someone investigate this?
Comment 1 Ben Kohler 2013-06-19 20:59:28 UTC
I've finally found a machine where I can reproduce this. Here's what I've found so far-- I believe the problem is triggered only when booting from a usb-2.0 storage device, and only on a subset of those setups. The ehci-pci module is currently known to be missing (see bug #470878), but some kind of fallback is happening and it's still finding the usb storage device, maybe using UHCI. On most of of these usb-2.0 setups, it fails right when it's time to mount rootfs from usb-storage, but SOME setups still find the device. On the setups where the usb storage device IS found, there are some subsequent IO errors (which I haven't yet captured), and apparently the inittab rewrite fails, and there is no autologin. I'm still looking into the finer details of the matter, but I do believe that this just another failure mode of the same missing ehci-pci issue, which will be fixed in a new release any time now, since genkernel-184.108.40.206 with the fixes has hit stable.
Comment 2 Ben Kohler 2013-06-19 22:13:38 UTC
This autologin failure happens on Dell Optiplex 330 and 380 at least, and check out the lspci output, their particular chipset (ICH7) lists both UCHI *and* EHCI controllers for the same ports: 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI]) 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01) (prog-if 00 [UHCI]) 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Meanwhile on an Optiplex 3010 (newer chipset) it lists only EHCI, and liveusb boot fails altogether, on the root mount: 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) This isn't a dell-specific issue, these are just the machines I have available to test on. It's looking like the fallback to UHCI is to blame.
Comment 3 Ben Kohler 2013-06-19 22:54:05 UTC
What's going on here is that the initramfs is loading up uhci-hcd and that is enough to make the usb storage device work, but then later when udev starts up and autoloads ehci-pci, all usb devices drop out (I see my usb keyboard and mouse LED's die at this moment also) and IO errors fill the screen and boot basically stops (BUT still ends up at a root login). To work around this, add ehci-pci.blacklist=yes to your kernel parameters (ie boot with "gentoo ehci-pci.blacklist=yes". Your devices will be stuck @ usb-1.1 speeds, but it should now boot.
Comment 4 Ben Kohler 2013-11-18 21:38:44 UTC
Fixed quite some time ago, forgot this was still open.