Bug 439642

I'm seeing the same type of thing with 20080330 images. 
can access /mnt/source/images/stage2.img
failed to mount loopback device /dev/loop0 on /mnt/runtime as /tmp/stage2.img:
No such file or directory

And here is the issue, stage2dir is cleared before stage2 is mounted:

            stage = NFS_STAGE_NFS;

            if (!doPwMount(fullPath, "/mnt/source", "nfs", mountOpts)) {
                if (FL_STAGE2(flags)) {
                    stage2dir = strdup("/mnt/source");
                    tmp = asprintf(&buf, "/mnt/source/%s", strrchr(directory, '/'));
                } else {
                    stage2dir = strdup("/mnt/source/images");
                    buf = strdup("/mnt/source/images/stage2.img");
                }

                winStatus(70, 3, _("Retrieving"), "%s %s...", _("Retrieving"), buf);
                rc = copyFile(buf, "/tmp/stage2.img");
                newtPopWindow();

                free(stage2dir);

                if (!rc) {
                    logMessage(INFO, "can access %s", buf);
                    rc = mountStage2("/tmp/stage2.img", stage2dir);

                    free(buf);

                    if (rc && rc == -1) {
                        foundinvalid = 1;
                        logMessage(WARNING, "not the right one");
                        umount("/mnt/source");
                    } else {
                        stage = NFS_STAGE_DONE;
                        rc = asprintf(&url, "nfs:%s:%s", host, directory);
                        break;
                    }
                } else {


Why stage2 needs to be in /tmp using a filesystem that will never be unmounted
for the duration of the install is beyond me.

Ah, thanks for finding this.  That's what I get for trying to be aggressive
about freeing memory instead of lazy like we usually are.

However, the NFS source could be unmounted during installation.  If there's a
problem with your NFS server before package installation starts, we will attempt
to unmount and prompt you to enter different repo information.  It's good to
have the stage2 grabbed so we're not leaving that mount point busy later on.

I retried with 20080402 images and booting with data on NFS
worked at least in a rescue mode.

I still see in anaconda log:
......
17:27:34 INFO    : going to do nfsGetSetup
17:27:47 INFO    : trying to mount CD device /dev/sr0 on /mnt/stage2
17:27:47 INFO    : mounting nfs path ......
17:27:57 INFO    : can access /mnt/source/images/stage2.img
........

Why this "trying to mount CD device" when anaconda was explicitely told
that we want to use something else?  What if some media would happen to
be there?

Also in anaconda log I collected 109 messages of that kind:

17:27:57 WARNING : Failed to create /etc/selinux/config: Read-only file system

with assorted files and directories below /etc/selinux.  At least
after I got a shell /etc/ looked quite writable.

We always check the CD device to see if there's a stage2 image there as an
optimization.  If found, we use it to prevent ever having to pull the image over
the network.

All those warnings are harmless - just the byproduct of the order we do some
copying in the loader.  They still need to get cleaned up though.

> We always check the CD device to see if there's a stage2 image there
> as an optimization.

It is a rather safe bet that one day somebody will be screwed up
by this ruse because a CD with a wrong stage2.img was forgotten
in a drive with a resulting mysterious refusal to boot. OTOH if
a runtime is loop-mounted from a file on CD, without copying it
first to /tmp, then this should save some memory.