Bug 611154
Summary: | Installation Method prompted in Anaconda although declared in ks.cfg and as boot: argument | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Carl Bachman Kharazmi <Carl.Bachman.Kharazmi> | |
Component: | anaconda | Assignee: | Chris Lumens <clumens> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> | |
Severity: | medium | Docs Contact: | ||
Priority: | low | |||
Version: | 6.1 | CC: | atodorov, borgan, Carl.Bachman.Kharazmi, dcantrell, ddumas, dgregor, jgreguske, leiwang, mshao, notting, pbokoc, weizhan | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | i386 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | anaconda-13.21.62-1 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 620813 (view as bug list) | Environment: | ||
Last Closed: | 2010-11-10 19:50:19 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 579590, 620813 |
Description
Carl Bachman Kharazmi
2010-07-04 00:30:11 UTC
This is because we're still adding "askmethod" to the boot parameters in the tree composition process, which was earlier required for testing. Can we get rid of that now? CC'ing rel-eng. Backstory: Several Fedora releases ago, we decided you could get away with completely skipping the method selection screen if we just had anaconda look at the /etc/yum.repos.d files and enable what's enabled by default. Then, you get to use the mirror system without having to know anything. When we started doing RHEL6, we didn't have any mirror system set up so by default, anaconda would run ahead to the package selection stage of installation, look for a website for the packages, not find anything, and prompt you. That was awful inconvenient for testing, so we added the askmethod parameter into the boot configs by default. Now, it seems extremely unlikely that RHEL is going to have the same mirror setup Fedora does, so perhaps the automatic repo enabling isn't a wise idea in RHEL. In that case, we should kill the askmethod parameter from the boot configs and have it behave like it used to - where the cmdline args or kickstart take precedence, otherwise you get the method selection screen in loader. Thoughts? Makes sense to me. My understanding is that the impacted code is in Anaconda's scripts directory, which is not owned by rel-eng, so hopefully nobody is waiting on me to take some action here. (not sure why I was cc'd) If I'm understanding comment #4 correctly, we get exactly the same behavior (it asks for install method) unless the user passes an argument on the command line/kickstart? With snap #8 askmethod is missing and when one boots off boot.iso anaconda will start stage2 from the boot.iso media and fail to download package metadata because no method is defined nor networking has been started. This is with manual install not kickstart. (In reply to comment #9) > With snap #8 askmethod is missing and when one boots off boot.iso anaconda will > start stage2 from the boot.iso media and fail to download package metadata > because no method is defined nor networking has been started. This is with > manual install not kickstart. Please provide the exact steps you used to perform the installation so we can investigate. 1) Using virt-manager create new KVM domU and select boot.iso as your installation media. 2) Anaconda starts and the first screen counts down 60 seconds where user can make modifications to boot cmd line. Just hit Enter. No modifications, no kickstart. 3) Just hit Next accepting all defaults untill anaconda reaches the package selection screen. Before this screen is shown anaconda tells you that it can't download metadata. The reason you're still not seeing the askmethod screen is ceb63411285e06652080fd39fe0317d1c19c295a, which adds stage2= to the boot.iso's arguments automatically. This causes us to skip the screen since we already know where stage2 is. Alexander - can you try your testing with removing the whole stage2= argument? Make sure everything works as expected with kickstart and method= like the original comment wanted. (In reply to comment #12) > Alexander - can you try your testing with removing the whole stage2= argument? > Make sure everything works as expected with kickstart and method= like the > original comment wanted. Here's my test: 1) boot from boot.iso, remove the stage2= parameter. No kickstart. The command line is: vmlinuz initrd=initrd.img method=http://... Loader detected the ISO media and asked me if I want to do a media check. After skipping it asked me which install method to use. After selecting URL method I was asked about network settings. After network was configured with DHCP anaconda proceeded to stage2 without asking me for the actual URL. 2) Second test is boot from boot.iso, remove the stage2= parameter and specify kickstart file. The command line is: vmlinuz initrd=initrd.img ks=http://.../ks.cfg The ks.cfg file contains all commands and specifies url install method. Loader started network via DHCP to download the ks.cfg file then asked me what install method to use. After selecting URL install method installation continued automatically. No more questions asked. Looks like both manual and automated installs are not working as expected. Note that there's bug #618618 (libvirt not using bridged networking) and I'm not sure if this doesn't affect things. Both tests were done in KVM. *** Bug 618144 has been marked as a duplicate of this bug. *** > 1) boot from boot.iso, remove the stage2= parameter. No kickstart. The command > line is: > vmlinuz initrd=initrd.img method=http://... > > Loader detected the ISO media and asked me if I want to do a media check. After > skipping it asked me which install method to use. After selecting URL method I > was asked about network settings. After network was configured with DHCP > anaconda proceeded to stage2 without asking me for the actual URL. You gave method=, therefore the askmethod screen is skipped. This part is working as intended. > 2) Second test is boot from boot.iso, remove the stage2= parameter and specify > kickstart file. The command line is: > vmlinuz initrd=initrd.img ks=http://.../ks.cfg > > The ks.cfg file contains all commands and specifies url install method. > > Loader started network via DHCP to download the ks.cfg file then asked me what > install method to use. After selecting URL install method installation > continued automatically. No more questions asked. This one still looks to be a problem. (In reply to comment #15) > > 1) boot from boot.iso, remove the stage2= parameter. No kickstart. The command > > line is: > > vmlinuz initrd=initrd.img method=http://... > > > > Loader detected the ISO media and asked me if I want to do a media check. After > > skipping it asked me which install method to use. After selecting URL method I > > was asked about network settings. After network was configured with DHCP > > anaconda proceeded to stage2 without asking me for the actual URL. > > You gave method=, therefore the askmethod screen is skipped. This part is > working as intended. > How is that working? There was the screen where you can select between Local Media, Hard Drive, NFS and URL install methods but after I've selected URL there wasn't the second screen which will ask me about the actual URL value. In the case I've specified method=http://... I expect that anaconda will automaticaly assume URL install method and not ask me anything. Oh right, sorry, I forgot that I'm always wrong about everything. When I try to install the RHEL6.0-20100722.0 and boot from boot.iso (download from RHEL6.0-20100722.0 tree) with no method set, after the media check step I skip, there is no ask on install method and directly enter into graphic interface. Until choose "which type of installation would you like" and I choose "replace existing linux system" and "next", and choose "write change to disk" ,there will be an error said "Unable to read group information from repositories" (as bug 618144 said). In the RHEL6.0-20100722.0 tree I see that the anaconda version is 13.21.60-1 When trying to install the same build with DVD which contains the whole source, it also has no ask on install method, but there is no error and the installation can be finished successfully. David and I worked on this one yesterday and committed some new changes that worked well in my testing. I try rhel6 beta2 (20100730.5) and boot from boot.iso again, without add "askmethod",this time I can see "DVD/NFS/URL" installation method dialogue.But after I choose URL method, I still did not find where I can input the URL address, so the installation will meet "unable to read group information repositories" again. Tested with 0730.5 tree: 1) Boot from boot.iso with 'linux method=http://...', no kickstart - install is able to complete. However there's only "Minimal" package set option available which sounds like product.img was not downloaded. Will file a separate bug for that. 2) Boot from DVD with 'linux ks=http://...', where ks.cfg specifies cdrom as install method - install completed, all package options were available (i.e. Basic server, Desktop, Minimal, etc) 3) Boot from boot.iso with 'linux askmethod' - select URL install method, configure TCP/IP, anaconda will ask for the URL value - install completes fine. 4) Boot from DVD with 'linux askmethod' - select URL install method, configure networking, anaconda will ask for the URL value - install completes fine. Moving to VERIFIED. Chris, booting with kickstart or manually with askmethod or method=... works as expected. However booting off boot.iso and just accepting the defaults fails. Anaconda asked me which install method I want, I've selected URL method, configured networking and stage2 started shortly afterwards. There was no screen asking me which is the URL of the install method. Should I open a new bug for this or move this one back to ASSIGNED? Please see bug 620746 and make sure you're testing anaconda-13.21.69-1 (or later). Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |