Description of problem: I did a minimal installation of F18 Beta TC7 (I tried both architectures). After the new system boots (or on any subsequent boot), there is no login prompt on tty1. tty2-6 contain login prompt ok. Version-Release number of selected component (if applicable): systemd-195-2.fc18.i686 systemd-libs-195-2.fc18.i686 systemd-sysv-195-2.fc18.i686 How reproducible: always Steps to Reproduce: 1. install minimal system 2. boot 3. see no prompt on tty1, just blinking cursor
This seems to break Beta criterion: 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 https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
Created attachment 638762 [details] anaconda-ks.cfg
Created attachment 638763 [details] anaconda.log
Created attachment 638764 [details] anaconda.packaging.log
Created attachment 638765 [details] anaconda.program.log
Created attachment 638766 [details] anaconda.storage.log
Created attachment 638767 [details] anaconda syslog
Created attachment 638768 [details] boot.log
Created attachment 638769 [details] messages
Neither enforcing=0 nor selinux=0 as a boot option helps.
Discussed at 2012-11-05 QA meeting acting as a blocker review meeting. Accepted as a blocker per criterion "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".
This is only broken when installing from Beta TC7 DVD, from netinst it works OK, I verified. <mkovarik> service getty@tty1 is disabled in systemd, it's only from DVD repo, from network repository this issue not occur
DVD: bash-4.2.37-6.fc18 initscripts-9.41-2.fc18 pam-1.1.6-1.fc18 util-linux-2.22-1.fc18 netinst: bash-4.2.39-1.fc18 initscripts-9.42-1.fc18 pam-1.1.6-3.fc18 util-linux-2.22.1-2.1.fc18
Already reported: 872845 Please mark 872845 bug as dup of this one. Cheers.
http://fpaste.stg.fedoraproject.org/1500 is the complete rpm -qa from a TC7 netinst (as with other testers, this works for me). http://fpaste.stg.fedoraproject.org/1502 is the complete rpm -qa from a TC7 DVD (as with other testers, this doesn't work for me). from the suspects kparal identified, i'd take a shot at initscripts as the fixer. I'll test just updating initscripts in the DVD case and see if that fixes it.
just updating initscripts doesn't fix it. neither does enforcing=0. http://paste.stg.fedoraproject.org/1503 is the diff between the netinst and dvd cases.
A full 'yum update' doesn't fix this either, so whatever fixes this has to happen at install time, apparently. makes me suspect 'initscripts' again, but it has to be in the install package set. unfortunately, it's difficult or impossible to test install with just cherrypicked additional packages atm.
*** Bug 872845 has been marked as a duplicate of this bug. ***
I don't think that initscripts are responsible for this. It looks that /usr/bin/systemctl enable \ getty@.service \ remote-fs.target \ systemd-readahead-replay.service \ systemd-readahead-collect.service >/dev/null 2>&1 || : from %post in systemd.spec is not executed or fails.
I would expect that to result in *no* accessible gettys, though. not just tty1.
getty@.service has: [Install] Alias=getty.target.wants/getty So, just tty1 there. The others are auto-spawned.
Note that as we're doing an unfreeze and general push tonight, this might magically go away in TC8, if whatever fixes it happens to get pushed stable.
(In reply to comment #22) > Note that as we're doing an unfreeze and general push tonight, this might > magically go away in TC8, if whatever fixes it happens to get pushed stable. Let's make sure. Please test and provide karma to following updates: https://admin.fedoraproject.org/updates/FEDORA-2012-17504/bash-4.2.39-1.fc18 https://admin.fedoraproject.org/updates/FEDORA-2012-17741/initscripts-9.42-1.fc18.1 https://admin.fedoraproject.org/updates/FEDORA-2012-17448/util-linux-2.22.1-2.1.fc18
Still broken with smoke16 DVD. bash-4.2.37-6.fc18.x86_64 initscripts-9.41-2.fc18.x86_64 util-linux-2.22-1.fc18.x86_64 systemd-195-2.fc18.x86_64
smoke16 only had the new anaconda, nothing else: it wasn't done with the stable push packages.
Installation of a systemd-libs package happens *after* systemd. However, systemd-libs provides shared library libsystemd-daemon, and systemctl is linked against it. Thus, calls to systemctl in a %post of systemd package fail, with an error produced by a dynamic linker, such that it couldn't find shared library. There is a circular dependency between systemd and systemd-libs. We should probably remove requirement of systemd by systemd-libs.
*** Bug 874459 has been marked as a duplicate of this bug. ***
systemd-195-6.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-195-6.fc18
Package systemd-195-6.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-6.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17924/systemd-195-6.fc18 then log in and leave karma (feedback).
Fixed in 18 Beta TC8.
(In reply to comment #30) > Fixed in 18 Beta TC8. Can you provide karma, please? Thanks. I also verified this.
Verified on TC8, and karma has been provided.
anaconda-18.28-1.fc18 is stable now, closing.