Bug 148764 - [PATCH] Wrong handling of network attached block devices
[PATCH] Wrong handling of network attached block devices
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks: 156320 156322
  Show dependency treegraph
 
Reported: 2005-02-15 08:43 EST by Bastien Nocera
Modified: 2014-03-16 22:52 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2005-607
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 11:46:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
netfs.patch (3.15 KB, patch)
2005-02-15 08:44 EST, Bastien Nocera
no flags Details | Diff
Updated patch to handle lvm/fsck for _netdev devices (865 bytes, patch)
2005-02-24 10:32 EST, AJ Lewis
no flags Details | Diff
Initial stab at netdev initscript (1.23 KB, text/plain)
2005-06-13 17:19 EDT, AJ Lewis
no flags Details
Initial stab at netdev initscript (1.22 KB, text/plain)
2005-06-13 17:23 EDT, AJ Lewis
no flags Details
same fix, but for RHEL 3 (3.30 KB, patch)
2005-07-13 16:12 EDT, Bill Nottingham
no flags Details | Diff
patches initscripts-7.31.22.EL-2 netfs, includes shutdown fixes, too (3.47 KB, patch)
2005-09-12 22:23 EDT, Josh Hildebrand
no flags Details | Diff
netfs.patch (470 bytes, patch)
2006-08-08 11:36 EDT, Josh Hildebrand
no flags Details | Diff

  None (edit)
Description Bastien Nocera 2005-02-15 08:43:00 EST
Description of problem:
netfs doesn't mount network attached block devices

Version-Release number of selected component (if applicable):
7.31.18.EL.1

Patch attached below
Comment 1 Bastien Nocera 2005-02-15 08:44:38 EST
Created attachment 111084 [details]
netfs.patch

Patch from Ian Amess <ian.amess@o2.com> with comments about each change
Comment 2 Bill Nottingham 2005-02-15 12:44:41 EST

*** This bug has been marked as a duplicate of 147610 ***
Comment 4 Bastien Nocera 2005-02-18 09:58:17 EST
The patch attached to this bug (bug
148764) contains more fixes than just the one that it was duped
against. In particular, the activating/deactivating LVM volume groups
on _netdev devices, and the fact that fsck tries to run on _netdev
devices.

The current code causes problems on startup for the initialisation of
iSCSI initiators connected to a NetApp, with LVM volume groups on there.
Comment 5 Bill Nottingham 2005-02-18 16:54:15 EST
netdev filesystems shouldn't be marked for check in fstab; that would
be a local config error.
Comment 6 Bill Nottingham 2005-02-22 11:49:23 EST
LVM and fsck should probably be tracked when the block devices are
created (in either the iscsi or nbd init scripts.)
Comment 9 AJ Lewis 2005-02-24 10:32:07 EST
Created attachment 111379 [details]
Updated patch to handle lvm/fsck for _netdev devices

This patch adds lvm activation and fsck support for _netdev devices.  It is
basically a reworking of the patch from comment #1, and obsoletes it.  The
reason I am proposing to do this in the netfs script instead of the individual
network block device initscripts is that this keeps it all in one place, and
anyone adding a new nbd doesn't need to reimplement all that checking.

The other thing I was thinking is we could add a netdev initscript that handles
network block device setup, and leave the mounting/unmounting to netfs -
thoughts?
Comment 10 Bill Nottingham 2005-02-25 13:19:15 EST
As an aside, shouldn't the fsck line just be -t opts=_netdev?

The reason I don't like it in netfs is because it's a separate
fsck/lvm/vgchange etc invocation on every boot when most users don't
need it; hence, it's better used when those devices are actually in use.
Comment 11 Bill Nottingham 2005-04-28 21:47:15 EDT
(In reply to comment #9)
>
> The other thing I was thinking is we could add a netdev initscript that handles
> network block device setup, and leave the mounting/unmounting to netfs -
> thoughts?

This seems to be the simplest solution, in my opinion.
Comment 17 AJ Lewis 2005-06-13 17:19:24 EDT
Created attachment 115377 [details]
Initial stab at netdev initscript

Here is an initial stab at a netdev initscript.  It simply looks at /etc/fstab
to see if there are any _netdev entries that are to be automounted, and if
there are runs vgscan && vgchange -ay (if lvm is present) and fscks the _netdev
filesystems.  It does nothing on the stop condition currently.
Comment 18 AJ Lewis 2005-06-13 17:23:11 EDT
Created attachment 115379 [details]
Initial stab at netdev initscript

Oops - had an echo in the wrong spot.  Updated netdev script with fix.
Comment 19 Bill Nottingham 2005-06-23 17:28:57 EDT
What would you like to do when fsck fails? :)
Comment 20 AJ Lewis 2005-06-24 10:30:14 EDT
Good question.  Since this isn't in the netfs script, we can't really prevent it
from being mounted, which is what I'd prefer.  I could do what rc.sysinit does
and drop the user into a shell, then reboot afterwwards, but I dunno that that's
a good idea at that point in the boot process.  What do you think?
Comment 21 Bill Nottingham 2005-06-24 13:16:34 EDT
Well...

After more consideration, I suppose netfs is ok for this bit, as long as the
fsck, lvm, etc are only conditionalized on netdev devices actually being in use.

As to what to do when fsck fails:

- Normally, rebooting after manual intervention on a failed fsck is done because
it's some sort of critical system filesystem. Is that normally the case for
filesystems of this sort?

- Probably the biggest reason why you'd want to reboot after failure is because
you may not have fixed in in the shell, and therefore you don't want to try and
mount it. For this, if fsck failed, we'd probably want to change the mounting to
be -O no_netdev. However, in the case of multiple netdev filesystems where only
one failed fsck, this would cause *all* of them to not get mounted.

I suppose shell then reboot is the safest option, but just slapping 'shutdown -r
now' in the middle of the script seems ugly. :/
Comment 33 Bill Nottingham 2005-07-14 15:22:31 EDT
Merged in 7.31.24.EL-1/7.93.14.EL-1.
Comment 34 Josh Hildebrand 2005-09-12 21:09:09 EDT
I tried the latest patch and it still doesn't work for me.  It looks like it's 
supposed to do a vgscan and then activate them all before trying to mount the 
iscsi LVM luns.  But it didn't work for me.   

When will 7.31.24.EL-1/7.93.14.EL-1 be out?
Where can I find it?

Is this supposed to unmount the VGs, and deactivate the VGs before it stops 
iSCSI during a shutdown?  I don't see the code for that.
Comment 35 Josh Hildebrand 2005-09-12 22:23:21 EDT
Created attachment 118744 [details]
patches initscripts-7.31.22.EL-2 netfs, includes shutdown fixes, too

this one works for me.. the previous one had a bug, or wasn't for my
initscripts version or something.  I also added 3 lines to make it set the
volume groups to inactive, so that iscsi module can stop properly.
Comment 36 Red Hat Bugzilla 2005-09-28 11:55:26 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.

http://rhn.redhat.com/errata/RHBA-2005-606.html
Comment 37 Red Hat Bugzilla 2005-10-05 11:46:41 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.

http://rhn.redhat.com/errata/RHBA-2005-607.html
Comment 38 Josh Hildebrand 2006-08-08 11:36:58 EDT
Created attachment 133796 [details]
netfs.patch

This patch fixes netfs within initscripts-7.31.31.EL-1 to support iscsi devices
in LVM volume groups.
Comment 39 Bill Nottingham 2006-08-08 11:41:19 EDT
We don't normally do vgchange -a n on shutdown - why would you need this?
Comment 40 Josh Hildebrand 2006-08-08 11:45:41 EDT
because the iscsi service cannot stop unless the devices are free.  with the 
VG's active, then the underlying iscsi devices are not free.

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