Re: Pre-bug-raising questions
On Mon, Jan 19, 2009 at 4:57 PM, Ian Campbell <email@example.com> wrote:
> On Mon, 2009-01-19 at 16:43 +0000, Mike Grice wrote:
>> 2009/1/19 Mike Grice <firstname.lastname@example.org>:
>> > On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell <email@example.com> wrote:
>> >> On Mon, 2009-01-19 at 14:12 +0000, Mike Grice wrote:
>> >>> Select a language: English
>> >>> Choose Language: default
>> >>> Detect Network Hardware:
>> >>> "No Ethernet card was detected. If you know the name of the driver
>> >>> │
>> >>> │ needed by your Ethernet card, you can select it from the list."
>> >> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
>> >> entries here and in the module the installer should be able to make the
>> >> connection between one and the other. For example for Xen virtual
>> >> devices we have:
>> >> di32:~# cat /sys/bus/xen/devices/vif-0/modalias
>> >> xen:vif
>> >> di32:~# modinfo xen-netfront
>> >> filename: /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
>> >> alias: xennet
>> >> alias: xen:vif
>> >> license: GPL
>> >> description: Xen virtual network device frontend
>> >> depends:
>> >> vermagic: 2.6.26-1-686-bigmem SMP mod_unload modversions
>> >> 686
>> >> So the xen:vif modalias ties into the alias on the module.
>> > Ok, that's pretty interesting. I suspect that the console support is
>> > compiled into the kernel via the CONFIG_LDOMS kernel option though
>> > (the net and disk are modules). The giveaway for that would be the
>> > very sparse loaded module list:
>> > hostname:~# lsmod
>> > Module Size Used by
>> > ipv6 307168 72
>> > ext3 142672 2
>> > jbd 50856 1 ext3
>> > sunvnet 16132 0
>> > sunvdc 12168 5
>> > Theres some interesting things in dmesg about console shenanigans:
>> > hostname:~# dmesg | grep -E '(cons|tty|prom)'
>> > [ 0.000000] console [earlyprom0] enabled
>> > [ 0.000000] OF stdout device is: /virtual-devices@100/console@1
>> > [22750.854590] console handover: boot [earlyprom0] -> real [tty0]
>> > [22755.397980] f02795dc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
>> > [22755.400034] console [ttyHV0] enabled
>> > The console I'm having problems with is the virtual one where it
>> > simulates being 'at the console'. From the primary LDOM (domain 0 in
>> > xenspeak), you telnet to localhost on a port and it dumps you to that
>> > console.
>> > The weird thing is that this console works completely fine during the
>> > debian-installer (even with colour and tabbing, etc.) but once you
>> > reboot into the new Debian install, the console is effectively
>> > 'read-only' (I see the login: prompt, but no matter what key
>> > combination I press, my typing does not show at the other side).
>> > The output of dmesg and a find in /sys are attached if you think
>> > perusing these will help...
>> Ok, to answer my own question, this console seems to have become a
>> serial console after the reboot. Just on a hunch I edited
>> /etc/inittab (via my ssh connection), uncommented the ttyS0 line (the
>> one you normally use to enable the serial console) and after an 'init
>> q' my virtual console that was open in another window sprang into life
>> with a normal banner.
>> How you'd take care of that in the installer in a nice way, I have no idea...
> For Xen I had to add code to
> packages/finish-install/finish-install.d/90console to make this work.
> It's r54359 in the Debian installer SVN repo
> If your device is hvc0 as well then adding an || to that if statement
> seems reasonable.
Having found that it's the weird behaviour of LDOM changing the device
from one type to another, I think its fair to say its down to the
person doing the installing to make sure this is picked up properly,
it's just inconvenient rather than broken. Although for a non-network
install you will have problems, so yeah, that kind of workaround is a
good idea, thanks.
The main concern I have is the autodetection of the hardware... I
don't know how the installer works enough to see what bit isn't
working there, so I'll have to do some digging :-(