Bug 805166
| Summary: | anaconda doesn't start with direct kernel boot and root=live:nfs: | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||
| Component: | kernel | Assignee: | Will Woods <wwoods> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 17 | CC: | awilliam, bruno, gansalmon, g.kaviyarasu, itamar, johannbg, jonathan, kernel-maint, madhu.chinakonda, nfs-maint, robatino, vanmeeuwen+fedora, wwoods | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | RejectedBlocker | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-04-19 21:48:38 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Kamil Páral
2012-03-20 15:49:56 UTC
Created attachment 571456 [details]
console log
Proposing as F17 Beta blocker due to this criterion: "The installer must be able to use the HTTP, FTP and NFS remote package source options" https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria This bug is not exactly about "package source options", but it is a pre-requisite to it. And it makes anaconda unbootable if you want to provide the root image over NFS. It is possible the same bug will manifest if I use repo=nfs:// option (not tested). Have you tried the traditional "repo=nfs://server:/path/to/repo" instead? Does it give the same result? I'm pretty ambivalent about blocker status for this one. We don't really cover remote delivery of the installer via nfs in the criteria, do we? It's not really a precursor to the criterion you cited, as you can use nfs remote package source without requiring nfs delivery of the installer... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers +1 to blocker +0 blocker +1 NTH This seems like a corner case. But it would be nice to have it fixed for the release media. (In reply to comment #3) > Have you tried the traditional "repo=nfs://server:/path/to/repo" instead? Does > it give the same result? Yes and no. It mounts squashfs.img correctly, but anaconda fails in the repo selection step. The problem is in 'nfs://'. If I change it to "repo=nfs:server:/path/to/repo" (which is according to the documentation) it works on both steps. I realized I had wrong syntax even in my original description. But it still behaves the same even after using "root=live:nfs:server:/path/squashfs.img". (In reply to comment #4) > We don't really cover > remote delivery of the installer via nfs in the criteria, do we? What if I want to boot from PXE, but want to use online repos for installation? Isn't that a valid use case? I have to provide it with squashfs.img, which I have stored on NFS. This seems to me like a reasonable PXE setup. Not sure how anaconda is doing stuff nfs wize but if you guys are using your own units you need to update them to something similar to what is in bug 769879. Last time I checked nfs in general was broken in F17 ( Granted that check was performed a while back). kamil: so if I understand comment #7, this can actually be made to work with current anaconda, and in fact the syntax specified in the documentation works - but other syntaxes which previously worked are now broken? johan: I'm using F17 as an NFS client and it seems fine, but that's pretty light duty (just for mounting my IRC logs from my IRC bouncer machine). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Adam, please note that I'm talking about 'repo=' option and 'root=' option. Those are different things. To summarize: 1. Anaconda works fine with 'repo=nfs:' option. It finds the root image (squashfs.img), mounts it, and also uses the package repository in there. 2. If you don't want to use 'repo=' option (e.g. you don't have the package repository mirrored), but still want to run anaconda (just the installer itself) from PXE, you need to use 'root=' option. This option syntax is *undocumented* (we should probably create a new bug about this). 3. 'root=' option syntax was mentioned in several bug reports by anaconda team members. It is basically the same as 'repo=VALUE' syntax, it looks like 'root=live:VALUE/LiveOS/squashfs.img'. 4. 'root=live:nfs:' is broken (as described in this bug). That means the following use case is broken: "start anaconda from PXE (or other direct kernel boot, like in VM) when you have the root image stored on NFS and you don't have package repositories mirrored". Currently either 'repo=' option is required, or you have to use other protocol than nfs in 'root=' option. In Fedora 16 we didn't have this problem because stage2 was part of initrd.img (IIRC). Therefore we have no criterion for fetching the anaconda root image from remote locations. That's why I used the "remote package source" criterion, which is very similar, but true, not the same. right, I kinda got that but the report got rather confused because you kept trying different things. if you think the test cases need to be modified or added to in the noloader era, please draft that up, we should certainly test the functionality it makes sense to test. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Discussed at 2012-03-26 QA meeting acting as a blocker review meeting. Agreed this is not a blocker per anaconda team's statement that using root= in this way is not supported or expected to work. Anaconda team is to update the documentation regarding what the repo= parameter is capable of and how it should be used. We should then look at any possible changes/improvements to the install guide and the release criteria. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Follow-up on this, AIUI: anaconda team says that repo= should always be used, even in the case Kamil describes as "If you don't want to use 'repo=' option (e.g. you don't have the package repository mirrored), but still want to run anaconda (just the installer itself) from PXE". repo= is expected to work with a partial repository - if you have the squashfs file in the appropriate place, even if the rest of the tree is missing, it should at least pull squashfs from there and then use any other repo you provide at the package selection stage for package installation. Please correct me if I'm wrong. Should we then mark this as NOTABUG or WONTFIX? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #13) > repo= is expected to work with > a partial repository - if you have the squashfs file in the appropriate place, > even if the rest of the tree is missing, it should at least pull squashfs from > there and then use any other repo you provide at the package selection stage > for package installation. Please correct me if I'm wrong. You are right, wwoods assumed that. But currently that doesn't work, see bug 790348 (the first few comments might be confusing, until we realized what the root cause is). If anaconda team claims root= option should not be used by users (they just use it internally), let's close this bug, but we should then discuss whether bug 790348 is a blocker for some of our PXE/VM boot use cases (except we don't have any ATM). I'm closing this one (root= is not for public usage) and proposing bug 790348 as a blocker due to the new criterion. |