[systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles

[Kay Sievers]

On Mon, Feb 3, 2014 at 2:44 PM, Hannes Reinecke <hare at suse.de> wrote:
> On 01/31/2014 05:08 PM, Hendrik Brueckner wrote:
>> Ensure to start getty programs on all essential system consoles on Linux on
>> System z.  Add these essential devices to the list of virtualization_consoles
>> to always generate getty configurations.
>>
>> For the sake of completion, the list of essential consoles is:
>>
>>   /dev/sclp_line0 - Operating system messages applet (LPAR)
>>   /dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
>>   /dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
>>   /dev/hvc0  - Already handled by systemd (IUCV HVC terminal on z/VM)
>>
>> Depending on the environment, z/VM or LPAR, only a subset of these terminals
>> are available.
>>
>> See also RH BZ 860158[1] "Cannot login via Operating System Console into RHEL7
>> instance installed on a LPAR".  This bugzilla actually blocks the installation
>> of Linux on System z instances in LPAR mode.
>>
> Hehe.
>
> Nice try, but sadly incomplete.
>
> When switching to a real 3270 console (try 'conmode=3270' on the
> kernel command line) systemd isn't able to open a console, either.
>
> Which opens up a can of worms:
>
> - The S/390 3270 tty device is using a device node
>   /dev/3270/ttyX _and_ an offset '1' to the minor node.
>   So the first tty here is in fact /dev/3270/tty1
> - systemd is using the 'active' sysfs attribute in
>   /sys/class/tty/console to figure out the active
>   console; for the 3270 console this contains the string
>   'tty32700'.
>   Which of course doesn't exist and confuses systemd
>   getty-generator.
>
> The reason for the slightly weird string in 'active' is the way it's
> generated (check drivers/tty/tty_io.c:show_cons_active()):
>         count += sprintf(buf + count, "%s%d%c",
>                          cs[i]->name, cs[i]->index, i ? ' ':'\n');
>
> where 'cs' is the _console_ structure, not the tty structure.
> So we're getting the _console_ name plus the _console_ index here.
> And the console name for the 3270 console is 'tty3270', with the
> index '0'.
>
> Which raises the question: what exactly should be 'active' contain?
> The console name (which doesn't have any equivalent in sysfs), or
> the tty name (which has)?
>
> And, more importantly, how is one supposed to _find_ the
> corresponding sysfs entry for the current 'active' attribute?
>
> From what I've seen most driver work by virtue of the happy accident
> that the console index equals the tty index.
> But that's not a requirement anywhere in the console code.
> Quite the contrary; tty drivers have the 'first_minor' entry
> to explicit request an offset other than '0'.
>
> (And the console driver has an explict '->device' callback
> which allows the tty driver to return the correct index.
> Not that it's used here; would've been too easy).
>
> So how to fix this?
> Update the driver to adhere to the (broken) current behaviour?
> Or modify 'active' to return the corrent tty name?

Sounds fine, if that does not break anything. Systemd should only care
about the matching name on the kernel cmdline and the VTs /dev/ttyX.

> Or add a workaround to systemd?

Any fancier logic would need to go into a separate generator..
Generators can do anything they like, and extend the logic the same
way the default systemd logic is shipped.

Kay