Bug 859716 - kernel-3.5.4-1.fc17.x86_64 fails to start storage devices, services
Summary: kernel-3.5.4-1.fc17.x86_64 fails to start storage devices, services
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-23 13:56 UTC by josip@icase.edu
Modified: 2013-01-02 17:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-02 17:40:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description josip@icase.edu 2012-09-23 13:56:06 UTC
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


How reproducible:


Steps to Reproduce:
1. Install kernel-3.5.4-1.fc17.x86_64
2. Boot
3. Boot fails
  
Actual results:
Boot fails

Expected results:
Boot succeeds

Additional info:
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.

Comment 1 josip@icase.edu 2012-09-23 15:19:15 UTC
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[1]: Job nfs-lock.service/start failed with result 'dependency'.
[   94.944493] systemd[1]: Job rpcbind.service/start failed with result 'dependency'.
[   94.944503] systemd[1]: Job rpcbind.socket/start failed with result 'dependency'.
[   94.944541] systemd[1]: 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.

Comment 2 josip@icase.edu 2012-09-23 15:23:12 UTC
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.

Comment 3 Param Singh 2012-09-25 13:50:33 UTC
It's not booting for i686 either

Comment 4 josip@icase.edu 2012-10-02 00:31:33 UTC
Boot still fails after upgrading to kernel-3.5.4-2.fc17.x86_64

Comment 5 josip@icase.edu 2012-10-14 16:27:15 UTC
Boot still fails after upgrading to kernel-3.6.1-1.fc17.x86_64

Comment 6 josip@icase.edu 2012-11-03 13:10:05 UTC
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.

Comment 7 josip@icase.edu 2012-11-04 12:36:04 UTC
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.


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