Red Hat Bugzilla – Bug 873387
After minimal DVD install there is no login prompt on tty1
Last modified: 2012-11-14 04:51:13 EST
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):
Steps to Reproduce:
1. install minimal system
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
Created attachment 638762 [details]
Created attachment 638763 [details]
Created attachment 638764 [details]
Created attachment 638765 [details]
Created attachment 638766 [details]
Created attachment 638767 [details]
Created attachment 638768 [details]
Created attachment 638769 [details]
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
Already reported: 872845
Please mark 872845 bug as dup of this one.
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 \
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.
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:
Still broken with smoke16 DVD.
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.
* 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:
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.