Created attachment 438153 [details] first example of tty1 Description of problem: I have install F14 Alpha RC3 with minimal package set. After installed system boots, I don't get login prompt on tty1, I have to switch to some other tty. It took me a long time to recognize that, for a long time I supposed the system is simply frozen. The display of tty1 varies, sometimes there are more services started, sometimes less (see attachments). But no login prompt. Version-Release number of selected component (if applicable): systemd-7.1.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. Install minimal package set 2. Boot 3. Actual results: no login prompt on tty1 Expected results: login prompt on tty1 Additional info:
Created attachment 438154 [details] second example of tty1
Created attachment 438155 [details] rpm -qa
Created attachment 438156 [details] system logs
Not sure yet why this is happening, but as Adam Williamson indicated earlier in a different bug, not having a getty on tty1 is not serious enough to be an Alpha blocker: https://bugzilla.redhat.com/show_bug.cgi?id=619889#c19
(In reply to comment #1) > Created an attachment (id=438154) [details] > second example of tty1 Reproduced it on systemd-7.1.fc14.i686 after minimal virt-installing F14-Alpha-RC3-i386-DVD
I reproduced it. For some reason default.target points to graphical.target after minimal installation. I suspect that when systemd-units's postinstall scriptlet runs during installation, /etc/inittab is not there yet and the "[ -z $runlevel ]" branch is taken... /root/install.log confirms it - all systemd* packages were installed before initscripts (which owns /etc/inittab)
I believe anaconda modifies /etc/inittab after the packages are installed. So anaconda should update /etc/systemd/system/default.target too. When it writes runlevel N to initttab, it should update default.target to be a symlink to /etc/systemd/system/runlevel$N.target
Patches will be considered.
The code is in pyanaconda/desktop.py. I'll make a patch.
Created attachment 438197 [details] [PATCH] update systemd's default.target for the desired runlevel This patch should do it. I tested the Desktop class separately from anaconda. It created default.target as expected.
Thanks for the patch. Applied and pushed.
I'm not entirely sure this is the problem, though it might be =). I know a bug similar to this exists after booting live, installing, and booting with parameter '3', which causes systemd to go down its multi-user.target path. After firstboot runs, you wind up at a black screen; you can either hit ctrl-alt-f2 to get to tty2, or ctrl-c and then tty1 pops up. I'm not sure why that is - I don't know what process it is that's hanging around that gets zapped out of the way by the ctrl-c. Kamil, can you do a bit more testing here? Can you try doing a minimal install then booting with parameter 'systemd.unit=multi-user.target' ? That should avoid the problem with the default target by forcing it to use the multi-user.target (which is the equivalent of runlevel 3). See how that behaves. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #12) > I'm not entirely sure this is the problem, though it might be =). I know a bug > similar to this exists after booting live, installing, and booting with > parameter '3', which causes systemd to go down its multi-user.target path. > After firstboot runs, you wind up at a black screen; you can either hit > ctrl-alt-f2 to get to tty2, or ctrl-c and then tty1 pops up. ... or you can press Enter :-) getty is actually there, but its initial prompt has been redrawn. That's a different bug.
(In reply to comment #13) > getty is actually there, but its initial prompt has been redrawn. That's a > different bug. bug 623430
ah, I see. Thanks. So this bug occurs when you do a traditional install without X included, which would be most common in the case of a minimal install, right? The same talking point applies here as to 623430: just how broken can a console boot be for Alpha? We haven't pinned that down with a criterion yet, so we should discuss it at go/no-go. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at today's go/no-go meeting. We decided this doesn't constitute an Alpha blocker. We plan to take the fix for rc4 if available by tomorrow afternoon, however, as it's a simple and clearly correct change and gives a substantial benefit. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Release criterion proposal is http://lists.fedoraproject.org/pipermail/test/2010-August/092615.html . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
adamw: Maybe F14Blocker or F14Beta instead of F14Target?
depends what we decide on the list, but yeah, let's throw it on Beta for now to make sure we don't forget about it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-14.16-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/anaconda-14.16-1.fc14
anaconda-14.15-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
This was fixed on F14-alpha-rc4, but on tty1, I saw some output which should not display on the first boot.
that's probably covered by https://bugzilla.redhat.com/show_bug.cgi?id=619931 . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers