Description of problem: No prompt after system boot. It is not possible to login. Version-Release number of selected component (if applicable): initscripts-9.16-2.fc14.i686 How reproducible: 100% Steps to Reproduce: 1. boot system in runlevel 3 2. 3. Actual results: no prompr after system boot Expected results: bash prompt after system is booted Additional info: 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 N 4 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 host: [sergeil@homedesk ~]$ cat /etc/issue Fedora release 13 (Goddard) Kernel \r on an \m (\l) [sergeil@homedesk ~]$ uname -r 2.6.33.6-147.2.4.fc13.i686.PAE [sergeil@homedesk ~]$ rpm -qf `which qemu-kvm` qemu-system-x86-0.12.3-8.fc13.i686 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] systemctl list-units [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? http://lists.fedoraproject.org/pipermail/devel/2010-August/140294.html Please try the command mentioned therein, and reboot.
Is there a packaged version of systemd that includes this fix?
(In reply to comment #11) > http://lists.fedoraproject.org/pipermail/devel/2010-August/140294.html 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...