Red Hat Bugzilla – Bug 103856
NFS install pauses because all loopback devices are in use
Last modified: 2007-11-30 17:06:58 EST
Description of problem:
Installing Taroon Beta 2 on a PowerEdge 7150 server, using NFS pointing at a
directory containing the ISO images for AS (not a directory containing the
extracted files from the ISOs). Choose various package groups, but not
"Everything". Install proceeded quite well, VT3 showed it switching from CD 1
to 2 to 3 to 4 to pick up new discs as expected. However, the install GUI paused
_("The package %s-%s-%s cannot be opened. This is due "
"to a missing file or perhaps a corrupt package. "
"If you are installing from CD media this usually "
"means the CD media is corrupt, or the CD drive is "
"unable to read the media.\n\n"
"Press <return> to try again.") % (h['name'],
prompting for a retry when installing openoffice-i18n-*. This was because all
loopback devices were already in use by the installer, though mount shows only 3
in use. I manually unmounted /tmp/isomedia, but all loopback devices were
*still* in use. I ran 'losetup -d /tmp/loop3' (and repeat for 4-7) trying to
free them up, one succeeded. I was able to manually mount CD 4 by loopback then
to /tmp/isomedia, and the install was able to continue.
Later, when it went to install redhat-release, it needed to switch back to CD 1
to find this, but again was unable to do so. Manually running 'losetup -d
/tmp/loop2' succeeded, and I was able to mount disc1 on /tmp/isomedia, but that
isn't where anaconda is looking for it I guess...
Now, this last part may have to do with my having the AS, ES, and WS CD images
in the same directory. I booted off of AS CD 1, but now it's prompting me for a
WS package. I was able to manually install the redhat-release package it asked
for, but was never able to get it to go past looking for it. I eventually gave
up, manually made a elilo.conf file, and just rebooted...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
To be clear, Dell does not consider this a showstopper.
Having the ISOs for all variants in the same directory is very explicitly not
supported. Only one ISO set per directory, please. Otherwise things are likely
to get confused.
And that probably leads to a case where we unmount but don't free up a loop
device -- I'll check those error paths.
Can you get me the /tmp/anaconda.log and /tmp/syslog from when this happens?
I ran into a more serious form of this problem. I had a directory on my NFS
server with discs 1-4 of Taroon beta 2 for both ia64 and x86_64 (ie 8 total iso
images in the same directory).
I booted off of a disc 1 CD with "linux askmethod. I chose NFS install and
pointed the installer at the directory on the server with the iso images. This
worked fine on x86_64, but on ia64 the installer gets a kernel oops and can't
When I moved the CD images to separate ia64/ and x86_64/ directories, the ia64
installer works fine.
Closing, user error. I moved the 4 install CDs to their own directory and was
able to successfully install. The problem was that I had the AS, ES, and WS CDs
in the same directory.
Should this really be closed? I agree that the underlying cause is user error,
but oopsing in the installer with no feedback as to why is definitely not good