Description of problem:
No prompt after system boot. It is not possible to login.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot system in runlevel 3
no prompr after system boot
bash prompt after system is booted
In second console boot indicator show booting...
Is there one on vt2?
on vt2 is booting indicator (animation of progress)
Not sure how you got plymouth progress on vt2. Moving to systemd for the moment.
and what do you have on vt3?
F14 is under KVM,
Sorry, maybe, switching between vt was my mistake and I'm in the same vt.
Also, I found strange:
[root@rawhide ~]# runlevel
According to kernel parameter, runlevel have to be 3.
I try to use runlevel 2, but runlevel is 4 too...
By default runlevels 2, 3, 4 are just aliases for the same target "multi-user.target". If you query the current runlevel, then systemd will return you the highest runlevel that makes sense. That has the effect that even though requested 3 you got 4, which is effectively the same.
How did you get a shell if there are no logins shown?
>> How did you get a shell if there are no logins shown?
by ssh (slogin)
And, what do you see on vt3?
Could you please attach "systemctl list-units" and "systemctl list-jobs" issued shortly after the machine is booted and you logged in via ssh? Also, could you boot with systemd.log_level=debug on the kernel command line and attach "dmesg" from after boot here?
Created attachment 439452 [details]
boot with systemd.log_level=debug on the kernel command line and attach "dmesg" from after boot here
[sergeil@homedesk ~]$ cat /etc/issue
Fedora release 13 (Goddard)
Kernel \r on an \m (\l)
[sergeil@homedesk ~]$ uname -r
[sergeil@homedesk ~]$ rpm -qf `which qemu-kvm`
cmd line to run virtual machine:
qemu-kvm -localtime -m 512 -name rawhide -vga std \
-drive file=rawhide.img,if=virtio,boot=on -boot c \
-net nic,macaddr=52:54:00:12:34:CE,model=virtio -net tap
Created attachment 439453 [details]
[root@rawhide ~]# cat f14-systemctl_list-jobs
JOB UNIT TYPE STATE
0 jobs listed.
Hmm, the logs suggest the gettys have never been tried to be started. Is this an upgrade from older rawhide to newer rawhide? If so, have you seen this heads-up i posted on fedora-devel a while back?
Please try the command mentioned therein, and reboot.
Is there a packaged version of systemd that includes this fix?
(In reply to comment #11)
Note that the list web archive mangled Lennart's message. There really is no such thing as a "getty at .service". The original email said "getty@.service".
(In reply to comment #12)
> Is there a packaged version of systemd that includes this fix?
You misunderstand. There's no packaged fix as such. Only the manual fix-up.
The problem only shows up after upgrades from an early Rawhide. Upgrades from F13 to current F14 and fresh installations of F14 should need no manual intervention.
Michael, the reason I'm asking is because alpha dvd iso on a fresh install reproduces this problem.
Nightly livecd iso also reproduces this.
I'm looking for a packaged version that includes this fix.
(In reply to comment #14)
> Michael, the reason I'm asking is because alpha dvd iso on a fresh install
> reproduces this problem.
Are you sure it is the same problem? Perhaps what you are seeing is bug 623430 which certainly does affect F14 Alpha.
Closing this bug, since we have uploaded quite a few new package versions since the bug was initially created, and Sergei never reported back about the original issue. Sergei, feel free to reopen if this problem still persists and the recommendations from comment #11 didn't help.
After a lot of updates problem is gone.
Runlevel is correct too...