Bug 623102 - no login prompt on tty1
no login prompt on tty1
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
14
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Beta/F14BetaBlocker
  Show dependency treegraph
 
Reported: 2010-08-11 06:55 EDT by Kamil Páral
Modified: 2010-08-13 13:26 EDT (History)
9 users (show)

See Also:
Fixed In Version: anaconda-14.15-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 18:02:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
first example of tty1 (28.43 KB, image/png)
2010-08-11 06:55 EDT, Kamil Páral
no flags Details
second example of tty1 (30.50 KB, image/png)
2010-08-11 06:56 EDT, Kamil Páral
no flags Details
rpm -qa (5.92 KB, text/plain)
2010-08-11 06:56 EDT, Kamil Páral
no flags Details
system logs (590.00 KB, application/x-tar)
2010-08-11 06:56 EDT, Kamil Páral
no flags Details
[PATCH] update systemd's default.target for the desired runlevel (1.31 KB, patch)
2010-08-11 10:20 EDT, Michal Schmidt
no flags Details | Diff

  None (edit)
Description Kamil Páral 2010-08-11 06:55:45 EDT
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:
Comment 1 Kamil Páral 2010-08-11 06:56:06 EDT
Created attachment 438154 [details]
second example of tty1
Comment 2 Kamil Páral 2010-08-11 06:56:22 EDT
Created attachment 438155 [details]
rpm -qa
Comment 3 Kamil Páral 2010-08-11 06:56:39 EDT
Created attachment 438156 [details]
system logs
Comment 4 Michal Schmidt 2010-08-11 07:23:19 EDT
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
Comment 5 He Rui 2010-08-11 07:54:01 EDT
(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
Comment 6 Michal Schmidt 2010-08-11 09:15:43 EDT
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)
Comment 7 Michal Schmidt 2010-08-11 09:34:36 EDT
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
Comment 8 Chris Lumens 2010-08-11 09:39:44 EDT
Patches will be considered.
Comment 9 Michal Schmidt 2010-08-11 09:46:50 EDT
The code is in pyanaconda/desktop.py. I'll make a patch.
Comment 10 Michal Schmidt 2010-08-11 10:20:14 EDT
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.
Comment 11 Chris Lumens 2010-08-11 10:39:46 EDT
Thanks for the patch.  Applied and pushed.
Comment 12 Adam Williamson 2010-08-11 12:04:53 EDT
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
Comment 13 Michal Schmidt 2010-08-11 14:16:10 EDT
(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.
Comment 14 Michal Schmidt 2010-08-11 15:03:26 EDT
(In reply to comment #13)
> getty is actually there, but its initial prompt has been redrawn. That's a
> different bug.    
bug 623430
Comment 15 Adam Williamson 2010-08-11 15:56:39 EDT
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
Comment 16 Adam Williamson 2010-08-11 21:30:44 EDT
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
Comment 17 Adam Williamson 2010-08-11 22:31:16 EDT
Release criterion proposal is http://lists.fedoraproject.org/pipermail/test/2010-August/092615.html .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Kamil Páral 2010-08-12 02:43:22 EDT
adamw: Maybe F14Blocker or F14Beta instead of F14Target?
Comment 19 Adam Williamson 2010-08-12 03:08:06 EDT
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
Comment 20 Fedora Update System 2010-08-12 14:38:35 EDT
anaconda-14.16-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/anaconda-14.16-1.fc14
Comment 21 Fedora Update System 2010-08-12 18:02:23 EDT
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.
Comment 22 Liam Li 2010-08-13 03:37:57 EDT
This was fixed on F14-alpha-rc4, but on tty1, I saw some output which should not display on the first boot.
Comment 23 Adam Williamson 2010-08-13 13:26:05 EDT
that's probably covered by https://bugzilla.redhat.com/show_bug.cgi?id=619931 .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.