Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 149149 - fsck fails - no devices node - fcpconf.sh does not verify if device nodes are created
fsck fails - no devices node - fcpconf.sh does not verify if device nodes are...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: s390utils (Show other bugs)
s390 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Horák
Depends On:
  Show dependency treegraph
Reported: 2005-02-19 09:25 EST by Oliver Paukstadt
Modified: 2010-03-18 12:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-18 12:16:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
console output (1.37 KB, text/plain)
2005-02-19 09:25 EST, Oliver Paukstadt
no flags Details

  None (edit)
Description Oliver Paukstadt 2005-02-19 09:25:17 EST
Description of problem:
/sbin/zfcpconf.sh does not verify if the device nodes are created. The fsck
required in fstab on that activated devices fails.
Adding a "sleep 10" at the end of zfcpconf.sh solves this problem on my systems.

Version-Release number of selected component (if applicable):
(on s390x as well)

How reproducible:
Boot from dasd, add zfcp devices using /etc/zfcp.conf and add the devices into
fstab with checking required.

Actual results:
fsck.ext3: No such file or directory while trying to open /dev/sda1

Expected results:
successful checking of device

Additional info:
I added a "sleep 10" at the end of zfcpconf.sh and this work around the problem
on my system. Values of 3 or 5 seconds were not enough.
For me it looks like udev is to slow to create the device nodes (maybe our
storage has some impact on this as well).
Only waiting for the creation of /dev/sda1 is not a solution as well, because
this would hang the system for ever if the device is not available at all. Maybe
a further analysis of the sysfs subtrees is required before returning from
Comment 1 Oliver Paukstadt 2005-02-19 09:25:18 EST
Created attachment 111229 [details]
console output
Comment 2 Phil Knirsch 2005-02-21 13:43:58 EST
Ok, i just talked with our udev guru here, and it's most likely an udev problem.

I'm reassigning it to udev for now.

Read ya, Phil
Comment 3 Harald Hoyer 2005-02-21 13:53:38 EST
which version of udev is installed?
Comment 4 Oliver Paukstadt 2005-02-21 14:06:24 EST
Comment 6 Dan Horák 2008-09-23 04:40:18 EDT
I think I have found a solution in the sysload package (http://www.ibm.com/developerworks/linux/linux390/sysload.html) - they use the udevsettle utility (or udevstart when it is not available) - udevsettle watches the udev event queue and exits when all events are processed, udevstart walks through /sys and creates the nodes for the devices it founds.
Comment 7 Ondrej Vasik 2010-03-18 12:16:16 EDT
As RHEL-4.9 is last update for RHEL-4 and it is not suitable for new features
and should address only security, performance and critical issues, I'm closing
that bugzilla WONTFIX. If this functionality is still missing in RHEL-5, feel
free to clone that bugzilla against it.

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