Bug 127072 - anaconda's mountLoopback doesn't handle vfat driver disks
anaconda's mountLoopback doesn't handle vfat driver disks
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
: 165251 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-01 11:41 EDT by Charles Duffy
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-24 14:01:39 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 Charles Duffy 2004-07-01 11:41:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040614 Netscape 7/0.8

Description of problem:
When using "driverdisk
--source=nfs:servername:/path/to/driverdisk.img", Anaconda fails to
use the drivers if the NFS share doesn't provide write access to
driverdisk.img.

loop6 is succesfully associated with driverdisk.img but the mount
itself fails. If I log in on tty2 and investigate, I find that "mount
/dev/loop6 /tmp/drivers" fails, and "mount -o ro /dev/loop6
/tmp/drivers" succeeds. This leads me to believe that the issue is
caused by the driver disk being mounted read-write; however, only
read-only access should be needed (and read-write is harmful as it
causes the mount to fail outright in the case of a read-only NFS volume).

Version-Release number of selected component (if applicable):
anaconda-9.1.2-2.RHEL

How reproducible:
Always

Steps to Reproduce:
1. Configure an NFS server with a read-only share hosting an Anaconda
driver disk.
2. Configure a Kickstart file which contains a directive akin to
"driverdisk --source=nfs:servername:/path/to/driverdisk.img".
3. Boot a system with the relevant kickstart file


Actual Results:  The NFS server is mounted, but the driver disk's
contents are not loaded. A message on tty3 indicates that the mount
failed.

Expected Results:  The drivers from the disk should have been loaded
by Anaconda.
Comment 1 Charles Duffy 2004-07-01 13:25:55 EDT
After further investigation, found my initial diagnosis to be mistaken
-- mountLoopback *does* mount partitions read-only by default. More to
follow.
Comment 2 Charles Duffy 2004-07-01 13:34:15 EDT
transferring <url> to a fd
mntloop loop6 on /tmp/drivers as /tmp/dd.img fd is 23
failed to mount loop: Invalid argument

However, I see a likely cause: The image is vfat, but mountLoopback
tries iso9660, ext2 and cramfs. Attempting a cramfs image instead to
see if this helps.
Comment 3 Charles Duffy 2004-07-01 13:44:57 EDT
Use of a vfat-based image was indeed the cause -- my initial
assessment was invalid. (I'm inclined to argue that lack of vfat
support in anaconda is still a bug; since the BOOT kernel supports
vfat, some driver disks have used this format, and dkms's mkdriverdisk
generates images in it, there's no excuse for mountLoopback not to try
it).
Comment 4 Charles Duffy 2004-07-01 13:48:32 EDT
Oops -- didn't mean to close it. Sorry 'bout that.
Comment 5 Jeremy Katz 2004-07-06 18:17:10 EDT
Fixed in CVS
Comment 6 Jeremy Katz 2005-08-08 18:10:33 EDT
*** Bug 165251 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Katz 2006-04-24 14:01:39 EDT
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.

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