Enhancement for 5.3. Our preffered way how to install headless system is over network with VNC. So create a screen in the text mode, which will ask the user if he wants to launch VNC mode instead.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 311806 [details] Ask the user if he wants to use vnc instead of text mode
Included in build 11.1.2.115
Martin, what about when we perform the installation in kickstart mode. Will text mode be used without any prompts? I assume so. Thanks!
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Anaconda's Text Mode installation now presents the option of switching to Virtual Network Computing (VNC) to complete the installation. "The VNC mode instalation offers more functionality than the text mode, would you like to use it instead?" Note to Ryan: David Cantrell wrote a whitepaper on how to use VNC, that we wnat to get onto th RH website as well - see http://dcantrel.fedorapeople.org/VNC_Whitepaper/
Martin, here're my findings: Anaconda will show the "Would you like to use VNC?" dialog in the case when we perform fully automated kickstart install in graphical mode but for whatever reason we're forced t go into text mode (e.g. boot with console= parameter for serial console access or there's no video hardware on the machine). I'm not sure what is the good solution here as it depends on when you check kickstart values. If anaconda will check all kickstart values and determine that it's a fully automated install then it can run into text mode because it will effectively show installation progress. OTOH if there's information missing from the kickstart file you'll most likely want to run vnc so the user can enter the missing info.
If you request graphical and we cannot start it, anaconda tries to fallback to text mode. Then we detect, that we are about to start text mode and ask the VNC question. The problem is.. I agree that is breaks fully automated ks installs, but when you request graphical in ks and then disable it by other means, it is not very clean setup anyways. If you want to use text mode over serial console (the described setup), why to use "graphical" command in the first place? The logic which controls the question is this: if vncksdata.displayMode!=DISPLAY_MODE_GRAPHICAL and vncksdata.displayMode!=None: flags.vncquestion = False which means, that it really happens only when there is nothing in the ks file (and text on the boot prompt) or there is graphical in the ks file and for some reason we cannot start it, which is error, because the user requested graphical. And I think we can suppose, that when we encounter error, the unattended instalation is not desirable.
James, what's your take on this issue? It's causing lots of tests to timeout and we need to take some action quickly.
For 5.3 ... if using kickstart, don't prompt ... just fallback to text-mode. Adding a timeout works as well but may just add complexity that we have to support+maintain+test for years to come. > The problem is.. I agree that is breaks fully automated ks installs, but when > you request graphical in ks and then disable it by other means, it is not very > clean setup anyways. This is very common in our and other lab setups. We request graphical (remote KVM connected), but we want the kernel console to be a remote serial console so that we can log all output (including any unexpected prompts). If the presence of console= is influencing the display mode preference of anaconda, perhaps we need to investigate how the display mode is established. The presence of console= should result in text-install only if the user also supplies 'text' on the cmdline or kickstart. Sounds like we have room for documenting expected behaviors... We have some stuff documented in the Installation Guide already, http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s2-x86-starting-bootopts.html Choosing a display mode: 1) using kernel command-line (cmdline, text, vnc) * does serial or console= influence the result ... if so how? 2) using kickstart (cmdline, text, vnc, graphical) If no display mode is specified, we will try graphical, then fallback to text. If a display mode fails to activate: * when doing kickstart, fallback to text * when not doing kickstart, prompt user for VNC or text Thoughts/concerns?
(In reply to comment #14) > We have some stuff documented in the Installation Guide already, > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s2-x86-starting-bootopts.html > > Choosing a display mode: > 1) using kernel command-line (cmdline, text, vnc) > * does serial or console= influence the result ... if so how? I've heard that serial console will always force text mode. At least practice shows it does. > 2) using kickstart (cmdline, text, vnc, graphical) > > If no display mode is specified, we will try graphical, then fallback to text. > > If a display mode fails to activate: > * when doing kickstart, fallback to text this means we have to maintain text mode so user can enter missing information which contradicts with text mode removal ideas. Better is: If a display mode fails to activate: If kickstart has all info (i.e. unattended install): * when doing kickstart, fallback to text or even cmdline else: * prompt user for VNC or text
(In reply to comment #15) > (In reply to comment #14) > > We have some stuff documented in the Installation Guide already, > > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s2-x86-starting-bootopts.html > > > > Choosing a display mode: > > 1) using kernel command-line (cmdline, text, vnc) > > * does serial or console= influence the result ... if so how? > > I've heard that serial console will always force text mode. At least practice > shows it does. I've heard similar things ... we need specifics on this point. We need to tell our customers how to reliably choose a display mode. > > 2) using kickstart (cmdline, text, vnc, graphical) > > > > If no display mode is specified, we will try graphical, then fallback to text. > > > > If a display mode fails to activate: > > * when doing kickstart, fallback to text > this means we have to maintain text mode so user can enter missing information > which contradicts with text mode removal ideas. Better is: There will *always* be a text-mode. The proposed idea is to remove functionality from text-mode that adds a devel/qa/support burden. > If a display mode fails to activate: > If kickstart has all info (i.e. unattended install): > * when doing kickstart, fallback to text or even cmdline > else: > * prompt user for VNC or text That is the intended behavior I think works best. We cannot change the kickstart install behavior for all of our customers that rely on the RHEL5.0 "assumptions" without a large documentation+messaging effort. We can of course change it in Fedora in preparation for RHEL6. In summary... * If a user requests graphical, and it fails to activate ... feel free to prompt. * If a user is relying on anaconda to select the display mode, and graphical fails to activate ... > If kickstart ... proceed with text mode > If interactive ... prompt user for preference
> * If a user is relying on anaconda to select the display mode, and graphical > fails to activate ... >> If kickstart ... proceed with text mode >> If interactive ... prompt user for preference It should work like this from the beginning... well i guess I have an error somewhere.. This patch may solve it. diff --git a/anaconda b/anaconda index 51609e8..dd309bb 100755 --- a/anaconda +++ b/anaconda @@ -881,7 +881,7 @@ if __name__ == "__main__": got_bad_edid = True opts.display_mode = 't' - if opts.display_mode == 't' and graphical_failed and not opts.ksfile: + if opts.display_mode == 't' and graphical_failed and not anaconda.isKickstart: ret = vnc.askVncWindow() if ret != -1: opts.display_mode = 'g' The updates image for it is at http://msivak.fedorapeople.org/anaconda/vncq.img
Ok, after debugging session with Alex, we now have the solution in git repo and it will be in the next (11.1.2.132) build. And for the other question: The text mode is indeed set by loader, when the serial is requested (loader2/loader.c:1510).
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,5 +1 @@ -Anaconda's Text Mode installation now presents the option of switching to Virtual Network Computing (VNC) to complete the installation. +Anaconda's Text Mode installation now presents the option of switching to Virtual Network Computing (VNC) to complete the installation.-"The VNC mode instalation offers more functionality than the text mode, would you like to use it instead?" - -Note to Ryan: David Cantrell wrote a whitepaper on how to use VNC, that we wnat to get onto th RH website as well - see -http://dcantrel.fedorapeople.org/VNC_Whitepaper/
This options was added to Fedora 10 and now it is impossible to perform unattended text mode installation. If I specifically put text mode into the anaconda's command line it shouldn't pause installation and ask if I want to use VNC instead
Vadym, this bug is filed against Red Hat Enterprise Linux 5 not Fedora. If you're seeing the issue with F10 please file another bug. You can add a link to this bug saying that it was fixed in RHEL.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0164.html