Bug 188099 - can't mount iscsi ext3 fs by label.
can't mount iscsi ext3 fs by label.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux (Show other bugs)
4.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks: 176344
  Show dependency treegraph
 
Reported: 2006-04-05 20:52 EDT by JB Segal
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2007-0235
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:18:24 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)

  None (edit)
Description JB Segal 2006-04-05 20:52:43 EDT
Description of problem:
Using e2label to label an ext3fs on an iscsi LUN and then trying to mount by
that lable fails.

Version-Release number of selected component (if applicable):
(I have no idea if this is actually an e2fs problem or an isci-initiator-utils
issue, or something else entirely.)
e2fsprogs-1.35-12.3.EL4
iscsi-initiator-utils-4.0.3.0-3
(System as a whole just updated to RHEL4u3 a few hours ago.)

How reproducible:
Very

Steps to Reproduce:
1. #e2label /dev/sdb iscsi-jfk0

2.# e2label /dev/sdb
iscsi-jfk0

3.# mount -L iscsi-jfk0
  
Actual results:
mount: no such partition found

(or, from an fstab entry of 
LABEL=iscsi-jfk0        /netapp/iscsi/jfk0              ext3    defaults,_netdev
        1 2
'mount -a' gives
[root@jfk /]# mount -a
mount: special device LABEL=iscsi-jfk0 does not exist

Expected results:
A mounted filesystem

Additional info:
Comment 1 Thomas Woerner 2006-04-06 05:53:38 EDT
Is '/sbin/findfs LABEL=iscsi-jfk0' working for you?
Comment 2 JB Segal 2006-04-06 11:10:16 EDT
Seems so, yes:
# /sbin/findfs LABEL=iscsi-jfk0
/dev/sdb

(I'll have to switch testing to a different box for anything involving
mounts/unmounts, as this is a production box that's hard to limit access to... 
So let's try the same things on my test box right now:
[root@comfort ~]# e2label /dev/sdc1 test1
[root@comfort ~]# e2label /dev/sdc1
test1
[root@comfort ~]# /sbin/findfs LABEL=test1
/dev/sdc1
[root@comfort ~]# mount -L test1 /netapp/iscsi/jfktest/1
[root@comfort ~]# mount
 . . .
/dev/sdc1 on /netapp/iscsi/jfktest/1 type ext3 (rw)

 { Oh My! I have a theory here... I'll expand at the end of this comment }

[root@comfort ~]# umount /netapp/iscsi/jfktest/1
 { I go and edit fstab ... }
[root@comfort ~]# grep jfktest /etc/fstab
LABEL=test1     /netapp/iscsi/jfktest/1         ext3    defaults,_netdev       1 2
[root@comfort ~]# mount -av
 . . .
/dev/sdc1 on /netapp/iscsi/jfktest/1 type ext3 (rw,_netdev)


So, my theory is that the important difference is:
/dev/sdc1 (a labeled sub-partition of the iSCSI LUN/'device') works.
/dev/sdb (A filesystem created using the whole LUN/'device' - which mkfs
confirmed I meant to do, and I did.) does NOT work.

Does that make any sense? If it's the case, I still think it's a bug that needs
to be fixed - or at the very least documented, but at least it's something I can
work around (on future systems) until it's fixed.
Comment 3 JB Segal 2006-04-06 11:28:44 EDT
Yeah, I think the device vs partition thing is the right direction:

[root@comfort jfk0]# e2label /dev/sdb test_label
[root@comfort jfk0]# cd ..
[root@comfort iscsi]# umount /netapp/iscsi/jfk0/
[root@comfort iscsi]# mount -L test_label !$
mount -L test_label /netapp/iscsi/jfk0/
mount: no such partition found
[root@comfort iscsi]# findfs LABEL=test_label
/dev/sdb
Comment 4 Thomas Woerner 2006-04-10 05:36:25 EDT
This is no e2fsprogs problem, then.

Assigning to util-linux which provides /bin/mount.
Comment 5 JB Segal 2006-06-20 14:52:08 EDT
This is actually a reasonably high-priority issue, as device id is not
guaranteed for iSCSI LUNs and so, should my system reboot, I have no guarantee
it will come back up correctly without manual intervention and perhaps
significant downtime.
Comment 6 Karel Zak 2006-06-21 04:49:15 EDT
Hmm.. the mount command in RHEL4 checks partitions only (/dev/name[0-9]*). It
seems like a bug. Thanks for your report.
Comment 7 JB Segal 2006-06-21 12:16:39 EDT
Oh, I know it's a bug. :)
I was just hoping to get the priority raised - and thus the time-to-resolution
hopefully lowered. Of course, I can do that myself, and if someone lowers it
again, I'll complain. It's all good.
Comment 8 RHEL Product and Program Management 2006-08-18 12:18:17 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 11 Bryn M. Reeves 2007-01-19 14:49:41 EST
Regarding the suggestions in comment #3 that this should be documented - there
is already a reference to this type of problem in the RHEL4 release notes:

"Red Hat requires that all block devices be initialized with a valid partition
table, even if there is a single partition encompassing the entire device. This
requirement exists to prevent potential problems caused by erroneous or
unintended partition tables on the device."

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/

The easy work around for this until mount supports labels for whole disks is to
use just such a partition table - I use these on iSCSI test boxes here for GFS &
cluster testing and it works fine.
Comment 16 Red Hat Bugzilla 2007-05-01 13:18:24 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/RHSA-2007-0235.html

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