Created attachment 491896 [details] dmesg (systemd.log_level=debug systemd.log_target=kmsg) Description of problem: After performing an iSCSI installation (1 remote iSCSI disk, 3 local disks), and booting the system with console=ttyS0, firstboot-text appears to be running while getty is also running on ttyS0. This prevents typing any commands after logging into ttyS0 Version-Release number of selected component (if applicable): * systemd-24-1.fc15.i686 * firstboot-1.117-2.fc15.i686 How reproducible: * 4 out of 4 attempts Steps to Reproduce: 1. Perform iSCSI install to a virt-guest 2. Boot installed system with 'serial console=ttyS0' Actual results: ┌────────┤ Choose a Tool ├─────────┐ │ │ │ Authentication configuration │ │ Firewall configuration │ Login incorrect │ Keyboard configuration │ │ Network configuration │ login: │ System services │ │ │ │ ┌──────────┐ ┌──────┐ │ │ │ Run Tool │ │ Quit │ │ │ └──────────┘ └──────┘ │ │ │ │ │ └──────────────────────────────────┘ Expected results: Firstboot-text and the login prompt shouldn't be running at the same time. Additional info: * This doesn't happen on *every* serial console installation. This only seems to happen when iSCSI is involved. * Before I login to ttyS0 ... # ps -wef | grep ttyS0 root 952 1 0 15:51 ttyS0 00:00:00 /bin/bash /etc/init.d/firstboot start root 1009 952 0 15:51 ttyS0 00:00:00 /usr/bin/python2 /usr/sbin/firstboot root 1127 1009 0 15:51 ttyS0 00:00:00 setup * After I manage to login to ttyS0 (many repeated tries) ... # ps -wefww | grep firstboot root 952 1 0 15:51 ? 00:00:00 /bin/bash /etc/init.d/firstboot start root 1009 952 0 15:51 ? 00:00:00 /usr/bin/python2 /usr/sbin/firstboot # systemctl status firstboot-text.service firstboot-text.service - firstboot configuration program (text mode) Loaded: loaded (/lib/systemd/system/firstboot-text.service) Active: activating (start) since Wed, 13 Apr 2011 16:00:41 -0400; 3min 2s ago Main PID: 949 (firstboot) CGroup: name=systemd:/system/firstboot-text.service ├ 949 /bin/bash /etc/init.d/firstboot start ├ 1022 /usr/bin/python2 /usr/sbin/firstboot └ 1118 setup # systemctl status serial-getty serial-getty - Serial Getty on ttyS0 Loaded: loaded (/lib/systemd/system/serial-getty@.service) Active: active (running) since Wed, 13 Apr 2011 16:00:44 -0400; 2min 46s ago Main PID: 1091 (agetty) CGroup: name=systemd:/system/serial-getty@.service/ttyS0 └ 1091 /sbin/agetty -s ttyS0 115200 38400 9600
Discussed at the 2011-04-21 blocker bug review meeting. This bug hits the following release criteria: "The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices" "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so" As this bug does hit release criteria, it was accepted as a blocker for final release.
Hmm, firstboot currently orders itself before getty, but this is not sufficient if a serial console is used. Here's how I suggest this is fixed: instead of ordering relative to getty, firstboot should be ordered before systemd-user-sessions.service. All terminals (i.e. both getty and serial-getty) are already ordered after systemd-user-sessions.service and hence transitively would also be ordered after firstboot. Hence the suggested patch: Replace the following line: Before=getty By the following line in /lib/systemd/system/firstboot-text.service: Before=systemd-user-sessions.service And that should be all that is necessary. (Side note: systemd-user-sessions.service is used to enable logins locally. it removes /etc/nologin at boot) Reassigning to firstboot, where this small change needs to be made.
Discussed at 2011-04-29 NTH review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html). Seems like a straightforward change. Waiting on mgracik to proceed...
Fixed in firstboot-1.118-1
firstboot-1.118-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/firstboot-1.118-1.fc15
Package firstboot-1.118-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-1.118-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/firstboot-1.118-1.fc15 then log in and leave karma (feedback).
I am no longer seeing the reported issue, although I am seeing a new issue related to the change (see bug#701648)
firstboot-1.119-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/firstboot-1.119-1.fc15
Package firstboot-1.119-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-1.119-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/firstboot-1.119-1.fc15 then log in and leave karma (feedback).
firstboot-1.119-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.