Bug 859716 - kernel-3.5.4-1.fc17.x86_64 fails to start storage devices, services
kernel-3.5.4-1.fc17.x86_64 fails to start storage devices, services
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-23 09:56 EDT by josip@icase.edu
Modified: 2013-01-02 12:40 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-02 12:40:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description josip@icase.edu 2012-09-23 09:56:06 EDT
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 11:19:15 EDT
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 11:23:12 EDT
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 09:50:33 EDT
It's not booting for i686 either
Comment 4 josip@icase.edu 2012-10-01 20:31:33 EDT
Boot still fails after upgrading to kernel-3.5.4-2.fc17.x86_64
Comment 5 josip@icase.edu 2012-10-14 12:27:15 EDT
Boot still fails after upgrading to kernel-3.6.1-1.fc17.x86_64
Comment 6 josip@icase.edu 2012-11-03 09:10:05 EDT
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 07:36:04 EST
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.