This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 439642 - anaconda refuses to boot from NFS mounted images
anaconda refuses to boot from NFS mounted images
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-29 19:01 EDT by Michal Jaegermann
Modified: 2008-04-02 16:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-31 10:02:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-03-29 19:01:38 EDT
Description of problem:

Attempts to boot, both in a "rescue" mode and for an installation,
with boot images provided on NFS server end up with "The Fedora
installation in that directory does not seem to match your boot
media".

Looking at text consoles I see the following:

mount nfs path ......  (correct)
can access /mnt/source/images/stage2.img
trying to mount CD device /dev/sr0 on /mnt/stage2    (!????)
.....
not the right one
going to do nfsGetSetup

and nothing else follows.  On the next screen one can find
at the bottom:
<4>ISOFS: Unable to identify CD-ROM format.
<4>VFS: Can't find an ext2 filesystem on dev loop0.

Attempts to mount CD device /dev/sr0 obviously have to fail.
There is no media in that drive (and the drive also does not
have to be present).

Version-Release number of selected component (if applicable):
Images from 20080329

How reproducible:
always
Comment 1 Jerry Vonau 2008-03-30 14:07:10 EDT
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.



Comment 2 Chris Lumens 2008-03-31 10:02:04 EDT
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.
Comment 3 Michal Jaegermann 2008-04-02 15:54:22 EDT
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.
Comment 4 Chris Lumens 2008-04-02 16:34:58 EDT
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.
Comment 5 Michal Jaegermann 2008-04-02 16:54:33 EDT
> 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.



Note You need to log in before you can comment on or make changes to this bug.