Bug 774126

I don't see the issue with latest 12.2.

what is your cmdline exactly ?

BOOT_IMAGE=/boot/vmlinuz-3.4.4-1.1-desktop root=UUID=019072c5-31df-414a-be30-b2f947436879 eth0=dhcp console=tty0 console=ttyS0,115200 resume=/dev/disk/by-id/ata-MB0500EAMZD_9WJ1R3LX-part5 splash=silent quiet showopts

no issue on my test VM.

could you boot with systemd.log_level=debug systemd.log_target=kmsg and when it crashes, login through ssh (or another tty, if you can) and get dmesg output  and attach it to this bug report ?

Huh. It seems to only have happened for the boot immediately following installation. It works fine now.

Oops. Or not. Enabling debugging seems to have affected the behavior. I'll try once more.

Created attachment 500916 [details]
dmesg.txt

Ok. I misinterpreted.

The key thing is that a getty is presented *before* the rest of the jobs have been started. If I try to log in prior to the boot process finishing, getty crashes or otherwise exits early. If I wait until the remaining jobs complete, the login proceeds normally.

It may be a factor that I have NIS enabled on the system, even though I don't actually use it for logins. +:::::: isn't in /etc/passwd.

I'll be able to fix "present getty after all services have started" only after 12.2 is released because new type of service (called Idle) has been introduced in upstream systemd to fix that but backporting it would be too invasive.

from the log, it looks like waiting for ypbind triggered a timer:
[   26.631738] systemd[1]: serial-getty@ttyS0.service holdoff time over, scheduling restart.

could you try to edit /lib/systemd/system/getty@.service and on the line After= add ypbind.service ?

Adding that line didn't affect the results.

I also tried removing the NIS components from /etc/shadow but it had no impact.

Disabling NIS completely had no impact.

Unfortunately replacing agetty with a script that runs it through strace didn't work either.

looking at the trace, ypbind is started before getty so it is not the issue.

just to test, you could add After=xdm.service (since xdm is one of the last service) but it probably won't help..

Is this bug still valid?  This because I'm able to login as root via serial console after adding /dev/ttyS0 to /etc/securetty. I'm running also grub on serial console and using console=ttyS0,1152000 console=tty0 on the kernel command line.

I'll need to install 13.1 on this machine to test. FWIW, I don't think it should be necessary to add ttyS0 to /etc/securetty when it was used as a system console during installation.

Without ttyS0 in /etc/securetty root is not allowed to use /dev/ttyS0 over a serial line.

Let's ask the maintainer of yast2-bootloader if the serial terminal line is added to the /etc/securetty in case of using the line for root access.

I guess this is not the case ... also I've added the security team to CC list as IMHO this could be a securitry issue as a serial line may or may not be a secure line for root access ... in last case this bug would become invalid.

This is not systemd but plymouth.  The plymouth process locks the termios structure with the ioctl TIOCSLCKTRMIOS and this leads to the effect that the first agetty on the system console e.g. the serial line does not change the termios structure with tcsetattr().

I've added a simple routine

  for (i = 0; i < 10; i++) {
          /*
           * Even with TTYReset=no it seems with systemd or plymouth
           * the termios flags become changed from under the first
           * agetty on a serial system console as the flags are locked.
           */
          struct termios lock;
          memset(&lock, 0, sizeof(struct termios));
          if (ioctl(STDIN_FILENO, TIOCGLCKTRMIOS, &lock) < 0)
                  break;
          if (!lock.c_iflag && !lock.c_oflag && !lock.c_cflag && !lock.c_lflag)
                  break;
          debug("termios locked\n");
          tcsendbreak(STDIN_FILENO, 0);           /* 0.25 upto 0.5 seconds */
  }

in termio_init() of agetty

This is an autogenerated message for OBS integration:
This bug (774126) was mentioned in
https://build.opensuse.org/request/show/213466 Factory / util-linux

Even if I've added a workaround to agetty there remains a bug in plymouth as systemd uses

   /usr/bin/plymouth --wait

in plymouth-quit-wait.service with 20 seconds timeout but plymouth does not unlock the termios structure within this timeout.  Clearly serial-getty@.service does depend that plymouth-quit-wait.service is finished.

This is an autogenerated message for OBS integration:
This bug (774126) was mentioned in
https://build.opensuse.org/request/show/213474 Factory / util-linux

Beside this problem that /usr/bin/plymouth --wait does not restore the consoles termios structure the other problem that the serial console is not part of the file /etc/securetty still remains.

IMHO and after a talk with Steffen the physical device of the system console should become part of /etc/securetty in the YaST2 module used for asking/setting the password of the super user root.

@ Raymond :  Please could you report the problem upstream, that is that plymouth
with option --wait does not unlock the termios structure of the the physical devices used for /dev/console aka the system console.  This seems to be similar to a problem with the X Window System, compare with bug #809806.

Currently systemd uses the plymouth-quit-wait.service with

 [Service]
 ExecStart=-/usr/bin/plymouth --wait
 Type=oneshot
 TimeoutSec=20
 [Install]
 WantedBy=multi-user.target

which is required by serial-getty@.service but it seems not to work.  That is without my patch as workaround the agetty on the first serial console will be fooled by plymouth.

https://bugs.freedesktop.org/show_bug.cgi?id=73585

reported upstream.

This is an autogenerated message for OBS integration:
This bug (774126) was mentioned in
https://build.opensuse.org/request/show/214769 Factory / util-linux

Maybe it should be noted that the current workaround is that now sulogin and agetty uses a loop to wait on TIOCGLCKTRMIOS and after the timeout of 20 seconds for agetty and 5 seconds for sulogin both programs now break the lock with TIOCSLCKTRMIOS. The  tcsendbreak() on stdin I've replaced with sleep() for a second. Also I've added lines to quit and wait on plymouthd in console-shell.service, rescue.service, and emergency.service.

openSUSE 12.2 is out of maintenance. It seems like this bug may have been fixed already, but I'll be cautious and move the bug to Tumbleweed instead. Setting needinfo on the assignee for an update.

IMHO this one is fixed ... to be exact I'm using serial console withut any problems. If this is not fixed for the reporter (Hi Jeff) then please reopen.