Bug 947616
| Summary: | anaconda validate architecture from remote installation sources (one can boot X86_64 dvd media and install a 32-BIT one via NFS Installation Source) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Reartes Guillermo <rtguille> | ||||||||||||||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||
| Version: | 19 | CC: | anaconda-maint-list, awilliam, dshea, g.kaviyarasu, jonathan, jreznik, mkolman, robatino, sbueno, vanmeeuwen+fedora | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||
| OS: | Linux | ||||||||||||||||||
| Whiteboard: | RejectedBlocker | ||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||
| Last Closed: | 2014-02-20 22:47:59 UTC | Type: | Bug | ||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
| Embargoed: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
Created attachment 730964 [details]
program.log
Created attachment 730965 [details]
packaging log
Created attachment 730966 [details]
storage.log
Created attachment 730967 [details]
syslog file
Created attachment 730968 [details]
X.log
I was able to boot F19a TC3 x86_64 media and install F18 Release 32-BIT. The result was a F18 32-BIT system. It booted ok and without errors that i am aware of. Created attachment 730985 [details]
packaging log (F19 64-BIT using NFS Installation Source F18 32-BIT)
17:23:45,911 INFO packaging: have _yum_lock for AnaInstallThread
17:23:45,946 DEBUG packaging: getting release version from tree at None (19)
17:23:45,949 DEBUG packaging: got a release version of 19
17:23:45,950 INFO packaging: gave up _yum_lock for AnaInstallThread
17:23:45,951 DEBUG packaging: setting releasever to previous value of 18
17:23:45,955 INFO packaging: about to acquire _yum_lock for AnaInstallThread at /usr/lib64/python2.7/site-packages/pyanaconda
/packaging/yumpayload.py:352 (_writeInstallConfig)
I don't see any reason this should be a release blocker? Please provide some kind of justification when nominating a bug as a blocker, thanks. Me neither, according to the comments, installation completes successfully. Error message is definitely not a desired behaviour (could be intentional), warning could be possible (and so this bug is more RFE). -1 blocker. In fact, this is a thing that people may very well want to be able to do, and as you pointed out, the result is a bootable system. I'd go all the way to NOTABUG with this. Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . Rejected as a blocker: this bug boils down to 'the installer did what I asked', and it's pretty hard to quantify that as a blocker bug. We might want to pop up a warning when this kind of cross-arch config is requested to ensure it's what the user wanted, but that hardly quantifies an Alpha blocker: the bar for Alpha blockers is much higher, up in the 'it doesn't work at all no matter what I do' range. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |
Created attachment 730963 [details] anaconda.log Description of problem: I booted the X86_64 media, but selected a i686 media by using NFS as an Installation Source. Anaconda never issued any warning about it, also the installation went smooth and the resulted system is a bootable i686 system.... Version-Release number of selected component (if applicable): F19a TC3 (19.14) How reproducible: always Steps to Reproduce: 0. Boot F19a TC3 X86_64 (64-BIT) DVD Media 1. Reach the Main Hub, leave defaults in the Welcome Screen 2. Change the Keyboard, if needed (i used Spanish) 3. Enter SOFTWARE: Installation Source Spoke 4. Select 'On The Network' and NFS as the Installation Source 5. I put '192.168.100.10:/var/ftp/pub/f19-32' as the NFS path. It contains the 32-BIT version of F19. This might be a potential mistake one might do some times... 6. Enter SOFTWARE: Software Selection and select Minimal, to save time. 7. Enter STORAGE: Installation Destination, i just used Automatic Partitioning, default scheme and deleting whatever was on disk. 8. Install F19, the result will be a 32-BIT install and not a 64-BIT one. Actual results: If one makes a mistake, like presenting a 32-BIT tree to a 64-BIT installer, the 64-BIT will silently install a 32-BIT system. (I was surprised that it did not crash, that itself is a good thing!). The user might end installing an unwanted architecture. Expected results: Either an error message, or a warning that the installed system will be not 64-BIT but 32-BIT. I did not test the the inverse case.