Hide Forgot
Description of problem: Since I was having problems getting video to work in my fedora 14 alpha x86_64 DVD install attempt, I decided to let it try VNC. I gave it a VNC password in the dialog for starting the VNC server, but the vnc viewer did not ask for a password, it just connected to the server as soon as I clicked connect (using tightvnc viewer on windows XP - bleh!) Version-Release number of selected component (if applicable): Whatever is on the f14 alpha x86_64 DVD. How reproducible: Only tried it once so far. Steps to Reproduce: 1.have X fail 2.let anaconda ask you if you want to use VNC or text mode 3.choose VNC and specify a password Actual results: vncviewer connects with no password prompt Expected results: password prompt Additional info: I called this high severity because it seems like a security issue.
When I ran this again to get screenshots for another bug, I was very careful to make sure I really did specify a password, and once again I got no password prompt from the vnc client, so it looks reproducible.
I just tested F-14-Beta (anaconda-14.17.4) and it started VNC without error. When connecting to the VNC session using my F-14-Beta desktop (tigervnc-1.0.90-0.22.20100813svn4123), it prompted and accepted a valid password. I have not tested the procedure you documented regarding failing X. I do not have any systems where X currently fails. Can you confirm that the reported problem remains?
Unfortunately I can't test it. I still get the vesa driver failing, but it doesn't seem to offer VNC as an alternate technique on error now, it just goes directly to text mode. Maybe it only offers VNC when installing from an actual DVD rather than hard disk install which is what I tried this time?
(In reply to comment #3) > I still get the vesa driver failing, but it > doesn't seem to offer VNC as an alternate technique on error now, it just goes > directly to text mode. Maybe it only offers VNC when installing from an actual > DVD rather than hard disk install which is what I tried this time? Yes, this has been the behavior (intentional or unintentionl) for some time. When performing a hard drive ISO install, you must force it to use VNC by adding the boot parameter 'vnc'. I'm not clear whether that's intentional or not, so can you file a separate bug to track the missing text/vnc prompt for hard drive installs? For this bug, please boot with 'vnc', that should allow you to retest. Also, be sure you are pressing the 'OK' and not 'No password' on the VNC screen. I'm sure you aren't, but doesn't hurt to state the obvious. ┌─────────────┤ VNC Configuration ├──────────────┐ │ │ │ A password will prevent unauthorized listeners │ │ connecting and monitoring your installation │ │ progress. Please enter a password to be used │ │ for the installation │ │ │ │ Password: ******__________ │ │ Password (confirm): ******__________ │ │ │ │ │ │ ┌────┐ ┌─────────────┐ ┌──────┐ │ │ │ OK │ │ No password │ │ Back │ │ │ └────┘ └─────────────┘ └──────┘ │ │ │ │ │ └────────────────────────────────────────────────┘
I can't reproduce the original situation at all. Even if I boot from a real DVD and select basic video, it goes directly to text mode when vesa fails to work. In my original bug, it offered VNC as an alternative. If I put vnc on the kernel parameters, it goes directly to vnc, and seems to work properly.
(In reply to comment #5) > I can't reproduce the original situation at all. Even if I boot from a real > DVD and select basic video, it goes directly to text mode when vesa fails to > work. In my original bug, it offered VNC as an alternative. I don't think it will offer VNC as an alternative for a media-based (non-network) install. I could be wrong, but I'm not familiar with that workflow. However, that may be the same problem where HDISO-based (e.g. non-network) installs do not offer VNC. Martin can confirm? Is there a reason we don't offer VNC for media-based (CD/DVD/HDISO) installs when X fails or isn't available? > If I put vnc on the kernel parameters, it goes directly to vnc, and seems to > work properly. That seems to be working as expected. You can optionally provide a VNC password with another boot parameter, 'vncpassword=<password> ' For this bug, let's get feedback from Martin in order to determine how to proceed. I think we may file a new bug to address prompting for VNC for media-based installations, and close this issue as NOTABUG if we are unable to reproduce the issue.
This bug was discussed at the 2010-10-01 blocker review meeting. We agreed there's currently too much uncertainty to make a determination of the bug's status; we will review it next week.
Just to make sure I wasn't going insane, I popped the original F14 Alpha x86_64 DVD I made back in the machine, booted from it, selected basic video mode install, watched the X startup fail, then immediately got a curses mode popup titled "Unable to Start X" with two buttons to choose from [Start VNC] and [Use text mode]. When I go through the same procedure with the F14 Beta x86_64 DVD, I don't get the "Unable to Start X" popup - it goes directly to text mode install. Selecting VNC in the F14 Alpha case was the only path that got me to the original bug of VNC ignoring the password I specified. I guess one way to fix it is to never offer that option :-).
James: I am pretty sure we do not offer VNC for the same reason we do not display network configuration dialogs during media install. That is, we consider network to be optional during media install - you have (had?) to do ip=ask vnc to force the netinstall behaviour IIRC.
(In reply to comment #9) > James: I am pretty sure we do not offer VNC for the same reason we do not > display network configuration dialogs during media install. That is, we > consider network to be optional during media install - you have (had?) to do > ip=ask vnc to force the netinstall behaviour IIRC. Thanks Martin, "ip=ask" was the boot argument I was forgetting. However, I think we still have a remaining question ... Martin: Tom identifies a behavior change between the Alpha and Beta when the installer recovers from X failing to start (see comment#8). Do you know why the F-14-Beta installer no longer prompts for VNC configuration in the event that X failed to start? Tom: With regards to "Unable to Start X", is there a bug filed for that issue already? If X is failing to start, we can certainly continue to track that bug in the appropriate bug.
> Tom: With regards to "Unable to Start X", is there a bug filed for that issue > already? If X is failing to start, we can certainly continue to track that bug > in the appropriate bug. The radeon driver is working fine in beta, but the vesa driver is the one the fails to start and already has a report in bug 627073. Maybe that is a way to reproduce this: Perhaps if you have a radeon but add a kernel parameter like xdriver=nv you could reproduce the same behavior from the f14 alpha? (Just a thought).
moving to ASSIGNED
Tom, what version (exactly) of Fedora and of Anaconda are you using? VNC checks if there is a network available, but that piece of code has been there for ages. As James is saying in #2, normal VNC does work. And there was no change to the VNC code between 14.15 (Alpha) and now.. So I need exact information about the procedure to reproduce it (an Alpha) and logs from you Alpha and Beta installs. Anyways, this is not blocker at all. VNC in normal mode works and VNC after failing X on non-network install is clearly not common case.
I'm not sure what the version numbers are, but I used the released F14 Alpha x86_64 DVD, burned to an actual DVD-R and booted from my DVD drive. If I select the "basic video" install option in the initial boot screen, that is when I get the bug 627073 vesa driver X failure, and the f14 alpha installer then asks me if I want to try VNC or text mode. Doing the exact same thing with the F14 Beta x86_64 DVD on the same system gets me directly to the text mode installer with no question about VNC or text. I do have my dd-wrt enable router setup to provide dhcp and dns, so at boot time if the installer cared to ask, it could easily obtain valid network setup info. I saved all the logs in bug 627073, so you can see the f14 alpha logs attached to that bug.
We discussed this at the blocker review meeting of 2010-10-08 and agreed it is not a blocker, as per Martin's comment above.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping