Created attachment 682928 [details]
File: anaconda-tb

Created attachment 682929 [details]
File: anaconda.log

Created attachment 682930 [details]
File: environ

Created attachment 682931 [details]
File: ifcfg.log

Created attachment 682932 [details]
File: packaging.log

Created attachment 682933 [details]
File: program.log

Created attachment 682934 [details]
File: storage.log

Created attachment 682935 [details]
File: syslog

Did you create this USB stick yourself? This does look like a bug, but you should be able to work around it by using dd to write the iso to a USB stick and install from that.

I face the same issue on Fedora 19 :

1) boot from USB disk, via grub, to the F19 vmlinuz & initrd, with a repo=hd:LABEL=bootstuff:/isos/f19/

That /isos/f19/ folder contains the DVD.

2) Then select the installation drive and go to custom installation layout. select a partition, and watch the crash

Reproduced 4 times out of 4 attempts.



It is possible to work around it, I agree, but my environment is to choose what I want to install from a collection of isos on that disk. a dd image would help me for this time, but not on the long run.

Note : 
On my side : yes, I created that USB disk myself. That was working very fine for at least F15 -> F17.

Created attachment 775961 [details]
F19 64 bit similar crash

Please attach logs as individual text/plain attachments, not zips or tarballs.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Re-opening : Issue still appears on Fedora 20.

Issue is that there are 2 loopback references to the ISO /run/install/isodir/f20-64/Fedora-20-x86_64-DVD.iso.

`losetup -j /run/install/isodir/f20-64/Fedora-20-x86_64-DVD.iso` returns 2 entries :


/dev/loop0 /run/install/repo iso9660 ro,relatime 0 0
/dev/loop4 /run/install/source iso9660 ro,relatime 0 0

This lead to an exception in loop.py :

def get_loop_name(path):
    args = ["-j", path]
    buf = losetup(args, capture=True)
    if len(buf.splitlines()) > 1:
        # there should never be more than one loop device listed
        raise LoopError("multiple loops associated with %s" % path)

Created attachment 880212 [details]
Anaconda backtrace on F20

=> From the source, it it appears that "there should never be more than one loop device listed", I suspect the loop0 is created by dracut[*]. I am unsure yet who is creating loop4, but it actually may be something from the dracut modules.

* : 
- loop1 is squashfs.img and loop2 is rootfs (found in squashfs.img), thus it was logically created prior to starting anaconda

OK ... I bypassed the incident by manually removing the second loop and replaced it by a symlink from the terminal screen :

umount /run/install/source
rmdir /run/install/source
cd /run/install
ln -s repo /run/install/source

I got my inspiration from the initrd's /lib/dracut/hooks/pre-trigger/50-repo-genrules.sh, so I thought I could do the same :
---8<---
case "$root" in
[...]
  anaconda-auto-cd)
[...]
    # HACK: anaconda demands that CDROMs be mounted at /mnt/install/source
    ln -s repo /run/install/source
--->8---

Unfortunately, it may affect the repository set up, , and I was forced to use a netinstall... but at least, I successfully installed F20 :)

So, I believe that the first iso mount, and thus the loop0 creation, is coming from the function anaconda_live_root_dir() in initrd's lib/anaconda-lib.sh :

---8<---
repodir="/run/install/repo"
[...]

# try to find a usable runtime image from the repo mounted at $mnt.
# if successful, move the mount(s) to $repodir/$isodir.
anaconda_live_root_dir() {
    local img="" iso="" srcdir="" mnt="$1" path="$2"; shift 2
    img=$(find_runtime $mnt/$path)
    if [ -n "$img" ]; then
        info "anaconda: found $img"
        [ "$mnt" = "$repodir" ] || { mount --make-rprivate /; mount --move $mnt $isodir; }
        anaconda_auto_updates $repodir/$path/images
    else
        if [ "${path%.iso}" != "$path" ]; then
            iso=$path
            path=${path%/*.iso}
        else
            iso=$(find_iso $mnt/$path)
        fi
        [ -n "$iso" ] || { warn "no suitable images"; return 1; }
        info "anaconda: found $iso"
        mount --make-rprivate /
        mount --move $mnt $isodir
        iso=${isodir}/${iso#$mnt}
        mount -o loop,ro $iso $repodir                                             <== There!
        img=$(find_runtime $repodir) || { warn "$iso has no suitable runtime"; }
        anaconda_auto_updates $isodir/$path/images
    fi
[...]
}
--->8---

=> I still have not managed to trace back where is the 2nd loop (loop4) is coming from, but my understanding is that the second one should be somehow avoided to match with the python Anaconda requirement of 1 loop per device only.

=> note : I have setup a raw LV that is self sufficient to reproduce the incident : it contains grub, F20's vmlinuz/initrd, F20's ISO, and an encrypted PV that will force anaconda to hit the problematic code path and crash when we unlock the PV

The second mount is coming from the python Anaconda itself :

From lib64/python2.7/site-packages/pyanaconda/constants.py
MOUNT_DIR = "/mnt/install"
INSTALL_TREE = MOUNT_DIR + "/source"

lib64/python2.7/site-packages/pyanaconda/packaging/__init__.py :

class PackagePayload(Payload):
    """ A PackagePayload installs a set of packages onto the target system. """
[...]
    def _setupMedia(self, device):
        method = self.data.method
        if method.method == "harddrive":
            self._setupDevice(device, mountpoint=ISO_DIR)

            # check for ISO images in the newly mounted dir
            path = ISO_DIR
            if method.dir:
                path = os.path.normpath("%s/%s" % (path, method.dir))

            # XXX it would be nice to streamline this when we're just setting
            #     things back up after storage activation instead of having to
            #     pretend we don't already know which ISO image we're going to
            #     use
            image = findFirstIsoImage(path)
            if not image:
                device.teardown(recursive=True)
                raise PayloadSetupError("failed to find valid iso image")

            if path.endswith(".iso"):
                path = os.path.dirname(path)

            # this could already be set up the first time through
            if not os.path.ismount(INSTALL_TREE):
                # mount the ISO on a loop
                image = os.path.normpath("%s/%s" % (path, image))
                mountImage(image, INSTALL_TREE)        <== THERE

lib64/python2.7/site-packages/pyanaconda/image.py :

def mountImage(isodir, tree):

    while True:
        if os.path.isfile(isodir):
            image = isodir
        else:
            image = findFirstIsoImage(isodir)  
            [...]

            image = os.path.normpath("%s/%s" % (isodir, image))

        try:
            blivet.util.mount(image, tree, fstype = 'iso9660', options="ro") <== THERE



lib/python2.7/site-packages/blivet/util.py :

def mount(device, mountpoint, fstype, options=None):
    [...]
    argv = ["mount", "-t", fstype, "-o", options, device, mountpoint]



=> So the double-mounting is apparently coming from python Anaconda itself (the first iso mount is from dracut, and python Anaconda mounts the second one).

=>  _setupMedia() should probably check if the ISO has been already mounted elsewhere, and if so, maybe create some symlink or something ?

This should be working fine with F21.

(In reply to bcl from comment #21)
> This should be working fine with F21.

Hi,
 Could u double check the python-blivet in F21?
I watched the similiar double mount error in F21 ppc64 installtion.
And I checked that the commit https://github.com/rhinstaller/blivet/commit/d63c967affc5a6b88c355d6b24089d68080f02e2 had been included in F21 yet

(In reply to hejia from comment #22)
> (In reply to bcl from comment #21)
> > This should be working fine with F21.
> 
> Hi,
>  Could u double check the python-blivet in F21?
> I watched the similiar double mount error in F21 ppc64 installtion.
> And I checked that the commit
> https://github.com/rhinstaller/blivet/commit/
> d63c967affc5a6b88c355d6b24089d68080f02e2 had been included in F21 yet

sorry. s/had been/had not been/

Sorry, I was mistaken. This will be fixed in F22.

On my side, F19 and F20 were crashing, but I didn't face any issue with F21 using similar method. So it has been working fine for me, at least (x86_64).