Description of problem: Clean installation of Fedora 15 using network installation was OK, but after the first reboot, the system stuck indefinitely. First boot did not show up leaving the box unusable. It is only possible to boot into runlevel 1 (single root user). Although the message says to use systemctl default to switch into normal operation mode, this does not work either and stucks indefinitely. Note that Fedora 14 installed/run without problems on the same hardware. Version-Release number of selected component (if applicable): dbus-1.4.6-3.fc15.i386 systemd-24-1.fc15.i386 firstboot-1.117-2.fc15.i386 kernel-2.6.38.2-9.fc15.i386 How reproducible: Always, on at least two of my different machines (did not want to spoil more hardware...). Steps to Reproduce: 1. Install F15 using network install (selected KDE instead of Gnome) 2. reboot as instructed by the installation 3. experience hang-up Actual results: First boot does not pop up, system stuck, hard reset required to put it out of the misery. Machine unusable. See screen log below under Additional info. Expected results: First boot shows up and allows finishing the installation procedure. Machine usable after installation. Additional info: This is the listing on the screen (retyped on other working machine so slim chance of typo): mkdir: cannot create directory `/run': File exists Starting initialize storage subsystems (RAID, LVM, etc.)... systemd-fsck[724]: /dev/sda2: recovering journal systemd-fsck[724]: /dev/sda2: clean, 81/128016 files, 49005/512000 blocks Starting /boot... Starting Enable all detected swap partitions... Starting Load Random Seed... Starting Recreate Volatile Files and Directories... Starting Tell Plymouth To Write Out Runtime Data... Starting Console System Startup logging... Starting Restore Sound Card State... Starting Bootup unhack.... Starting Set time via NTP... Starting Command Scheduler... Starting System Logging Service... Starting SYSV: sandbox, xguest and other apps that want to use pam_namespace require this script to be run at boot. This service script does not actually run any service but sets up: /var/tmp, /tmp and home directories to be used by these tools. If you do not use sandbox, xguest or pam_namespace you can turn this service off... Starting Console Mouse Manager... Starting ABRT Automated Bug Reporting Tool... Starting LSB: reset the system activity logs... Starting Job spooling tools... Starting ACPI Event Daemon... Starting Network Manager... Starting Self Monitoring and Reporting Technology (SMART) Daemon... Starting Machine Check Exception Logging Daemon... Starting irqbalance daemon... Starting System Setup Keyboard... Starting firstboot configuration program (graphical mode)... Starting D-Bus System Message Bus... (and now it is stuck forever, cursor blinking, but no echo on pressed keys, requires hard reset)
Please make sure you wait at least 3 minutes. If a service is stuck, this is the default timeout when systemd gives up on it and tries to continue with the followup units. Adam Williamson was seeing some issues with composes using dracut-008. It may be related. dracut would be the first thing I'd try updating (dracut-009-5.fc15 is on the way to stable) to see if that fixes the problem. ("dracut -f" then has to be run manually.) Also "enforcing=0" is always a good test to see if it is SELinux-related.
For the record, I was waiting all the time I was writing the problem report and retyping the screen of the stuck system, so it was about 15 minutes. Nothing had happened during that time... Just a note, when you install pre-release then testing repository is by default enabled, not only stable. Bodhi says dracut-009-5 was submitted 2011-03-31 to testing, my installation was 2011-04-09, so it is probably there (can't access the system at the moment to verify). I will give it another try and disable SELinux.
Oki, fresh new network install and got firstboot up and running, and my machine is back from zombieland :-) Seems like a proper fix was pushed into install repos just while ago. No need to play with SELinux. Most probably it was related to dracut issue mentioned by Michal, however I did not experience any tracebacks with Anaconda installer. Marking it a duplicate of Bug#694712 anyway, to keep logical relationship. Appologies for blaming systemd (which is an easy target to blame for all kinds of issues). *** This bug has been marked as a duplicate of bug 694712 ***