Hide Forgot
Description of problem: After upgrading from Fedora 14 to Fedora 15 the system boots into maintenance mode after: Cannot add dependency job for unit autofs.target, ignoring: Unit autofs.target failed to load: No such file or directory. See system logs and 'systemctl status' for details After various: Unit systemd-logger.service entered failed state systemd-logger.service start request repeated to quickly, refusing to start. udev: converting old udev database Ext3-fs (dm-0): using internal journal ---- [ cut here ] ---- Warning: at drivers/char/tty_io.c:1325 tty_open+0x213/0x3b7() Hardware name: Modules linked in: Pid: 137, comm: plymouthd Not tainted 2.6.36.1-7.rc1.fc15.i686 #1 the whole thing crashes. And boots into maintenance mode. This on vmware, kvm *and* on real hardware. Taking a plain vanilla kernel not created, patched and build by fedora makes the system boot on vmware, kvm *and* real hardware. Version-Release number of selected component (if applicable): 2.6.36.1-7.rc1.fc15.i686 for later kernels: worker did not accept message -1 (Connection refused), kill it multiple times. After these the system boots into maintenance mode. It is the same for all newer kernels: 2.6.38.6-26.rc1.fc15.i686 2.6.38.5-24.fc15.i686 2.6.38.2-9.fc15.i686 How reproducible: always. Just upgrade from Fedora 14. Steps to Reproduce: 1. Install Fedora 14 2. Update to the latest package-versions 3. Upgrade to Fedora 15 Actual results: Unusable system. Expected results: Fedora 15 running seamlessly Additional info: Ferora runs if kernels are replaced with plain vanila ones from kernel.org, compiled using Fedora 14.
Please boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg". When you get to the maintenance shell, store the logs using "dmesg > dmesg.txt". Attach the file here. Thanks.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Closing, because this bug has been marked [NEEDINFO] for 5 months. Feel free to reopen if you can provide the requested information.
Got here via a google search with this same problem. I think it's from an incomplete upgrade - I got to the same symptom when my f14 box dropped the wifi adapter in the middle of an upgrade (and modprobing ath9k didn't bring it back to life as it usually does). My startup got stuck on systemd dependencies - for some reason it couldn't start a LUKS volume that I could start by hand from a maintenance shell (and sh -x doesn't work anymore to debug...). I was able to drop to emergency shell, do 'init 3' to get to a prompt, manually configure my network, and do a 'yum -y update' which pulled down several more packages, and then when I rebooted all was well.