Bug 624249 - boot in runlevel 3 can not finish (it do not run shell).
boot in runlevel 3 can not finish (it do not run shell).
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-15 03:47 EDT by Sergei LITVINENKO
Modified: 2010-09-14 13:01 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 626498 (view as bug list)
Environment:
Last Closed: 2010-09-13 17:03:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
boot with systemd.log_level=debug on the kernel command line and attach "dmesg" from after boot here (49.33 KB, text/plain)
2010-08-18 13:40 EDT, Sergei LITVINENKO
no flags Details
systemctl list-units (6.68 KB, text/plain)
2010-08-18 13:48 EDT, Sergei LITVINENKO
no flags Details

  None (edit)
Description Sergei LITVINENKO 2010-08-15 03:47:42 EDT
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...
Comment 1 Bill Nottingham 2010-08-16 13:17:46 EDT
Is there one on vt2?
Comment 2 Sergei LITVINENKO 2010-08-16 13:49:02 EDT
on vt2 is booting indicator (animation of progress)
Comment 3 Bill Nottingham 2010-08-16 14:08:41 EDT
Not sure how you got plymouth progress on vt2. Moving to systemd for the moment.
Comment 4 Lennart Poettering 2010-08-16 15:20:10 EDT
and what do you have on vt3?
Comment 5 Sergei LITVINENKO 2010-08-16 15:55:13 EDT
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...
Comment 6 Lennart Poettering 2010-08-16 16:46:09 EDT
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?
Comment 7 Sergei LITVINENKO 2010-08-16 23:46:57 EDT
>> How did you get a shell if there are no logins shown?

by ssh (slogin)
Comment 8 Lennart Poettering 2010-08-17 08:45:43 EDT
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?
Comment 9 Sergei LITVINENKO 2010-08-18 13:40:30 EDT
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
Comment 10 Sergei LITVINENKO 2010-08-18 13:48:15 EDT
Created attachment 439453 [details]
systemctl list-units

[root@rawhide ~]# cat f14-systemctl_list-jobs 
JOB UNIT         TYPE       STATE  

0 jobs listed.
Comment 11 Lennart Poettering 2010-08-18 16:59:20 EDT
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.
Comment 12 d. johnson 2010-08-23 18:36:03 EDT
Is there a packaged version of systemd that includes this fix?
Comment 13 Michal Schmidt 2010-08-24 12:05:42 EDT
(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.
Comment 14 d. johnson 2010-08-24 14:18:40 EDT
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.
Comment 15 Michal Schmidt 2010-08-24 18:28:18 EDT
(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.
Comment 16 Lennart Poettering 2010-09-13 17:03:17 EDT
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.
Comment 17 Sergei LITVINENKO 2010-09-14 13:01:36 EDT
After a lot of updates problem is gone.
Runlevel is correct too...

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