Bug 708034 - fsck fails on boot in EC2
Summary: fsck fails on boot in EC2
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Cloud Image Validation
Classification: Red Hat
Component: images
Version: RHEL5.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jay Greguske
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-26 15:31 UTC by Jay Greguske
Modified: 2011-10-11 21:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-11 21:16:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jay Greguske 2011-05-26 15:31:15 UTC
INIT: version 2.86 booting
 
                Welcome to Red Hat Enterprise Linux Server
                Press 'I' to enter interactive startup.
Setting clock : Thu May 19 15:58:05 EDT 2011 [  OK  ]
 
Starting udev: [  OK  ]
 
Loading default keymap (us): [  OK  ]
 
Setting hostname localhost.localdomain:  [  OK  ]
 
No devices found
failed to stat() /dev/mapper/no
failed to stat() /dev/mapper/block
failed to stat() /dev/mapper/devices
failed to stat() /dev/mapper/found
Setting up Logical Volume Management:   No volume groups found
[  OK  ]
 
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a LABEL=/
fsck.ext3: Unable to resolve 'LABEL=/'
 
[FAILED]
 
 
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Press enter for maintenance
(or type Control-D to continue):
---------------------------------------------------------------
For a successful start:
INIT: version 2.86 booting
 
                Welcome to Red Hat Enterprise Linux Server
                Press 'I' to enter interactive startup.
Cannot access the Hardware Clock via any known method.

Comment 1 Jay Greguske 2011-05-26 15:32:43 UTC
Ben's email:

"""
The root of the problem is that the root device is mapped to /dev/sda. The swap device is mapped to /dev/sda3. I think that this probably confusing UDEV, since normally, /dev/sda is used at the device identifier and /dev/sdaX[1-9] is used as the device partition mappings. EC2 maps both /dev/sda and /dev/sda3 as block devices. From the kernels perspective, it doesn't care.

I believe that if you change the block mapping for the root device from /dev/sda to /dev/sda1, this should fix the problem for you. I haven't had a chance to test the theory, but it would get around that suspect rule and not require any other changes than a re-registration of the AMI. 
"""

Comment 2 Harald Hoyer 2011-05-27 08:50:26 UTC
Here is the bugzilla for
failed to stat() /dev/mapper/no
failed to stat() /dev/mapper/block
failed to stat() /dev/mapper/devices
failed to stat() /dev/mapper/found

https://bugzilla.redhat.com/show_bug.cgi?id=671386

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2011:11115-02
http://errata.devel.redhat.com/errata/show/11115

Comment 3 Harald Hoyer 2011-05-27 08:51:06 UTC
Does it help with sda1 vs. sda and LABEL=root vs LABEL=/ ?

Comment 4 Jay Greguske 2011-05-27 12:44:55 UTC
/dev/sda1 was the trick. 

Thanks Harald!


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