I tried BitTwister's command to see what desktop manager I was using,
[jim@sorrel ~]$ systemctl status display-manager.service
● gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset:>
Active: inactive (dead)
Should gdm be other than "dead"? Everything seems to work as I expect,
but I have only a few things showing on the icon bars.
On Sat, 11 Apr 2020 13:29:03 -0000 (UTC), Jim Beard wrote:
I tried BitTwister's command to see what desktop manager I was using,
[jim@sorrel ~]$ systemctl status display-manager.service ● gdm.service
- GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor
preset:>
Active: inactive (dead)
Should gdm be other than "dead"? Everything seems to work as I expect,
but I have only a few things showing on the icon bars.
It would not have hurt to have provided some information about o install
type (clean, upgrade)
o iso used o Desktop Environments installed.
o Desktop Environment in use
That would go a long way towards someone with time on their hands to
have a look at your problem/question.
click up a root terminal to run mcc, navigate
mcc->Boot->Set up display manager
to see what is selected.
If more than one option with one selected, I see no reason that you
could pick another one, reboot, and if do not like results, go back to original selection, and reboot.
On Sat, 11 Apr 2020 11:01:15 -0500, Bit Twister wrote:
On Sat, 11 Apr 2020 13:29:03 -0000 (UTC), Jim Beard wrote:
I tried BitTwister's command to see what desktop manager I was using,
[jim@sorrel ~]$ systemctl status display-manager.service ● gdm.service >>> - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor
preset:>
Active: inactive (dead)
Should gdm be other than "dead"? Everything seems to work as I expect,
but I have only a few things showing on the icon bars.
It would not have hurt to have provided some information about o install
type (clean, upgrade)
Upgrade
o iso used o Desktop Environments installed.
Mageia-7-x86_64.iso 4.1 GiB 2 July 20199
Only the Gnome desktop installed.
o Desktop Environment in use
Gnome
That would go a long way towards someone with time on their hands to
have a look at your problem/question.
click up a root terminal to run mcc, navigate
mcc->Boot->Set up display manager
to see what is selected.
GDM was selected. XDM was available.
If more than one option with one selected, I see no reason that you
could pick another one, reboot, and if do not like results, go back to
original selection, and reboot.
I tried a method that sometimes cleans up cruft, by choosing XDM, giving
that an ok, and when told I needed to reboot backed out until I could
choose setup display manager again and chose GDM, ok'd that. This time I went all the way out and rebooted.[jim@sorrel ~]$
Logged in, loaded the desktop, checked and found gdm dead.
Launched mcc, went to systems service, and found gdm was set to start on boot, but was stopped. After two or three clicks on start, I got a gray screen with the choice for jim or tester, selected jim.
That started the desktop, with the proper mageia background.
[jim@sorrel ~]$ ps -eF |grep gdm
root 10878 1 0 66129 7840 0 20:02 ? 00:00:00 /usr/sbin/ gdm
root 11109 10878 0 47911 8340 6 20:02 ? 00:00:00 gdm- session-worker [pam/gdm-password]
jim 11125 11109 0 46755 5500 0 20:02 tty2 00:00:00 /usr/ libexec/gdm-wayland-session /usr/bin/gnome-session
jim 12186 12144 0 8786
The gdm-wayland-session above caught my eye, so I tried a couple of
things.
[jim@sorrel ~]$ ls -l .xs*
-rw------- 1 jim jim 45 Jul 23 2017 .xsession-errors
[jim@sorrel log]$ ls -l Xorg*
-rw-r--r-- 1 root jim 34025 Apr 11 20:02 Xorg.0.log
-rw-r--r-- 1 root jim 33803 Apr 11 19:59 Xorg.0.log.old
-rw-r--r-- 1 root root 28468 Feb 14 12:38 Xorg.9.log
-rw-r--r-- 1 root root 30139 Jan 19 09:06 Xorg.9.log.old
[jim@sorrel log]$ ps -eF |grep way
jim 11216 11196 0 398474 58120 5 20:02 tty2 00:00:00 /usr/bin/ Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 - displayfd 6
jim 11125 11109 0 46755 5500 0 20:02 tty2 00:00:00 /usr/ libexec/gdm-wayland-session /usr/bin/gnome-session
jim 12692 12144 0 8786 808 0 20:28 pts/1 00:00:00 grep --
color way
And in /var/log
[root@sorrel log]# grep wayland * |grep -v directory
security.log.1:Mar 15 04:22:01 sorrel.home.invalid diff:
- Added packages : x11-server-xwayland-1.20.7-1.mga7
security.log.1:Mar 15 04:22:01 sorrel.home.invalid diff:
- Removed packages : x11-server-xwayland-1.20.5-1.mga7
It looks like my system is either alternating between wayland and xorg,
or trying to run both.
And I am totally at a loss on what to do about that. I am not inclined
to do a clean install on a new partition, and nothing short of that would seem likely to clean up everything.
My original question now has an answer, though. The gdm display manager should not be dead.
On Sun, 12 Apr 2020 04:16:07 -0500, Bit Twister wrote:
ye-gads, I pity any windows escape who tries gnome as their first Linux
OS.
Ok, forget anything else I said about gnome in the above thread.
The gray screen on login is normal, and does not look anything like
icewm login screen.
All the systemctl display stuff does not apply.
You just need to have gdm.service enabled/running and no errors.
the wayland stuff is default and does not appear to be removed in a
stock gnome only install.
I am sorry about the trouble I put you through.
On Sun, 12 Apr 2020 05:32:35 -0500, Bit Twister wrote:
On Sun, 12 Apr 2020 04:16:07 -0500, Bit Twister wrote:
ye-gads, I pity any windows escape who tries gnome as their first Linux
OS.
Ok, forget anything else I said about gnome in the above thread.
The gray screen on login is normal, and does not look anything like
icewm login screen.
All the systemctl display stuff does not apply.
You just need to have gdm.service enabled/running and no errors.
the wayland stuff is default and does not appear to be removed in a
stock gnome only install.
I am sorry about the trouble I put you through.
Life is never so simple, as you can see if you read what I think is pertinent from this morning's eplorations and tests.
reboot
startx
open a terminal window
ps -eF |grep org > deskie
Cat deskie:
root 9661 9660 1 97613 36700 4 10:56 tty1 00:00:03 /usr/ libexec/Xorg :0 vt1 -keeptty -auth /home/jim/.serverauth.9638 -
deferglyphs 16
jim 11707 10222 0 8787 756 5 11:01 pts/0 00:00:00 grep --
color org
ps -eF |grep wayland yields nothing.
as root
mcc
go to system
go to manage system services
gdm marked for On boot but stopped
Start it
get the gray windows with jim and tester
log in as jim, get the normal desktop with mageia background
open a terminal window
ps -eF | grep wayland
jim 12841 12821 0 398127 56344 3 11:07 tty2 00:00:00 /usr/bin/ Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 - displayfd 6
jim 12750 12734 0 46755 5512 6 11:07 tty2 00:00:00 /usr/ libexec/gdm-wayland-session /usr/bin/gnome-session
jim 13462 13174 0 8786 808 1 11:10 pts/0 00:00:00 grep --
color wayland
ps -eF |grep org yields nothing.
In short, gdm is set for enabled on boot in mcc/system services but fails
to load. Given I boot to level 3, should it be set to boot or left unchecked?
xinitd is running and is set to start on boot in mcc/manage system
services. Is this interfering or taking command? My understanding is
that xinit precedes gdm and should start it up, but if so that is not happening.
Should I have an .xinitrc file in $HOME with the last line of gdm ??
startx would be the next point to address, I would think.
I would think startx should use it if it exists, and when it existed it
had contents
DISPLAYMANAGER=gdm
DESKTOP=GNOME
Some months ago I was having desktop problems (as were others, due to an upgraded kernel I think) and I had deleted it. I also at one point had DISPLAYMANAGER=dm but that did not seem useful. With it or without it
today, it seems to do nothing.
It appears I have a formidable tangle ahead of me, if this thing is to
work properly.
Any ideas on what is where that determines what gets loaded?
Cheers!
jim b.
You have your system set to start on runlevel3? Why do you need a display manager then?
"The display manager is a bit of code that provides the GUI login screen
for your Linux desktop."
but you do not need it. You are logging in to the terminal and running startx.
I assume that when you run startx you get an X screen, and can run your X programs on that.
On Sun, 12 Apr 2020 05:32:35 -0500, Bit Twister wrote:
Life is never so simple, as you can see if you read what I think is
pertinent from this morning's eplorations and tests.
reboot
startx
startx would be the next point to address, I would think.
I would think startx should use it if it exists, and when it existed it
had contents
DISPLAYMANAGER=gdm
DESKTOP=GNOME
Should I have an .xinitrc file in $HOME with the last line of gdm ??
In short, gdm is set for enabled on boot in mcc/system services but fails
to load.
Given I boot to level 3, should it be set to boot or left
unchecked?
xinitd is running and is set to start on boot in mcc/manage system
services. Is this interfering or taking command? My understanding is
that xinit precedes gdm and should start it up, but if so that is not happening.
Any ideas on what is where that determines what gets loaded?
Some months ago I was having desktop problems (as were others, due to an upgraded kernel I think) and I had deleted it. I also at one point had DISPLAYMANAGER=dm but that did not seem useful. With it or without it
today, it seems to do nothing.
It appears I have a formidable tangle ahead of me, if this thing is to
work properly.
On Sun, 12 Apr 2020 16:58:24 +0000, William Unruh wrote:
<snip>
You have your system set to start on runlevel3? Why do you need a display
manager then?
Something has to manage an xwindows display, particularly if more than
one user logs into the machine. My question at the moment is, what decides and starts up the windows display.
If I use startup, with a .desktop directory calling for gdm and Gnomedesktop.
Yes. From a fresh boot and login, startx delivers an Xorg desktop. When I go into mcc and start gdm from the manage services section, I get Xwayland
as the Gnome desktop.
How do I get Xwayland and Gnome desktop without starting up mcc, going to system services, and manually start gdm there?
On Sun, 12 Apr 2020 16:58:24 +0000, William Unruh wrote:
<snip>
You have your system set to start on runlevel3? Why do you need a display
manager then?
Something has to manage an xwindows display, particularly if more than
one user logs into the machine. My question at the moment is, what decides and starts up the windows display.
If I use startup, with a .desktop directory calling for gdm and Gnomedesktop.
I get .Xorg and the Gnome desktop. It would be nice if two componentsintended
to run and work together actually did so, I would expect.
not"The display manager is a bit of code that provides the GUI login screen
for your Linux desktop."
but you do not need it. You are logging in to the terminal and running
startx.
Again, yes, I was logging into the terminal and running startx, but that did
start the Gnome Desktop Manager gdm, that I thought would be a good idea.
I assume that when you run startx you get an X screen, and can run your X
programs on that.
Yes. From a fresh boot and login, startx delivers an Xorg desktop. When I go into mcc and start gdm from the manage services section, I get Xwayland
as the Gnome desktop.
How do I get Xwayland and Gnome desktop without starting up mcc, going to system services, and manually start gdm there?
On Sun, 12 Apr 2020 17:37:25 -0000 (UTC), Jim Beard wrote:
On Sun, 12 Apr 2020 16:58:24 +0000, William Unruh wrote:
<snip>
You have your system set to start on runlevel3? Why do you need a display >>> manager then?
Something has to manage an xwindows display, particularly if more than
one user logs into the machine. My question at the moment is, what decides >> and starts up the windows display.
systemctl based on the enabled service
release
If I use startup, with a .desktop directory calling for gdm and Gnome desktop.
I suggest to you, that is an obsolete feature/function for current xorg
on Mageia.
Yes. From a fresh boot and login, startx delivers an Xorg desktop. When I >> go into mcc and start gdm from the manage services section, I get Xwayland >> as the Gnome desktop.
Well, frap, Everything I have been doing with you was based on the
assumption that you have set gui runlevel as default.
If default is just multi user runlevel 3. then I have no further suggestions other than what I have given so far.
How do I get Xwayland and Gnome desktop without starting up mcc, going to
system services, and manually start gdm there?
As root "systemctl start gdm.service" would do the same thing.
On 2020-04-12, Jim Beard <jim.beard@verizon.net> wrote:
On Sun, 12 Apr 2020 16:58:24 +0000, William Unruh wrote:
<snip>
You have your system set to start on runlevel3? Why do you need a display >>> manager then?
Something has to manage an xwindows display, particularly if more than
one user logs into the machine. My question at the moment is, what decides >> and starts up the windows display.
The windows etc are handled by the window manager, I think, which is not
the display manager. As you found (I assume) not having gdm still gave
you an xwindows system to launch and display your programs on.
GDM and the Gnome desktop running on wayland. Yes, Gnome will run with the Xorg system as well, but I would prefer the Gnome Display Manager createdIf I use startup, with a .desktop directory calling for gdm and Gnome desktop.
I get .Xorg and the Gnome desktop. It would be nice if two components intended
to run and work together actually did so, I would expect.
Which two elements?
"The display manager is a bit of code that provides the GUI login screen >>> for your Linux desktop."
but you do not need it. You are logging in to the terminal and running
startx.
Again, yes, I was logging into the terminal and running startx, but that did not
start the Gnome Desktop Manager gdm, that I thought would be a good idea.
Why?
I assume that when you run startx you get an X screen, and can run your X >>> programs on that.
Yes. From a fresh boot and login, startx delivers an Xorg desktop. When I >> go into mcc and start gdm from the manage services section, I get Xwayland >> as the Gnome desktop.
Ah, so you are concerned that the desktop you get from startx is not the desktop that you want, is that it?
I assume that startx is not reading the right file to discover what
desktop you want to run. You can tell startx which to use (not that I
can tell you how right now, I just recall seeing that in the past).
Which desktop does get started?
How do I get Xwayland and Gnome desktop without starting up mcc, going to
system services, and manually start gdm there?
I have found some old ways of starting wayland and Gnome, with at least oneof them
requiring a reboot to get back to run level 3.
On Sun, 12 Apr 2020 19:53:47 -0000 (UTC), Jim Beard wrote:
I have found some old ways of starting wayland and Gnome, with at least one of them
requiring a reboot to get back to run level 3.
In my stupid opinion, you should set mcc boot option to boot
grub2 graphical menu
Your approach of using (as root) "systemctl start gdm.service" from level 3 command line did start up Gnome with the wayland display manager, but Icould
not use Cntl-Alt-2 to get to tty2.
On Mon, 13 Apr 2020 15:14:18 -0000 (UTC), Jim Beard wrote:
Your approach of using (as root) "systemctl start gdm.service" from level 3 >> command line did start up Gnome with the wayland display manager, but I could
not use Cntl-Alt-2 to get to tty2.
Not surprising since different runlevel logic is involved.
I am interested in knowing if you set the system to boot
grub2 graphical menu ( gui runlevel 5), works as far as getting logged in.
On Tue, 14 Apr 2020 16:36:55 -0000 (UTC), Jim Beard wrote:
On Mon, 13 Apr 2020 10:55:10 -0500, Bit Twister wrote:
On Mon, 13 Apr 2020 15:14:18 -0000 (UTC), Jim Beard wrote:I set the system to boot grub2 graphical, rebooted, and found myself at a
Your approach of using (as root) "systemctl start gdm.service" from level >>>> command line did start up Gnome with the wayland display manager, but I could
not use Cntl-Alt-2 to get to tty2.
Not surprising since different runlevel logic is involved.
I am interested in knowing if you set the system to boot
grub2 graphical menu ( gui runlevel 5), works as far as getting logged in. >>
loging prompt. That worked to log me in, but no gui desktop.
Do remove/change the auto login setting you made./etc/systemd/system/default.target
I suggest resetting your test account to clean install/day one settings,
run the root commands to setup gui login and login on the test account.
Commands to reset test account follows.
I am using "junk" as the test account in the following commands.
Commands have to be executed by root.
rsync --delete -aAHSXxv /etc/skel/ /home/junk
chown -R junk:junk /home/junk
Commands to set gui runlevel 5 login.
In a root terminal prompt, paste the following:
systemctl enable gdm.service
ln -sf /lib/systemd/system/graphical.target
systemctl set-default graphical.target
systemctl enable getty@tty1.service
reboot
on next reboot you should be at the graphical login screen.
Pick desired user, and at the enter password prompt, pick the desired
desktop by clicking on the gear icon, then enter password.
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal
runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager
then launches the user's Desktop Environment upon a valid password.
If you want to stick with runlevel3 boot, then you will have to run
systemctl start gdm.service or pick the desired ""startx whatever here"
to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager,
and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1,
or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the
Gnome desktop and reverting to a level 3 console window.
I am keeping a copy of your routine for resetting an account to
day one status, setup the gui login, and login on the test account,
from your earlier post in this thread 14 Apr 2020 12:24:52. That
could come in handy, but does not seem necessary at the moment.
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal
runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager
then launches the user's Desktop Environment upon a valid password.
If you want to stick with runlevel3 boot, then you will have to run
systemctl start gdm.service or pick the desired ""startx whatever here"
to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager,
and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1,
or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the
Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at
that point the login screen is on tty1 and stays there. This does use
the wayland display manager on my system currently. I speculate gdm
will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and
get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
I am keeping a copy of your routine for resetting an account to
day one status, setup the gui login, and login on the test account,
from your earlier post in this thread 14 Apr 2020 12:24:52. That
could come in handy, but does not seem necessary at the moment.
Cheers!
jim b.
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal
runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager
then launches the user's Desktop Environment upon a valid password.
If you want to stick with runlevel3 boot, then you will have to run
systemctl start gdm.service or pick the desired ""startx whatever here"
to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager,
and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1,
or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the
Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at
that point the login screen is on tty1 and stays there. This does use
the wayland display manager on my system currently. I speculate gdm
will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and
get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
You can tell startx to start the new session on a different output.
I have never done this with wayland/gnome, but do it all the time with plasma.
startx -- :2
On Thu, 16 Apr 2020 16:45:19 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal
runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager
then launches the user's Desktop Environment upon a valid password.
If you want to stick with runlevel3 boot, then you will have to run
systemctl start gdm.service or pick the desired ""startx whatever here" >>>> to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager,
and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1,
or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the
Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at
that point the login screen is on tty1 and stays there. This does use
the wayland display manager on my system currently. I speculate gdm
will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and
get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
You can tell startx to start the new session on a different output.
I have never done this with wayland/gnome, but do it all the time with
plasma.
startx -- :2
Tried that. I first tried it from a terminal windows under Gnome desktop,
and the error message was that startx had to be run from a console window.
I then went to tty2 and tried it, only to be told startx was already
running on :0.
kde/plasma and whatever your display manager is may do things entirely different, of course.
Your error message was from startx, not from gdm/gnome. Ie, it has
nothing to do with the display manager or the login manager.
It sould to me like you did NOT do the
-- :2
part of the above command. It says to run startx on the display
2, not 0 Your error message says it was trying to do it on display 0
On Thu, 16 Apr 2020 21:45:39 -0000 (UTC), William Unruh wrote:defaults to IceWm
Your error message was from startx, not from gdm/gnome. Ie, it has
nothing to do with the display manager or the login manager.
It sould to me like you did NOT do the
-- :2
part of the above command. It says to run startx on the display
2, not 0 Your error message says it was trying to do it on display 0
You both need to read the bug report https://bugs.mageia.org/show_bug.cgi?id=16894
startx does not start default desktop configured in /etc/sysconfig/desktop,
You need to launch startx with whatever DE desired, based on what isinstalled
.
A quick glance at a Mageia Gnome only install gives
$ grep ^Exec= /usr/share/xsessions/* /usr/share/xsessions/gnome-classic.desktop:Exec=startgnome_classic /usr/share/xsessions/gnome.desktop:Exec=/usr/bin/gnome-session /usr/share/xsessions/gnome-xorg.desktop:Exec=/usr/bin/gnome-session /usr/share/xsessions/icewm.desktop:Exec=icewm /usr/share/xsessions/icewm-session.desktop:Exec=icewm-session
Based on the above I could do a
startx startgnome_classic
or startx gnome-session
If the user has already has launched a startsx then the user will
have to supply a different DISPLAY number for each new startx command.
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Thu, 16 Apr 2020 16:45:19 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal
runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager >>>>> then launches the user's Desktop Environment upon a valid password.
If you want to stick with runlevel3 boot, then you will have to run
systemctl start gdm.service or pick the desired ""startx whatever here" >>>>> to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager, >>>> and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1, >>>> or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the
Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at >>>> that point the login screen is on tty1 and stays there. This does use >>>> the wayland display manager on my system currently. I speculate gdm
will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and
get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
You can tell startx to start the new session on a different output.
I have never done this with wayland/gnome, but do it all the time with
plasma.
startx -- :2
That is
startx then a space, then two minus signs, then a space, then a colon
and the number 2.
Tried that. I first tried it from a terminal windows under Gnome desktop,
and the error message was that startx had to be run from a console window. >> I then went to tty2 and tried it, only to be told startx was already
running on :0.
Yes it HAS to be run from a console alt-ctrl-F2 lets say if that is
free.
kde/plasma and whatever your display manager is may do things entirely
different, of course.
Your error message was from startx, not from gdm/gnome. Ie, it has
nothing to do with the display manager or the login manager.
It sould to me like you did NOT do the
-- :2
part of the above command. It says to run startx on the display
2, not 0 Your error message says it was trying to do it on display 0
On Thu, 16 Apr 2020 21:45:39 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Thu, 16 Apr 2020 16:45:19 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal >>>>>> runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager >>>>>> then launches the user's Desktop Environment upon a valid password. >>>>>>
If you want to stick with runlevel3 boot, then you will have to run >>>>>> systemctl start gdm.service or pick the desired ""startx whatever here" >>>>>> to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager, >>>>> and being able to move among two or more gui desktops and terminal
consoles on ttyx but with the gdm greeter-login screen always on tty1, >>>>> or 2. starting the Gnome desktop without gdm, which does not allow
multiple Gnome desktops on different ttys but does allow exiting the >>>>> Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at >>>>> that point the login screen is on tty1 and stays there. This does use >>>>> the wayland display manager on my system currently. I speculate gdm >>>>> will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and
get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
You can tell startx to start the new session on a different output.
I have never done this with wayland/gnome, but do it all the time with >>>> plasma.
startx -- :2
That is
startx then a space, then two minus signs, then a space, then a colon
and the number 2.
Tried that. I first tried it from a terminal windows under Gnome desktop, >>> and the error message was that startx had to be run from a console window. >>> I then went to tty2 and tried it, only to be told startx was already
running on :0.
Yes it HAS to be run from a console alt-ctrl-F2 lets say if that is
free.
kde/plasma and whatever your display manager is may do things entirely
different, of course.
Your error message was from startx, not from gdm/gnome. Ie, it has
nothing to do with the display manager or the login manager.
It sould to me like you did NOT do the
-- :2
part of the above command. It says to run startx on the display
2, not 0 Your error message says it was trying to do it on display 0
startx -- :2 was the command used, and it did not work.
when I started up Gnome on a tty1 commandline with
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and then on a tty2 commandline (after Cntl-Alt-F2)
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
both worked. But, I could not start up the Gnome session on tty2 from
within tty1. That wiped out my first Gnome session, and tty1 was
frozen blank. In this set of most recent trials, gdm was not running. Anything that started up gdm dedicated tty1 to gdm's login screen, and
that could not be changed, so far as I have been able to determine.
I would think startx should use it if it exists, and when it existed it
had contents
DISPLAYMANAGER=gdm
DESKTOP=GNOME
I can not find the bug, but I do remember commenting on that the kde
name change to plasma might break a few people using .desktop because
some X11 script had a case statement for each DESKTOP name.
On 2020-04-17, Jim Beard <jim.beard@verizon.net> wrote:
On Thu, 16 Apr 2020 21:45:39 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Thu, 16 Apr 2020 16:45:19 +0000, William Unruh wrote:
On 2020-04-16, Jim Beard <jim.beard@verizon.net> wrote:
On Wed, 15 Apr 2020 11:25:26 -0500, Bit Twister wrote:
On Wed, 15 Apr 2020 14:35:08 -0000 (UTC), Jim Beard wrote:
mcc settings:
grub2 graphical interface
launch graphical interface on boot not checked
display manager gdm
do not start gui on login
Result: no gui desktop on login, gdm not running per ps.
Ok, looks normal for a runlevel 3 setup.
Based on start of this thread, I am/was trying to get you a normal >>>>>>> runlevel 5 gui login with gdm-wayland/Gnome desktop.
That would would be
grub2 graphical interface
launch graphical interface on boot CHecked
do start gui on login
Some googling about greeters indicates it starts the Display Manager >>>>>>> then launches the user's Desktop Environment upon a valid password. >>>>>>>
If you want to stick with runlevel3 boot, then you will have to run >>>>>>> systemctl start gdm.service or pick the desired ""startx whatever here"
to get a gui desktop envionment.
I seems I have my choice of 1. starting up gdm as the display manager, >>>>>> and being able to move among two or more gui desktops and terminal >>>>>> consoles on ttyx but with the gdm greeter-login screen always on tty1, >>>>>> or 2. starting the Gnome desktop without gdm, which does not allow >>>>>> multiple Gnome desktops on different ttys but does allow exiting the >>>>>> Gnome desktop and reverting to a level 3 console window.
systemctl start gdm.service
as root is the easy way to start up gdm as the display manager, and at >>>>>> that point the login screen is on tty1 and stays there. This does use >>>>>> the wayland display manager on my system currently. I speculate gdm >>>>>> will use wayland by default.
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and
XDG_SESSION_TYPE=wayland dbus-run-session gnome-session
both start up a Gnome desktop on the current tty, tty1 if I have
just logged in, and it is possible to logout from that desktop and >>>>>> get back to the level 3 command line prompt without having a gui
continue on tty1 or anywhere else. I can move around
among tty2-tty6 using Cntl-Alt-F[2-6] but cannot start a Gnome
desktop on a new tty without it killing the old one.
You can tell startx to start the new session on a different output.
I have never done this with wayland/gnome, but do it all the time with >>>>> plasma.
startx -- :2
That is
startx then a space, then two minus signs, then a space, then a colon
and the number 2.
Tried that. I first tried it from a terminal windows under Gnome desktop, >>>> and the error message was that startx had to be run from a console window.
I then went to tty2 and tried it, only to be told startx was already
running on :0.
Yes, you cannot start up a new x session on top of an old one. It will
try to use that display and complain or go nuts.
Yes it HAS to be run from a console alt-ctrl-F2 lets say if that is
free.
kde/plasma and whatever your display manager is may do things entirely >>>> different, of course.
Your error message was from startx, not from gdm/gnome. Ie, it has
nothing to do with the display manager or the login manager.
It sould to me like you did NOT do the
-- :2
part of the above command. It says to run startx on the display
2, not 0 Your error message says it was trying to do it on display 0
startx -- :2 was the command used, and it did not work.
"It did not work" is a pretty vague statement. What happened?
when I started up Gnome on a tty1 commandline with
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
and then on a tty2 commandline (after Cntl-Alt-F2)
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
OK,
both worked. But, I could not start up the Gnome session on tty2 from
Of course not.
within tty1. That wiped out my first Gnome session, and tty1 was
frozen blank. In this set of most recent trials, gdm was not running.
Anything that started up gdm dedicated tty1 to gdm's login screen, and
that could not be changed, so far as I have been able to determine.
You should not start up or need gdm. That is for logging in on runlevel
5. You are wanting to use runlevel 3.
So you must log into a separate console for each session you wnat to
run.
You have done that and it works. What else do you want?
Either that or start on runlevel 5 with gdm as your login manager.
It is unclear to me what it is you want to have happen.
Looking around line 129 I see that the resolution is that DESKTOP=
has to be the actual command which I am guessing is the same as the
one in the desktop Exec= line for the desired DE.
Selections can be found with one of the following:
grep ^Exec= /usr/share/xsessions/*
grep ^Exec= /usr/share/wayland-sessions/*.desktop
On Fri, 17 Apr 2020 07:01:56 -0400, Bit Twister<BitTwister@mouse-potato.com> wrote:
lineLooking around line 129 I see that the resolution is that DESKTOP=
has to be the actual command which I am guessing is the same as the
one in the desktop Exec= line for the desired DE.
Selections can be found with one of the following:
grep ^Exec= /usr/share/xsessions/*
grep ^Exec= /usr/share/wayland-sessions/*.desktop
That works if the DESKTOP variable is set to a valid command name, which is not normally the case.
Normally, it will fall through to line 139 ...
/usr/sbin/chksession -x=$DESKTOP
The easiest way to change the value without having to check manually, is to use mcc, enable autologin for the specified user with the desired desktop, then if you want turn off the autologin.
That will leave the ~/.desktop file set with the correct value for from the
starting with Name= in the session file.
On Sun, 12 Apr 2020 16:07:53 -0000 (UTC), Jim Beard wrote:
I would think startx should use it if it exists, and when it existed it
had contents
DISPLAYMANAGER=gdm
DESKTOP=GNOME
I indicated $HOME/.desktop had been deprecated/discontinued.
I was wrong. Sorry.
While clearing up bugs in my automated install scripts this morning,
I found out that /etc/X11/Xsession does source $HOME/.desktop
I can not find the bug, but I do remember commenting on that the kde
name change to plasma might break a few people using .desktop because
some X11 script had a case statement for each DESKTOP name.
Looking around line 129 I see that the resolution is that DESKTOP=
has to be the actual command which I am guessing is the same as the
one in the desktop Exec= line for the desired DE.
Selections can be found with one of the following:
grep ^Exec= /usr/share/xsessions/*
grep ^Exec= /usr/share/wayland-sessions/*.desktop
Both /usr/share/wayland-sessions/gnome.desktop and /usr/share/xsessions/gnome.desktop exist, and I see no easy way to
make startx find and use /usr/share/wayland-sessions/gnome.desktop.
Both /usr/share/wayland-sessions/gnome.desktop and /usr/share/xsessions/gnome.desktop exist, and I see no easy way to
make startx find and use /usr/share/wayland-sessions/gnome.desktop.
I tried BitTwister's command to see what desktop manager I was using,
[jim@sorrel ~]$ systemctl status display-manager.service
● gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset:>
Active: inactive (dead)
Should gdm be other than "dead"? Everything seems to work as I expect,
but I have only a few things showing on the icon bars.
Cheers!
jim b.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 88:45:13 |
| Calls: | 6,658 |
| Files: | 12,203 |
| Messages: | 5,334,020 |