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.
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.