On 20 March 2016 at 16:20, jd1008 <jd1008@gmail.com> wrote:


On 03/20/2016 10:14 AM, James Hogarth wrote:



On 20 March 2016 at 16:08, jd1008 <jd1008@gmail.com <mailto:jd1008@gmail.com>> wrote:



    On 03/19/2016 08:37 PM, g wrote:


        On 03/19/16 20:52, g wrote:

            On 03/19/16 20:38, jd1008 wrote:
            <>

                SO how can I debug this, or is this the normal behavior?
                If normal, since which release?

            --

            because you booted to level 1, not all that is needed for
            xwindows
            has been loaded.

            if you init 3, note list of additional progs that are
            initialize.

            after your login, run startx or init 5, depending on which
            state
            you want.

        --

        and i just might be incorrect on that recall from 'chemo
        brain' memory
        because i did a quick run thru and did not have problem
        issuing 'init 5'
        or 'startx' as root user at level 1.

        as for diff of what is initialized from 'level 1' and 'level
        3', it
        just may be appear that they appear diff.

        my bad. please excuse.


    Well, I am mostly concerned with finding out the why of it.
    What is NOT BEING DONE or STARTED which prevents going to full
    init level 5?



So init 1 is synonymous with the rescue target in systemd terms (see man systemd.special)

If you look at what is available at that level it does not surprise me that startx doesn't work.

Carrying out init 5 is synonymous with systemctl isolate graphical.target (the old runlevel 5 translating to the graphical target in systemd terms)

Related to this the old init 3 is roughly equivalent to systemctl isolate multi-user.target

I say roughly equal as targets and isolate is far more precise, powerful and capable than the old init levels and the symlinks that run to Kill or Start services so behaviour from days of yore may differ slightly ...

It would be useful if you are seeing issues transitioning from one target to another to get the journal from the attempts to do so.

OK. So, when it happens, you would like the output of journalctl -xb?  There are quite a options to journalctl,
and I am not sure which ones will reveal the info you want.


Just the last minute or so from the journal when you have an issue ought to assist:

journalctl  --since "1 minute ago"