Bug 695029

Summary: F15 doesn't boot in KVM
Product: [Fedora] Fedora Reporter: David Kovalsky <dkovalsk>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 15CC: benl, johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-19 08:16:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Screenshot from virtmanager
none
yum.log
none
boot.log
none
Xorg log
none
Screenshot from virtmanager where boot gets stuck with debugging on
none
Screenshot from virtmanager where boot gets stuck with debugging on (2)
none
Console output where boot gets stuck for 3m
none
Console output after boot starts moving again none

Description David Kovalsky 2011-04-09 21:22:03 UTC
Created attachment 491007 [details]
Screenshot from virtmanager

Installed yesterday, updated to the latest Mirror Manager suggests ATM.

What logs might be interesting to you?

Comment 1 Michal Schmidt 2011-04-10 11:44:09 UTC
So it worked after installation before the update? Knowing what was update would be helpful (/var/log/yum.log).

Does it boot with enforcing=0?

Comment 2 David Kovalsky 2011-04-11 09:17:07 UTC
Michal - I forgot to mention - it didn't boot with enforcing=0 / selinux=0 (does that even work these days?). 

I've actually never been able to boot the system. I installed on Friday I believe, no luck with booting. 

So I used loop device, kpartx and created a full directory structure, chrooted into in and run `yum update' in hope that there has been an update meanwhle. About 200 packages got updated (I'll attach yum.log in a minute), but the results are the same - no boot.

Comment 3 David Kovalsky 2011-04-11 09:24:13 UTC
Created attachment 491179 [details]
yum.log

Comment 4 David Kovalsky 2011-04-11 09:28:00 UTC
Created attachment 491181 [details]
boot.log

Comment 5 David Kovalsky 2011-04-11 09:30:47 UTC
Created attachment 491183 [details]
Xorg log

It also seems that Xorg was attemting to start. But I never got the the point where I could see GUI or reach a command line. 

Attaching the Xorg log. Sorry for the sparse info, it's really hard for me to tell what's going on or where the boot is getting stuck. Can I perhaps raise the verbosity somehow?

Comment 6 Michal Schmidt 2011-04-11 11:47:05 UTC
I'm curious about the "Failed to create directory /var/lock/subsys: No such file or directory" on the screenshot. Does /var/lock exist? Is it a directory, or a symlink to ../run/lock ?

(In reply to comment #2)
> Michal - I forgot to mention - it didn't boot with enforcing=0 / selinux=0
> (does that even work these days?). 

Yes, it should work. My F15 system boots with SELinux enforcing. With disabled it works too.

(In reply to comment #3)
> yum.log

I see that dracut was updated to 009-5. I don't know if your initramfs was regenerated since then. If not, try to do that in the chroot. There were some problems reported with booting F15 composes that used dracut-008.

(In reply to comment #5)
> Can I perhaps raise the verbosity somehow?

You could use "systemd.log_level=debug".

BTW, make sure you wait at least 3 minutes when the boot appears to be stuck. It is the default timeout.

Comment 7 David Kovalsky 2011-04-12 13:00:02 UTC
lrwxrwxrwx.  1 root root   11 Apr  8 23:03 lock -> ../run/lock

/var/lock is a symlink. 

# ls -l lock/
total 8
drwxrwxr-x. 2 root lock 4096 Apr  5 14:45 lockdev
drwx------. 2 root root 4096 Feb  9 15:38 lvm


Re SELinux: I was thinking out loud if selinux=0 actually disables SELinux :)

Initramfs rebuilt, it is the same size as the old one and md5sums match. So this doesn't make any difference. 

Added the debug log.

The boot got stuck for 3 minutes as you've mentioned (see the screenshot), after the 3 minute timeout the boot continued. Still, I don't see any GUI (pure black screen) and trying to switch terminals I can't find a console to log in.

Comment 8 David Kovalsky 2011-04-12 13:01:08 UTC
Created attachment 491477 [details]
Screenshot from virtmanager where boot gets stuck with debugging on

Comment 9 David Kovalsky 2011-04-12 13:02:35 UTC
Created attachment 491478 [details]
Screenshot from virtmanager where boot gets stuck with debugging on (2)

Got this by pressing ESC 2 times to see the TUI status and going back to text.

Comment 10 Michal Schmidt 2011-04-12 13:19:37 UTC
(In reply to comment #7)
> Re SELinux: I was thinking out loud if selinux=0 actually disables SELinux :)

Yes, it does. This always worked. There was a bug when SELinux was disabled using /etc/selinux/config, but that has been fixed too.

> The boot got stuck for 3 minutes as you've mentioned (see the screenshot),
> after the 3 minute timeout the boot continued. Still, I don't see any GUI (pure
> black screen) and trying to switch terminals I can't find a console to log in.

Did it manage to start syslog and write the logs to /var/log/messages?

If that did not work, boot with "selinux=0 console=ttyS0 systemd.log_level=debug systemd.log_target=kmsg", remove "rhgb quiet" if they're there, and get the messages using "virsh console <your_guest>".

Comment 11 David Kovalsky 2011-04-13 18:29:04 UTC
Created attachment 491847 [details]
Console output where boot gets stuck for 3m

/var/log/messages is zero length, so did the steps described above to capture the output

Comment 12 David Kovalsky 2011-04-13 18:31:45 UTC
Created attachment 491848 [details]
Console output after boot starts moving again

I got to firstboot this time around.

Comment 13 Michal Schmidt 2011-04-14 19:14:34 UTC
Hmm, why does the log say "dracut: dracut-008-7.fc15"?
I have to doubt this then:
> Initramfs rebuilt, it is the same size as the old one and md5sums match.
> So this doesn't make any difference.

Comment 14 David Kovalsky 2011-04-15 09:07:01 UTC
Perhaps I did the rebuild wrong? 

I did cp /boot/$image /boot/$image.old
mkinitrd /boot/$image `uname -r`

And then compared $image and $image.old by md5sum.

Is that the right approach?

Comment 15 Michal Schmidt 2011-04-17 21:14:18 UTC
mkinitrd is just a wrapper for dracut.
If you really made a copy and did not pass "-f" to dracut, you should have got an error:
  F: Will not override existing initramfs (/boot/$image) without --force

To recreate the initramfs for the currently running kernel, just use simply "dracut -f".

Comment 16 David Kovalsky 2011-04-18 19:42:57 UTC
Michal, sorry for not being clear. After making a backup I removed the old initramfs. So mkinird really created the same. 

But after I removed the initramfs and ran `dracut -f', new (different) one was generated. And even in enforcing mode (with the most recent updates as of right now) I'm able to boot in KVM without any lag. 

Thanks a lot for your help!

(I believe this bug can be closed)