Bug 127072

Summary:	anaconda's mountLoopback doesn't handle vfat driver disks
Product:	Red Hat Enterprise Linux 3	Reporter:	Charles Duffy <charlesduffy>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	barryn, kloostec
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-04-24 18:01:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Charles Duffy 2004-07-01 15:41:54 UTC

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 17:25:55 UTC

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 17:34:15 UTC

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 17:44:57 UTC

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 17:48:32 UTC

Oops -- didn't mean to close it. Sorry 'bout that.

Comment 5 Jeremy Katz 2004-07-06 22:17:10 UTC

Fixed in CVS

Comment 6 Jeremy Katz 2005-08-08 22:10:33 UTC

*** Bug 165251 has been marked as a duplicate of this bug. ***

Comment 7 Jeremy Katz 2006-04-24 18:01:39 UTC

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.