Bug 879187
|
Description
Adam Williamson
2012-11-22 10:05:19 UTC
Created attachment 649611 [details]
File: anaconda-tb
Created attachment 649612 [details]
File: product
Created attachment 649613 [details]
File: type
Created attachment 649614 [details]
File: ifcfg.log
Created attachment 649615 [details]
File: storage.log
Created attachment 649616 [details]
File: version
Created attachment 649617 [details]
File: environ
Created attachment 649618 [details]
File: executable
Created attachment 649619 [details]
File: anaconda.log
Created attachment 649620 [details]
File: syslog
Created attachment 649621 [details]
File: hashmarkername
Created attachment 649622 [details]
File: packaging.log
Created attachment 649623 [details]
File: cmdline_file
Created attachment 649624 [details]
File: release
Created attachment 649625 [details]
File: program.log
I may be just dumb and/or drunk, but I've spent the last hour trying to get an NFS install of Beta RC1 to work and just cannot do it. It either ignores my NFS repo and goes to 'nearest mirror' or hits this TB. I have an F17 system - 192.168.1.11 - with this /etc/exports : /export 192.168.1.0/24(ro,sync,insecure,root_squash,no_subtree_check,fsid=0) /export/fedora 192.168.1.0/24(rw,nohide,sync,insecure,root_squash,no_subtree_check) Fedora-18-Beta-x86_64-DVD.iso is in the /export directory . I hit this TB by booting netinst with default parameters, and at the installation source screen, selecting NFS from the drop-down and entering: 192.168.1.11:/Fedora-18-Beta-x86_64-DVD.iso in the text box, then hitting Done. If I just enter: 192.168.1.11:/ then I get no tb, but it reports an error and the spoke shows as greyed out. Various attempts at inst.repo=nfs:... incantations result in one of these three results - traceback, error/greyed out, or 'nearest mirror'. If I run 'mount -t nfs 192.168.1.11:/ /mnt/temp' on my desktop, the mount works fine, and I see the .iso file in /mnt/temp . So the server appears to be correctly configured. Proposing as a blocker, do please advise if this is, in some way, operator error. I just booted Beta RC1 netinst (anaconda 18.29.2) with inst.repo=nfs:192.168.1.1:/mnt/test , where /mnt/test contains loopback-mounted DVD. The Closest Mirror is selected by default. So...I managed to get a couple of successes by dropping the inst.stage2 parameter from the netinst parameters and passing inst.repo=nfsiso:blah. I cannot get it to work interactively, or while the inst.stage2 parameter is present. OK, NFS is definitely badly regressed in RC1 over TC9 :( This may be related to the fix for https://bugzilla.redhat.com/show_bug.cgi?id=876223 . To summarize: In TC9, I can append inst.repo=nfs or inst.repo=nfsiso on the command line just fine. No need to wipe the inst.stage2 parameter. They work interchangeably, btw, either will work for either type of NFS repo. I can pick an NFS repo from the Installation Source spoke (interactively) just fine (whether it's an exploded tree or just a directory with a .ISO file in it). Basically everything works fine *except* the single case mentioned in 876223 - where you explicitly specify a .iso filename. In RC1, interactive selection of NFS repos of any kind - exploded tree or ISO, whether passing a directory or a precise .ISO path - appears broken. Just doesn't work. You wind up with a tb or Closest Mirror. Appending the inst.repo=nfs(iso) parameter also doesn't work (you get Closest Mirror). The only way to make it work is to delete the inst.stage2 parameter and replace it with inst.repo=nfs(iso). I'll attach logs from a few failure cases. Created attachment 649795 [details]
packaging.log: appended repo=nfsiso:192.168.1.11:/export/fedora (result: Closest Mirror)
Created attachment 649796 [details]
program.log: appended repo=nfsiso:192.168.1.11:/export/fedora (result: Closest Mirror)
Created attachment 649798 [details]
syslog: appended repo=nfsiso:192.168.1.11:/export/fedora (result: Closest Mirror)
Created attachment 649799 [details]
anaconda.log: appended repo=nfsiso:192.168.1.11:/export/fedora (result: Closest Mirror)
I can confirm that the problem in comment 17 is solved if I remove inst.stage2= and provide the same inst.repo= as before. Created attachment 649802 [details]
packaging.log: booted netinst as usual, interactively specified NFS repo (result: Error setting up software source)
Created attachment 649803 [details]
program.log: booted netinst as usual, interactively specified NFS repo (result: Error setting up software source)
Created attachment 649804 [details]
anaconda.log: booted netinst as usual, interactively specified NFS repo (result: Error setting up software source)
Created attachment 649805 [details]
syslog: booted netinst as usual, interactively specified NFS repo (result: Error setting up software source)
I can also confirm (In reply to comment #24) > I can confirm that the problem in comment 17 is solved if I remove > inst.stage2= and provide the same inst.repo= as before. The other workaround is to use direct kernel boot instead of netinst (that effectively doesn't set any inst.stage2= and therefore works OK). Applies for both NFS and NFSISO. For blocker reference, the relevant criterion here is "The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options". It does not explicitly state whether both cmdline and interactive, or just one of the two, should work. I believe http://git.fedorahosted.org/cgit/anaconda.git/commit/?h=f18-beta2-branch&id=1b7e6541b8ca5dbf7f76aa20a25837906ba2b2c5 is what broke this, BTW. Looking at the IRC logs, I remember why this was committed to Beta branch now. jlk was fixing 876897 , and his fix for that depended on the changes in this commit. dlehman actually ran it past me at the time: 20-11-2012 11:37:49 < dlehman!~dlehman.72.173: adamw: I know this probably seems like a mess, but when you have 8 patches in the works you can't always te st them in isolation from each other and then again for every possible subset 20-11-2012 11:49:17 > adamw: dlehman: sure, i get that. go ahead and put that fix in. I don't believe I actually eyeballed the patch, and honestly I'm not sure I'd have wound up the alarm if I had, I usually trust jlk's/dlehman's reads. So we weren't really going against policy here, the commit was a dep of an NTH fix, just unfortunate. I'll attach a full IRC log extract for forensic purposes. Created attachment 649998 [details]
IRC log extract from when we discussed applying this patch (for forensic purposes)
*** Bug 879338 has been marked as a duplicate of this bug. *** Discussed at 2012-11-22 go/no-go meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-22/f18_beta_gono-go_meeting.2012-11-22-20.01.log.txt ) acting as a blocker review meeting. This is narrowly rejected as a blocker: it sucks, but there are two viable and documentable workarounds (replace inst.stage2= , and use direct kernel boot). Adding to CommonBugs, of course. Moving to final blocker instead. As I have said on other bugs, I am not a Fedora expert. I am the author of 879338 which is referenced in Comment 33. In that bug I used PXE to try to install RC1; it failed, so if that is using "direct kernel boot" I respectfully disagree that the workaround works. Of course, if "direct kernel boot" means something else then I apologize for wasting everybody's time reading this comment. (My PXE command line is in that bug report; I had no stage2=...) Thanks. It's possible your bug is something different, perhaps the use of UDP. Kamil just duped it on general principles. I'll check the logs and see. I'm confused why I don't see this bug listed on http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist since it seems to say above "Blocks: F18Blocker" -- which I was guessing meant it would be on that list. Thanks. (In reply to comment #38) Because I failed to remove RejectedBlocker from the Whiteboard. Thanks, fixed. +1 final blocker due to violation of the following F18 beta release criterion [1]: The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options. [1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria +1 blocker for final, the workarounds are okay for Beta but not for Final. It never occurred to me it wouldn't be a final blocker, but if we have to vote to make it so of course I vote +1 to make it a final blocker, on the grounds of "The installer must be able to use all supported local and remote package source options." (I thought it was, already.) all blockers are nominated, voted on and then accepted. +1 final blocker, not a very nice workaround known That makes for +4 blocker - moving to accepted I don't know what it means, but the initial traceback is suspiciously close to the one in bug 879612. Please retest with smoke4, I've done about a dozen installs using inst.repo=nfs:IP:path and other than not rebooting at the end they installed just fine. I tried to verify bug 879187. I booted netinst and then selected installation source dialog and provided nfsiso url nfs:ip:/path/dvd.iso Package: anaconda-18.36 OS Release: Fedora release 18 Created attachment 659293 [details]
18.36 anaconda-tb for graphical nfsiso
Created attachment 659296 [details]
18.36 anaconda-tb for cmdline nfsiso
Graphically I wasn't able to select nfs (not nfsiso) at all, it complained about invalid url all the time. There was no mention in packaging.log that it would try to mount anything. Manually I could mount it just fine.
The same applies for inst.repo=nfs:ip:path, closest mirror is selected after anaconda start and there is no mention in any logs of nfs mounting.
For inst.repo=nfs:ip:path/dvd.iso anaconda crashes immediately on start, traceback attached.
All tested with smoke4 netinst and smoke4 dvd as a nfs/nfsiso repo.
I still see the issue occurring in F18-TC1 (anaconda 18.36); hopefully I'll have a fix later today or tomorrow. QA Test Case NFSISO install F18-TC1 Booted from DVD and changed source to NFS iso file. Package: anaconda-18.36 Architecture: i686 OS Release: Fedora release 18-TC1 QA Test Case NFSISO Testing F18-TC1 Failed when trying read iso Package: anaconda-18.36 OS Release: Fedora release 18-TC1 (In reply to comment #51) > I still see the issue occurring in F18-TC1 (anaconda 18.36); hopefully I'll > have a fix later today or tomorrow. Samantha - any progress? (In reply to comment #54) > (In reply to comment #51) > > I still see the issue occurring in F18-TC1 (anaconda 18.36); hopefully I'll > > have a fix later today or tomorrow. > > Samantha - any progress? Sorry - this got preempted in favor of some RHEL issues. Hoping to take a look at it this week. Still having to work on RHEL issues, so my apologies. I should mention that with F18-TC3 (anaconda 18.37.3), I'm not getting any tracebacks. Installation over interactive NFS fails, but the installer doesn't crash, and an error message is displayed. As far as what exactly is causing the issue here though, the NFS repo (exploded tree or ISO) is never actually getting mounted. It always gets (incorrectly) detected as being mounted though....hence why anaconda continues to run, only failing when it finally hits a wall trying to access info that would be obtained from files in a mounted tree or ISO. The issue does lie in the code from the patch linked in comment 31, but it's not possible to simply revert that at this point--too much has changed in the codebase since that was originally posted. anaconda-18.37.6-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.37.6-1.fc18 I tested anaconda-18.37.6-1.fc18 with: * exploded tree in interactive mode * dvd.iso in interactive mode * exploded tree using inst.repo * dvd.iso using inst.repo Everything works. Except that nfsiso fails to reboot, which is bug 876218. dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |