Red Hat Bugzilla – Bug 859716
kernel-3.5.4-1.fc17.x86_64 fails to start storage devices, services
Last modified: 2013-01-02 12:40:06 EST
Description of problem:
Booting kernel-3.5.4-1.fc17.x86_64 fails at the point of starting storage devices (RAID, LVM, ...). Entering recovery mode shows that all services failed to start claiming "dependency" problems. On the same machine, previous kernel-3.5.3-1.fc17.x86_64 boots just fine.
Version-Release number of selected component (if applicable): kernel-3.5.4-1.fc17.x86_64
Steps to Reproduce:
1. Install kernel-3.5.4-1.fc17.x86_64
3. Boot fails
Interestingly enough, kernel-3.5.4-1.fc17.x86_64 mounts /boot, /, and /tmp but not /var before the failure. In recovery, /var can be mounted just fine.
Services (such as network) fail to start in recovery.
The output of dmesg from a failed kernel-3.5.4-1.fc17.x86_64 boot looks benign up to this point (note the "dependency" complaints):
[ 5.631806] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null)
[ 5.674494] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[ 94.944481] systemd: Job nfs-lock.service/start failed with result 'dependency'.
[ 94.944493] systemd: Job rpcbind.service/start failed with result 'dependency'.
[ 94.944503] systemd: Job rpcbind.socket/start failed with result 'dependency'.
[ 94.944541] systemd: Job cups.socket/start failed with result 'dependency'.
By contrast, kernel-3.5.4-1.fc17.x86_64 boot proceeds normally at the equivalent point.
Uhm, in "Comment 1", there is a typo: kernel-3.5.3-1.fc17.x86_64 boots normally, kernel-3.5.4-1.fc17.x86_64 fails.
It's not booting for i686 either
Boot still fails after upgrading to kernel-3.5.4-2.fc17.x86_64
Boot still fails after upgrading to kernel-3.6.1-1.fc17.x86_64
On another computer (AMD, not Intel), kernel-3.6.2-4.fc17.x86_64 also failed to boot. Original kernel-3.3.4-5.fc17.x86_64 boots fine on this AMD machine. Good news: Upgrading to kernel-3.6.3-1.fc17.x86_64 also resulted in normal boot. Progress?
I have NOT yet confirmed that this upgrade fixes the original problem on my Intel machine. Stay tuned.
I found a fix for my Intel computer -- the problem was that kernel started naming RAID devices differently, so they could not be mounted.
In kernel 3.4.x, those devices are symbolic links like /dev/md/FDQN:name, where FDQN is the fully qualified host name.
With kernels 3.5.x and 3.6.x, those symbolic links are simply /dev/md/name.
Go figure... Changing /etc/fstab to match fixed the boot problem.