Bug 185534 - [EMC RHEL3 U8 bug] init:mount:fsck fails when fstype is set to auto on _netdev device in /etc/fstab
[EMC RHEL3 U8 bug] init:mount:fsck fails when fstype is set to auto on _netde...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Jay Turner
Depends On:
Blocks: RHEL3U8CanFix 184383
  Show dependency treegraph
Reported: 2006-03-15 11:38 EST by Wayne Berthiaume
Modified: 2015-01-07 19:12 EST (History)
10 users (show)

See Also:
Fixed In Version: RHBA-2006-0400
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-20 10:26:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Wayne Berthiaume 2006-03-15 11:38:00 EST
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 17:02:12 EST
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 17:18:18 EST
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 16:28:41 EST
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 09:37:11 EST
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 12:09:31 EDT
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 10:50:28 EDT
In  test
Comment 30 Red Hat Bugzilla 2006-07-20 10:26:05 EDT
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.