Bug 524408 - Created /etc/fstab causes boot failure at filesystem check when /boot on usb key
Summary: Created /etc/fstab causes boot failure at filesystem check when /boot on usb key
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-19 22:02 UTC by Elijah Newren
Modified: 2010-01-20 18:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-20 18:51:37 UTC


Attachments (Terms of Use)

Description Elijah Newren 2009-09-19 22:02:26 UTC
(Yes, it's me again.  Sorry, but this weird use case just naturally triggered 4 separate bugs.)

Description of problem:
After booting Fedora 11 with an installation where / is mount on at the encrypted /dev/sda1 (laptop harddrive) and /boot is mount at /dev/sdb1 (usb key, unencrypted), boot fails early.  My laptop screen says (other than my lack of copying the correct number of spaces; hope I didn't introduce any other typos):

       Welcome to Fedora
       Press 'I' to enter ineteractive startup.
Starting udev:  [ OK ]
Setting hostname Miney: [ OK ]
mdadm: No arrays found in config file or automatically
Setting up Logical Volume Management: [ OK ]
Checking filesystems
Fedora-11-x86_64: clean, 84066/1925120 files, 682935/7680565 blocks
fsck.ext3: Unable to resolve 'UUID=00e870eb-2489-41fd-92e5-4374ced5eae0'
/: clean, 233339/5373952 files, 1716601/10739452 blocks
                                                    [ 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.
Give root password for maintenance
(or type Control-D to continue):


Version-Release number of selected component (if applicable):
anaconda-11.5.0.59-1.fc11.x86_64


How reproducible:
100%  (Same problem existed in Fedora 10; sorry for not reporting this 6 months ago)

Steps to Reproduce:
1. Install Fedora-11, with /boot on a usb key
2. Work around bug 524397, bug 524399, and bug 524407.
3. Reboot
  
Actual results:
Boot fails at the filesystem check stage

Expected results:
Boot into fedora 11

Additional info:

Once at this point you can fix the problem by:
# mount -o remount,rw /
# vi /etc/fstab
(Comment out the line that mounts /boot, then save and exit)
# <Ctrl-D>

then the system will reboot, and work.  Replacing the UUID in the /etc/fstab file with /dev/sdb1 does not fix the problem (or at least it didn't in Fedora 10, I admit I didn't bother trying in Fedora 11), I'm guessing because it's too early in the boot process to access usb devices.  However, interestingly, one can mount the usb key when in the system recovery shell that you get dumped into.

Comment 1 Hans de Goede 2009-09-21 13:36:40 UTC
The problem is that the usb-mass-storage driver waits a couple of seconds before
scanning any newly discovered devices, it does this because some buggy devices are
not ready to be scanned immediately after being plugged in.

What you can try to fix this without having to comment out the /boot line is add:
sleep 10

Before the following 2 lines:
# Sync waiting for storage.
{ rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; } >/d

If that works my guess about the problem is right, then we still need to come
up with a better solution, but it is a start.

Comment 2 Hans de Goede 2009-09-21 13:51:03 UTC
/me needs more coffee.

Sorry that was not entirely clear, when I said:

What you can try to fix this without having to comment out the /boot line is
add:
sleep 10

Before the following 2 lines:
# Sync waiting for storage.
{ rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; } 

I should have added that these lines can be found in /etc/rc.d/rc.sysinit and
that this file is where the sleep should be added.


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