*** Bug 132501 has been marked as a duplicate of this bug. ***

Marcus: Am I supporsed to fix this :)?

I don't know that's why I asked the initial reported to assign the
bug to yast2-maintainers. The runlevel code is out of my scope. In former
times this was done in my code but it was removed from there to some other
place and other maintainer.

Well, I'm a bit confused now, see this from the .changes file:
-------------------------------------------------------------------
Tue Mar 23 14:02:07 CET 2004 - mvidner@suse.cz
- propose runlevel 5 when doing a VNC installation (#31004)
- 2.9.11
-------------------------------------------------------------------
see: https://bugzilla.novell.com/show_bug.cgi?id=suse31004&x=0&y=0
Bug 46004 - VNC Installation via web browser does not work

This is part of the source code:
-------------------------------------------------------------------
    // find out proposal parameters, ie. what it depends on
    // some architectures don't have X at all
    boolean x11_needed = Arch::x11_setup_needed ();             // constant
    boolean x11_selected = Pkg::IsSelected ("xorg-x11");        // variable
    // But if we install over VNC, we want RL 5 (and kdm) even though
    // there's no X.
-------------------------------------------------------------------

So, the source code behaves well (as it is supporsed), but the bugreport says it is wrong. From my point of view either the behavior definition must be wrong or the bugreport.

In particular, olh says in bug 46004 comment 32 that runlevel 5 is needed.
So apparently RL 5 is needed to finish a VNC installation but then local X will not start.

ms: I'm afraid you have to solve this problem on you own. You can probe the hardware and propose a configuration based on the probing - if user have X11 installed - but do not let the user to test the proposed configuration if the installation runs in the VNC. That should be simple, shouldn't?

vnc relies on running kdm.
kdm does not start in runlevel 3.

One can argue that sax2 relying on runlevel 3 is a bug by itself.

In any case, if 'Remote Administration' is enabled during install, I DO expect that vnc login will work. Regardless of local X11 settings.

sax2 does not rely on runlevel 3. it forces the user to switch to
runlevel 3 if he runs the program from a console. This is because our
users often don't understand that there is a X-Server running the program
may start on but they don't see it because they are working on the console

All in all sax2 is not the point here we are talking about runlevel
configurations not about sax2. runlevel configuration is no longer my
code. Reassigning back to yast2-maintainers 

Well, Marcus, but the bugreport says that there's no valid xorg.conf after duing the VNC installation and that's why the bug-reported suggested to set the runlevel to 3.

Running sax2 after that - from console - wouldn't set the runlevel to 5 from 3 itself. So the solution could be to create a xorg.conf based on the hardware probing even the installation runs in VNC (if X11 are installed).

If you would do that feel free to call

  sax2 -r -a

from some point of the installation and you will get a valid
xorg.conf based on the hardware detection

Back to you Lukas - see Markus' solution.

This is probably gonna be fun :)

Please, see the bug 46004 - VNC Installation via web browser does not work
--- comment #10 ---
furthermore, vnc installation forces runlevel 3. But that means no kdm is 
started. Since X isnt configured anyway, it should not hurt to default to runlevel 5

a simple 'init 5' allowed remote login. inst_finish.ycp changed the runlevel 
in SLES8, this should be changed to runlevel 5 for 9.0
-------------------

--- comment #32 ---
you need runlevel 5.
-------------------

By the way, Runlevel takes care about running services and Runlevels... It is not supporsed to generate some fake xorg.conf and users would blame it for that.  I have allways though that X configuration should be generated by X configurator but maybe I'm wrong.

Generating some fake X configuration could be also done in some installation procedure which handles the VNC, SSH options.

Never mind Marcus, it might be possible to call SaX (`sax -a -r`) after the second stage is started in VNC.

But it might be also a bit problematic because it refuses to run on the console when the runlevel is set to '5' (with this runlevel it works only when running in Xwindows). The script requires runlevel '3' when running in console. Isn't it rather a bug (please, note, that `-a` should mean automatic 'without UI')?

I removed the runlevel check from sax2 if called with -a | --auto

Thanks Marcus. So there is nothing else needed. I'll add that command to the VNC_installation_only to the Write() process of the Runlevel with some nice y2milestone() and other debug information. I hope everybody will be satisfied.

On the other hand, I'd prefer to change the "Remote Administration" Write() process rather than change the Runlevel's one. The "Remote Administration" relies on that xorg.conf, but Runlevel itself doesn't. (This has to be investigated before). The only problem is, that the "Remote Administration" configuration is before XServer configuration.

Marcus, do you mind if I wrote the (auto-created) xorg.conf in the Write() process of the "Remote Administration" - (only) if it doesn't exist? Your XServer configuration will overwrite it if user selects other configuration on the next dialog.

Doing it that way if the installation runs in VNC would be a cool solution :)

Thorsten: It seems that the Remote Administration is proposed "disabled" even if the installation is done over the VNC, Firewall already supports to propose "open VNC ports" and reports it in the installation proposal. Would you like to propose the Remote Administration to be "enabled" by default in this case?

I would say yes, a usefull enhancement.

All Fixed in yast2-network-2.13.14