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.
After further investigation, found my initial diagnosis to be mistaken -- mountLoopback *does* mount partitions read-only by default. More to follow.
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.
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).
Oops -- didn't mean to close it. Sorry 'bout that.
Fixed in CVS
*** Bug 165251 has been marked as a duplicate of this bug. ***
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.