This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 853508 - nfsiso source for stage2 does not work
nfsiso source for stage2 does not work
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
i386 Linux
unspecified Severity high
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
CommonBugs
:
: 862996 (view as bug list)
Depends On:
Blocks: F18Blocker/F18FinalBlocker 824191
  Show dependency treegraph
 
Reported: 2012-08-31 14:53 EDT by Paul Franklin (RHlists)
Modified: 2013-03-12 10:24 EDT (History)
13 users (show)

See Also:
Fixed In Version: anaconda-18.17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-13 09:14:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg output (40.43 KB, text/plain)
2012-08-31 14:53 EDT, Paul Franklin (RHlists)
no flags Details
copy of dracut-state.sh (837 bytes, text/plain)
2012-08-31 14:54 EDT, Paul Franklin (RHlists)
no flags Details
output of journalctl -a (277.35 KB, text/plain)
2012-08-31 14:56 EDT, Paul Franklin (RHlists)
no flags Details
output of journalctl --output=verbose (1.35 MB, text/plain)
2012-08-31 14:58 EDT, Paul Franklin (RHlists)
no flags Details
copy of system.journal (1.61 MB, text/plain)
2012-08-31 14:59 EDT, Paul Franklin (RHlists)
no flags Details
dmesg output from try 178 (40.90 KB, application/octet-stream)
2012-09-21 10:48 EDT, Paul Franklin (RHlists)
no flags Details
journalctl -a output from try 178 (6.03 KB, application/octet-stream)
2012-09-21 10:51 EDT, Paul Franklin (RHlists)
no flags Details
copy of system.journal from try 180 (1.62 MB, application/octet-stream)
2012-09-21 10:58 EDT, Paul Franklin (RHlists)
no flags Details

  None (edit)
Description Paul Franklin (RHlists) 2012-08-31 14:53:12 EDT
Created attachment 608610 [details]
dmesg output

Description of problem:

I am not a Fedora expert so I apologize in advance if I
didn't follow the right form or tell you something you need.

In the last few days I have started to try to do a
PXE-install of the pre-alpha F18, so far with no success.

So I could certainly believe I am doing something wrong.
But it might be your problem too, so I'm filing this bug.

The goal was to use kernel.org for the repo but since my
internet connection is slow I downloaded the ISO image at
the library and then extracted things from it, here.  (It
takes me an hour to download squashfs.img for instance.)

So here is how I have things set up.

Here is what "ls -lFR /home/me/F/F18/20120828" says:

/home/me/F/F18/20120828:
total 302416
-r--r--r--    1 me me  277872640 Aug 30 12:04 201208281342_boot.iso
drwxr-xr-x    2 me me      4096 Aug 31 10:56 LiveOS/
-r--r--r--    1 me me  26246456 Aug 28 06:42 initrd.img
-r--r--r--    1 me me   5223184 Aug 22 07:43 vmlinuz

/home/me/F/F18/20120828/LiveOS:
total 208756
-r--r--r--    1 me me  213553152 Aug 28 06:40 squashfs.img

Here is part of my /tftpboot/pxe/pxelinux.cfg/default file:

# 164. Fedora 18 (to net-install pre-alpha "development" F18, from kernel.org)
label 164
  kernel F18/20120828/vmlinuz
  append initrd=F18/20120828/initrd.img ramdisk_size=10000 repo=http://mirrors.kernel.org/fedora/development/18/i386/os ip=dhcp noipv6 stage2=nfs:proto=udp:172.23.103.50:/home/me/F/F18/20120828 loglevel=debug keymap=us lang=en_US.UTF-8 selinux=0 nodmraid rd.debug

But as I mentioned it hasn't worked yet.

It is not clear to me what I can provide to help you, so I
have attached some files which may help, copies of two files
and the outputs from a few commands.

Thanks.


Version-Release number of selected component (if applicable):
see attachments

How reproducible:
always

Steps to Reproduce:
1. try to install via PXE
2.
3.
  
Actual results:
won't boot, get emergency shell

Expected results:
will boot installer

Additional info:
Comment 1 Paul Franklin (RHlists) 2012-08-31 14:54:51 EDT
Created attachment 608611 [details]
copy of dracut-state.sh
Comment 2 Paul Franklin (RHlists) 2012-08-31 14:56:23 EDT
Created attachment 608612 [details]
output of journalctl -a
Comment 3 Paul Franklin (RHlists) 2012-08-31 14:58:04 EDT
Created attachment 608615 [details]
output of journalctl --output=verbose
Comment 4 Paul Franklin (RHlists) 2012-08-31 14:59:40 EDT
Created attachment 608616 [details]
copy of system.journal
Comment 5 Will Woods 2012-09-04 09:50:57 EDT
Assuming your images aren't the very latest, this is very likely the same problem as bug 849672.

Could you fetch a copy of TC5 (or later) test images and see if that works? You should be able to get the images from a link off this page:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test



By the way: if you're using a DVD image on NFS you shouldn't need to extract the squashfs.img. The anaconda code in initrd.img should be smart enough to mount the .iso and use the squashfs image out of there. It should work if you pass the directory name or the full path to the iso itself, e.g.:

  inst.{repo,stage2}=nfs:...:/path/containing/iso/
  inst.{repo,stage2}=nfs:...:/path/containing/iso/fedora-XXX.iso

That should save you a little time and trouble in the future - although I'd suggest you wait until you've confirmed that the TC5 image works as expected with the setup you're already using. Changing multiple variables at once isn't great science, after all..
Comment 6 Paul Franklin (RHlists) 2012-09-04 20:23:08 EDT
Thank you for your response.

I don't really have a lot of time right now, since I am
leaving town tomorrow for about a week.  (While I hope to be
able to read my email, I'll only be taking a laptop along.)

Nonetheless, since your request (that I try TC5) was so
specific, I went to the library today and tried to download
it.  It started all right, with a report (from the stupid
WXP browser) that it should only take an hour and forty
minutes.  But as it went along it got slower and slower and
when I finally aborted it I was more than halfway through my
allotted two hours and only forty percent of it was done.

So if it is somehow absolutely positively necessary to you
that I download that DVD and then try to install it, when I
get back I will set up an rsync download (here, not at the
library, I can't run a shell there,) and wait a few days.

In case the test I performed before is good enough this time
too, I downloaded today's version of the boot.iso file from
http://mirrors.kernel.org/fedora/development/18/i386/os/images
(and then renamed it to 201209040700_boot.iso).  I then
looped it and extracted vmlinuz and initrd.img as usual.
Then put copies of them in my /tftpboot/pxe/F18/20120904.

Here is what "ls -lFR /home/me/F/F18/20120904" says:

/home/me/F/F18/20120904:
total 303256
-r--r--r--    1 me me  278921216 Sep  4 07:00 201209040700_boot.iso
-r--r--r--    1 me me  26062060 Sep  4 06:59 initrd.img
-r--r--r--    1 me me   5223184 Aug 22 07:43 vmlinuz

(I have no way to know whether those two are identical to
the ones in the full DVD image you wanted me to download.  I
assume so but of course you will know for sure.  I doubt
that your suggestion of outdated files is the problem, since
the 8/28 attempt I documented in this bug was merely one of
my attempts.  I tried the 1 September one too, say.  But I
tried today's anyway, just in case it matters.  It didn't.)

I have tried lots of things, including what I reported in
this report earlier.  Nothing has worked.  Whether or not I
unpacked the squashfs.img has never mattered.  I just don't
feel like documenting every failed attempt.

Here is part of my /tftpboot/pxe/pxelinux.cfg/default file:

label 170
  kernel F18/20120904/vmlinuz
  append initrd=F18/20120904/initrd.img ramdisk_size=10000 repo=nfs:proto=udp:172.23.103.50:/home/me/F/F18/20120904/ ip=dhcp noipv6 loglevel=debug keymap=us lang=en_US.UTF-8 selinux=0 nodmraid

label 171
  kernel F18/20120904/vmlinuz
  append initrd=F18/20120904/initrd.img ramdisk_size=10000 repo=http://mirrors.kernel.org/fedora/development/18/i386/os ip=dhcp noipv6 stage2=nfs:proto=udp:172.23.103.50:/home/me/F/F18/20120904/ loglevel=debug keymap=us lang=en_US.UTF-8 selinux=0 nodmraid

But as I mentioned, neither attempt worked.

The error typeout I saw did not seem to be different from
the ones I attached earlier so I am not going to attach any
today.  (As I mentioned I'm short on time.)  My guess is
that the necessary clues (whatever they are) are in the
files I attached earlier.  Somewhere.

If you still have no luck in discovering the problem, I will
be happy to assist you in finding it, when I return from my
trip.  (Even downloading whatever full DVD image you tell
me to, if you do insist upon it.)

I would request that in such a case you tell me the specific
PXE kernel arguments you want me to use (and I will modify
them for my environment) -- remembering that I do not want
to do a full net-install, I want a local squashfs.img or
boot.iso, etc.  (Eventually, of course I'll download the
full F18 DVD, the final one.)  Please tell me whatever files
(or command output) you then want me to attach, next time.

Thanks.
Comment 7 Paul Franklin (RHlists) 2012-09-06 10:19:27 EDT
It will be interesting to see if my bug is fixed when this one is:
https://bugzilla.redhat.com/show_bug.cgi?id=854180
Comment 8 Jesse Keating 2012-09-06 19:39:56 EDT
This bug may be relevant to 855170
Comment 9 Paul Franklin (RHlists) 2012-09-12 11:06:04 EDT
Can anybody tell me when the boot.iso file (which I mentioned
in comment #6 above) will have an initrd.img with the updated
dracut-023-39.git20120910.fc18 in it (as mentioned in 855170)?

Today's (12 Sept) seems to still have the old dracut-023-21.

Thanks.
Comment 10 Jesse Keating 2012-09-12 15:49:45 EDT
Probably after the Alpha is released.  This is not a alpha blocker issue.  When https://admin.fedoraproject.org/updates/FEDORA-2012-13731/dracut-023-39.git20120910.fc18  gets pushed to stable, the next day's compose should make use of it.
Comment 11 Paul Franklin (RHlists) 2012-09-21 10:48:09 EDT
Created attachment 615474 [details]
dmesg output from try 178
Comment 12 Paul Franklin (RHlists) 2012-09-21 10:51:27 EDT
Created attachment 615475 [details]
journalctl -a output from try 178
Comment 13 Paul Franklin (RHlists) 2012-09-21 10:58:19 EDT
Created attachment 615476 [details]
copy of system.journal from try 180
Comment 14 Paul Franklin (RHlists) 2012-09-21 11:00:42 EDT
Thank you for your response.  I especially appreciated the
pointer, which enabled me to follow that dracut's progress.

Unfortunately my tentative assumption is that is doesn't fix
my problem (whatever it may be).

To test it I downloaded 9/19's version of boot.iso from
http://mirrors.kernel.org/fedora/development/18/i386/os/images
(and then renamed it to 20120919_boot.iso).  I then looped
it and extracted vmlinuz and initrd.img as usual.  Then put
copies of them in my /tftpboot/pxe/F18/20120919.

Here is what "ls -lFR /home/me/F/F18/20120919" says:

/home/me/F/F18/20120904:
total 305780
-r--r--r--    1 me me  281018368 Sep 19 07:21 20120919_boot.iso
-r--r--r--    1 me me  26547024 Sep 19 07:19 initrd.img
-r--r--r--    1 me me   5223184 Aug 22 07:43 vmlinuz

Here is part of my /tftpboot/pxe/pxelinux.cfg/default file:

label 178
  kernel F18/20120919/vmlinuz
  append initrd=F18/20120919/initrd.img ramdisk_size=10000 repo=nfs:proto=udp:172.23.103.50:/home/me/F/F18/20120919/ ip=dhcp noipv6 loglevel=debug keymap=us lang=en_US.UTF-8 selinux=0 nodmraid

label 180
  kernel F18/20120919/vmlinuz
  append initrd=F18/20120919/initrd.img ramdisk_size=10000 repo=nfs:proto=udp:172.23.103.50:/home/me/F/F18/20120919/ ip=dhcp noipv6 loglevel=debug keymap=us lang=en_US.UTF-8 selinux=0 nodmraid rd.debug

As you can see, they are the same format as things I have
previously tried, only accessing the 9/19 initrd.img this
time.  (The second had the rd.debug flag turned on.)

Neither attempt worked.

It takes me a while to save things from that dracut shell
and then get them to where I can upload them, so I didn't do
it on 9/19, when I first tried it.  But I'm guessing it
won't matter to you.  If it does (and you want me to try the
9/21 initrd.img or wait for something to happen), say so.

As before, I don't really know what you may need in order to
debug this so I am attaching a few things.

If you have no luck in discovering the problem, I will be
happy to assist you in finding it.  Just let me know.

Thanks.
Comment 15 Paul Franklin (RHlists) 2012-09-25 09:46:52 EDT
Proposing as Beta blocker:
"It must be possible to install by booting the installation
kernel directly, including via PXE, and correctly specifying
a remote source for the installer itself, using whichever
protocols are required to work for package retrieval at the
current phase (Alpha, Beta, Final). This must work if the
remote source is not a complete repository but contains only
the files necessary for the installer itself to run."
Comment 16 Adam Williamson 2012-10-04 14:30:52 EDT
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . We noted that Kamil Paral filed a pass for the PXE validation test for Beta TC1: https://fedoraproject.org/wiki/Test_Results:Fedora_18_Beta_TC1_Install#PXE_Images . So we need more data to know what's going on here exactly and if this should be a blocker.

Paul, can you compare your configuration to that in the test case - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot - and see if there are significant differences? kparal, can you compare your test configuration to Paul's? Paul, can you re-test with Beta TC1 or TC2 - http://dl.fedoraproject.org/pub/alt/stage/ - and see if it is still broken for you? Thanks!
Comment 17 Kamil Páral 2012-10-04 17:00:38 EDT
Just a quick note here - all my testing was done with inst.repo=http:// protocol. The bug here seems to be related to nfs protocol. That might be a game-changer here. I'll retest as soon as I can with nfs as well.
Comment 18 Jesse Keating 2012-10-04 17:58:19 EDT
(In reply to comment #17)
> Just a quick note here - all my testing was done with inst.repo=http://
> protocol. The bug here seems to be related to nfs protocol. That might be a
> game-changer here. I'll retest as soon as I can with nfs as well.

inst.repo=nfs is broken until anaconda-18.13
Comment 19 Jesse Keating 2012-10-04 19:10:19 EDT
I've tested pxe with:

LABEL F18
        kernel /images/f18/vmlinuz
        MENU LABEL f18-nfs-serial
        append initrd=/images/f18/initrd.img ksdevice=bootif kssendmac inst.repo=http://reducio/mirror/development/18/x86_64/os console=ttyS0
        ipappend 2

and that works.

append initrd=/images/f18/initrd.img ksdevice=bootif kssendmac inst.repo=nfs:reducio:/srv/mirror/development/18/x86_64/os console=ttyS0

works as well (provided I'm using the Beta TC2 image set (anaconda 18.12)).

These are the common methods of doing pxe installs, what more is not working?
Comment 20 Jesse Keating 2012-10-04 19:15:52 EDT
Ok, looks like nfsiso support isn't working quite right, so that's something to look into.  Not sure if that's beta release requirement or not.
Comment 21 Jesse Keating 2012-10-04 19:34:45 EDT
Ok, the anaconda dracut module that tries to mount the iso fails.  We've got the iso dir mounted at /run/install/repo, and when we detect that there is an iso within, we try to move that mount point:

mount --move /run/install/repo /run/install/isodir

This fails with:

mount: wrong fs type, bad option, bad superblock on /run/install/repo,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

Chasing up with the kernel team why mount --move isn't working for us.
Comment 22 Jesse Keating 2012-10-04 19:47:47 EDT
*** Bug 862996 has been marked as a duplicate of this bug. ***
Comment 23 Paul Franklin (RHlists) 2012-10-04 19:50:33 EDT
> Paul, can you compare your configuration to that in the test case - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot - and see if there are significant differences? 

Well, as I said in my first post I don't claim to be a Fedora expert
but when I looked at QA:Testcase_Boot_Methods_Pxeboot it seemed to be
aimed at just booting the kernel and initrd image, then having the
user interactively enter in their desired options.  As you can see, I
placed many of my options in the PXE's append line.  I assume there
is a different path through your software (but of course I am just
guessing).  Perhaps therein lies the difference?

Note also I am giving an option to nfs, so perhaps that is it?

Having read Comment #21 I am aborting the download I had
started of 18-Beta-TC2.  I will wait for further instructions
here before I try downloading anything.

However, as I said earlier I am willing to help, try things,
give you whatever info you ask for.  Etc.

Thank you all.  I appreciate it.
Comment 24 Jesse Keating 2012-10-04 19:57:58 EDT
That test case needs to be updated, we don't have a facility to handle the "askmethod" type questions any more.  The path to stage2 has to be provided at boot time, or autodiscovered from the boot media (boot.iso/netinst.iso or the full DVD).

In the particular case you're testing, nfs, it will work provided you are pointing to a nfs tree that does have a LiveOS/squashfs.img path.  If you're pointing to a nfs tree that just has an iso it won't work due to the bug I just discovered.
Comment 25 Adam Williamson 2012-10-05 04:36:28 EDT
jesse: PXE alone is a Beta requirement, and NFS ISO alone is also a Beta requirement, the combination of the two is uncharted territory =)
Comment 26 Jesse Keating 2012-10-05 14:02:08 EDT
Ok, the base problem appears to be that /run/ is a "shared" mount, and we cannot do moves on shared mounts (see bug 847418).  A bodge would be to mount --make-private /run  before doing the mount --move call, then mount --shared /run again, but that's pretty ugly.

I'm adding Harald and Lennart to the CC list to get info from them about why /run/ is shared in the dracut environment to begin with, and see if there is any better way to accomplish what we're trying to do here, before I put in a bodge.
Comment 27 Adam Williamson 2012-10-10 14:41:34 EDT
Discussed at 2012-10-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-10/f18beta-blocker-review-3.2012-10-10-16.05.log.txt . We agreed in principle that, at Beta, either NFS non-ISO or NFS ISO remote sources need to work, but not both. The current criteria just say 'NFS' and don't really specify what this means, but in the past we've interpreted it to require NFS ISO, we don't think this is really right.

Kamil will propose changes to the criteria to cover this. On the basis of the agreement, this bug is rejected as a blocker, as plain NFS does work (and NFS ISO can be made to work with a workaround - provide LiveOS/squashfs.img). Re-proposing for Final, and adding CommonBugs so we can document the workarounds if this isn't fixed by Beta time.
Comment 28 Jesse Keating 2012-10-11 12:46:54 EDT
Ping Harald, Lennart, can you shed some light on what should be done here?
Comment 29 Lennart Poettering 2012-10-12 11:59:40 EDT
Humm, so we were asked to make everything shared, in order to play nice with containers.

Is there a reason why --move doesn't work, and can't be made work in the kernel? Any chance to replace this with --bind plus a umount?
Comment 30 Jesse Keating 2012-10-12 14:51:42 EDT
From what I heard from the kernel folks, it was a simple "no, we're not going to make --move work on shared filesystems"

Anyway I've tried your suggestion of --bind and then umount, and that seems to work in testing so I've submitted a patch.  It's a little bit nicer than the other suggestion which was to mark the filesystem as non-shared, do the move, then re-mark it as shared.
Comment 31 Michal Kovarik 2012-10-16 10:46:48 EDT
This issue affects installation from harddrive(repo=hd:<device>:/path) too.
Comment 32 Fedora Update System 2012-10-16 23:07:39 EDT
anaconda-18.17-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.17-1.fc18
Comment 33 Fedora Update System 2012-10-17 13:28:44 EDT
Package anaconda-18.17-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.17-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16295/anaconda-18.17-1.fc18
then log in and leave karma (feedback).
Comment 34 Fedora Update System 2012-10-17 22:36:39 EDT
anaconda-18.18-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.18-1.fc18
Comment 35 Fedora Update System 2012-10-18 11:28:33 EDT
Package anaconda-18.18-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.18-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16402/anaconda-18.18-1.fc18
then log in and leave karma (feedback).
Comment 36 Fedora Update System 2012-10-19 21:32:28 EDT
anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18
Comment 37 Paul Franklin (RHlists) 2012-10-20 15:30:17 EDT
I have downloaded the 18-Beta-TC6 i386 DVD image,
in the hope it might have some updated anaconda.

It failed to boot, leaving me in the dracut shell.

If necessary I will generate a "journalctl -a" output
file, and upload it here, but in the hope you can see
the problem based on my reading it (and guessing), it
seems the problem is a wrong argument to some "mount"
command, since it says:

... dracut-initqueue[268]: mount: unrecognized option '--rprivate'

after which it gives a list of possible mount options.

So maybe '--make-rprivate' is what is needed, instead?

But as I've said before, I am no expert.  I'm guessing.

Let me know what you want me to do, upload some file,
run some command in the dracit shell, etc.  Thanks.
Comment 38 Paul Franklin (RHlists) 2012-10-21 11:30:16 EDT
If I had to make a further guess, I'd guess:

.../pyanaconda/packaging/yumpayload.py

is where the offending code is:

iutil.execWithRedirect("mount",
                       ["--rprivate", "/"],
                       stderr="/dev/tty5", stdout="/dev/tty5")

but again I am just guessing.

I don't know how to patch the initramfs.img so I
will just wait for an updated anaconda, as usual.

Thanks.
Comment 39 Kamil Páral 2012-10-22 09:55:05 EDT
Paul, how do you boot? Bare-metal or virtual? Optical disk, converted to USB?

TC6 DVD in KVM boots just fine for me.
Comment 40 Kamil Páral 2012-10-22 09:56:39 EDT
Please ignore my last post, I just got confused here (thinking about a different bug).
Comment 41 Paul Franklin (RHlists) 2012-10-22 11:50:59 EDT
I boot via PXE, on "bare metal" (real machines, one
a PXE server, one a PXE client, no USB, no optical drive),
with a downloaded ISO image (of some sort, it varies) on
the server machine, NFS-mounted on the client.

Yes, I've wondered how you guys keep all the bugzilla
messages separate, in your minds.  You must get dozens
every day.  I don't envy you.

I will say I was surprised when I saw the "rprivate"
error message, since I had guessed a bind/umount pair
would be used instead.  Oh well.  I'm not trying to
tell you guys what to do; I'm just trying to install
Fedora 18, in the same way I've always installed them.

Thanks.
Comment 42 Adam Williamson 2012-10-22 19:43:12 EDT
There's a couple of invocations of 'mount --rprivate' in dracut/anaconda-lib.sh as well, they may be better candidates as they're in the dracut stuff.
Comment 43 Martin Banas 2012-10-23 07:51:44 EDT
Since this bug was originally filed because of different issue, which should be resolved, I created a new one for the -rprivate error: Bug 869246 .
Comment 44 Paul Franklin (RHlists) 2012-10-23 12:00:23 EDT
It seems to me that "nfsiso source for stage2 does not work"
still summarizes the problem fairly accurately, even if it
originally did not work for another reason.

Clearly I do not agree that it has been "fixed in 18.17"
(see above), or that it has been "resolved" as you put it.

But if you people think there should be a new bug at least
I would hope that you would make it a blocker of some sort.

Thanks.
Comment 45 Paul Franklin (RHlists) 2012-10-23 12:25:46 EDT
It's hard for me to follow things, as I am not used to
tracking changes in git, never mind in anaconda, but I
would guess that another argument for not having another
bug is that the yumpayload.py lines I reported above, in
Comment #38, were added in response to this bug report.

Thus any change to them can be thought of as a refinement
to the response to this particular bug.

I would have guessed that the dracut/anaconda-lib.sh lines
would have been the ones which required a different bug
to be created, not this bug, if anything.  Oh well.
Comment 46 Paul Franklin (RHlists) 2012-10-23 19:55:43 EDT
The make-rprivate fixes will be in anaconda-19.20

http://git.fedorahosted.org/cgit/anaconda.git/commit/?id=af5c706832622c9eb158e6c994ce240776a0f817
Comment 47 Paul Franklin (RHlists) 2012-10-23 19:56:40 EDT
Sorry.  Make that "18.20" instead.
Comment 48 Kamil Páral 2012-11-13 09:14:34 EST
This bugreport became quite unreadable. But I have tested booting in VM using vmlinuz+initrd+inst.repo=nfs:server:/path/dvd.iso and it booted and installed OK - F18 Beta TC8, anaconda 18.28. This was supposed to be fixed in 18.19, which is stable. So I'm closing this bug, and please reopen if nfsiso doesn't boot and install. For other issues please report separate bugs. Thanks.

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