On Mon, Feb 03, 2014 at 02:44:43PM +0100, Hannes Reinecke 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.
You are right. This change is incomplete regarding support for the 3270 terminals. > 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 So this requires yet another entry to the systemd rules file to tag 3270 terminal devices. > - 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'. >From the source code this simply states the name of the console device. The console device is not say *anything* about a potential associated terminal device. Console names (console= kernel parameter) are just identifiers. > > 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? Perhaps it's time for a new sysfs attribute to display the associated terminal device (if any). > > From what I've seen most driver work by virtue of the happy accident > that the console index equals the tty index. This is just naming... you can also develop a console without any terminal device involved. > 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? That's probably a good option but might break existing applications that rely on what is in "active". Alternatively add a new sysfs attribute to display console's associated terminal devices. ... or don't look at the console at all and start getty's on those terminal devices that are available. > Or add a workaround to systemd? Kind regards, Hendrik _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel