Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 185534 - [EMC RHEL3 U8 bug] init:mount:fsck fails when fstype is set to auto on _netdev device in /etc/fstab
Summary: [EMC RHEL3 U8 bug] init:mount:fsck fails when fstype is set to auto on _netde...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: e2fsprogs
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Jay Turner
Depends On:
Blocks: RHEL3U8CanFix
TreeView+ depends on / blocked
Reported: 2006-03-15 16:38 UTC by Wayne Berthiaume
Modified: 2015-01-08 00:12 UTC (History)
10 users (show)

Fixed In Version: RHBA-2006-0400
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-07-20 14:26:05 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0400 normal SHIPPED_LIVE e2fsprogs bug fix update 2006-07-19 18:26:00 UTC

Description Wayne Berthiaume 2006-03-15 16:38:00 UTC
Description of problem:
With the following entry in /etc/fstab I see an error message from 
init:mount:fsck: "Could not determine filesystem type for /dev/emcpowera1" and 
init:netfs:fsck is successful.

/dev/emcpowera1         /zoner/emcpowera        auto    _netdev         1 1

If I change the entry in /etc/fstab to the following there are no error 
messages from init:netfs:fsck and init:netfs:fsck is successful.

/dev/emcpowera1         /zoner/emcpowera        ext2    _netdev         1 1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Place entry "/dev/emcpowera1   /zoner/emcpowera   auto  _netdev  1 1" into
2. Reboot server
Actual results:

Error message in /var/log/messages whem mount() performs fsck - "Could not
determine filesystem type for /dev/emcpowera1"

Expected results:

mount:fsck should not attempt a _netdev device at this time. It seems to do it
because the fstype is auto. If I change it to ext2, it will ignore the device
because of the _netdev option. Parsing for auto should also include option
_netdev in the logic so this error does not occur.

Additional info:
Reference BZ #169403

Comment 1 Karel Zak 2006-03-15 22:02:12 UTC
This is really a fsck bug. The fsck command always tries to determine real
filesystem type before fs_opts checks. I think it's bad logic. There should be
fs_opts test __before__ fs_type tests.

Comment 2 Andrius Benokraitis 2006-03-22 22:18:18 UTC
Wayne, this needs an issue tracker, with reference to this bugzilla. So far this
has not been on anyone's radar at RH for inclusion into an Update.

Comment 3 Karel Zak 2006-03-23 21:28:41 UTC
Wayne, you're right that fsck tries open the device, but the message "Could not
determine filesystem type" is from RHEL3 fsck. 

Changing RHEL4 -> RHEL3.

Comment 8 Wayne Berthiaume 2006-03-24 14:37:11 UTC
Hi Karel.

    My bad. You are correct. I was hastily creating this BZ as an update to the 
previous BZ. It is a RHEL 3.0 bug. If I see the same issue in RHEL 4.0 I'll 
generate a seperate BZ.


Comment 17 Bob Johnson 2006-04-11 16:09:31 UTC
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.

Comment 29 Hari Kannan 2006-06-30 14:50:28 UTC
In  test

Comment 30 Red Hat Bugzilla 2006-07-20 14:26:05 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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