[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#541831: installation-reports: Sunfire T2000 success (one minor issue)

On Monday 17 August 2009, Stephen Gran wrote:
> > It sounds like the "rsc console" is something different, which could
> > explain what you saw. Maybe we need special handling for this case.
> The rsc is much like an iLo or alom.  It's just another management
> interface that offers a 'console' interface to manage the OS.  I did
> the install using this interface, obtained by running 'break -c'.

OK. So the problem is that there is no direct link between the rsc and the 
(serial) console to be used for the installed system.

> > Questions:
> > - What were the contents of /etc/inittab after the installation? Were
> >   the entries for tty[1-6] commented out or not?
> [contents of /etc/inittab]

So regular consoles were enabled. That's expected. I mainly asked to 

> #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
> #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
> I had to uncomment T0 to get a console with 'console -f' from the rsc.

So the rsc is somehow linked to ttyS0.

> ~ # console-type
> serial

This is at least one clue: D-I *does* detect it's a serial connection.

> ~ # readlink /proc/self/fd/0
> /dev/console

That's a logical value if it isn't /dev/ttyS0.

> > - If the first is not "serial" and/or the last is not /dev/ttyS0,
> > then how could the need to set up serial console be detected?
> That's a very good question.  Interestingly, I see this in dmesg:
> [   32.032662] console handover: boot [earlyprom0] -> real [tty0]
> So at least at that point, the kernel thinks it _is_ tty0.

That's fairly normal. In the past we've also seen on sparc:
[    0.000000] console [earlyprom0] enabled
[   53.918290] Console: colour dummy device 80x25
[   53.971361] console handover: boot [earlyprom0] -> real [tty0]
[   59.676537] Console: switching to mono PROM 80x34
[   64.238061] Console: ttyS0 (SAB82532)
[   64.308951] console [ttyS0] enabled

Is there anything after that first message in your case? The full boot log 
would be useful to have for this issue.

> Unfortunately, I don't know enough about whether there is a difference
> between what you attach to with 'console -f' in the rsc and what you
> attach to with 'break -c'.  I naively think that they should be the
> same thing, but it is possible that they are not.

/me is completely lost here.

> > - Does the installer work correctly and does a listener for serial
> > console get set up for the installed system if you boot D-I with
> > console=ttyS0?
> No:
> steal-ctty: No such file or directory
> steal-ctty: No such file or directory
> steal-ctty: No such file or directory
> Over and over.

That might be a bug in itself that's worth fixing. The source for 
steal-ctty is at [1]. It is called by [2], which does the actual 
detection. The loop is probably because init keeps failing and resets.

Can you find out what /var/run/console-device contains at that point?
I'd expect /dev/ttyS0, but it would be good to know for sure.
You can probably find out by booting with BOOT_DEBUG=3 and then in
/sbin/reopen-console add a 'set -x' plus near the end a 'sleep 30' so you 
have time to read the output.

> So, this doesn't look like a problem the installer can
> fix.  It's just odd that the OS doesn't see the serial console on the
> same device as the installer does:
> sgran@zee:~$ readlink /proc/self/fd/0
> /dev/ttyS0
> Well, I'm a bit mystified about how this could be fixed, so I don't
> mind if you want to close it as unresolvable or punt it over to the
> sparc porters to see if they can shed any light on it.

We have solved similar problems in that past. The only thing that's needed 
is *some* way of identifying this case. Possibly there's something 
in /proc from openprom? We could then do something similar as was done 
for powerpc (see the code after "# Set up virtualized..." in [3]).

The final option would be to add a dialog that's displayed if we are 
uncertain and that just asks what to use. Might be useful for other cases 

Main question is if you're willing and able to do a bit more digging :-)



Reply to: