You are not logged in.
Rather than not remember to keep the ~/xinitrc script example up to date,
see:
~/xinitrc https://git.devuan.org/PeteGozz/slim/bl … trc.sample
** the latest version should be on the tribulate0 branch **
But others if different may suite better.
It should be self explanatory.
(well it has comments)
The **new functionality** is that the script (rather than slim)
can get you logged in and GUIed up with or without slims dbus and consolekit* status.
It also sets _your_ default which is just that.
The default /etc/slim.conf should be OK as it is.
Essentially (for now), if slim was built with consolekit and dbus
then _they_ _have_ to be available.
If **system dbus** is not running::
slim _will_ actually startup and wait for a login
but when it tries to create YOUR session
it will fail (as it can't find the system dbus socket)
and hang on a black screen.
/var/log/slim.log will say so as well.
so::
sudo service dbus restart
(or your preferred incantations)
If Slim can not find consolekit::
Slim will behave precisely as though you can never type your password correctly
(or username)
i.e. You will keep coming back to the login screen.
There may be other states that have this behaviour.
This is probably consolekit not connecting to PAM services.
Or even an xauth issue... (in some cases)
There are a minimum of two libs involved.
So check with::
$ apt-cache show slim
Forcing a re-install of slim _should_ make apt go get the dependencies
slim needs if they are missing.
$ apt-get install slim --reinstall -t jessie
(or ascii)
(you will know if its any suite else right ?)
Last edited by PeteGozz (2017-07-16 14:19:13)
Offline
News from the **deliberately breaking** it front:
I have been testing slim with and without
** consolekit and dbus ** (they are a team here)
I have consistent enough results.
Which ever way it is done *slim should not get in the way* of _your_
Window or Desktop Manager
logging you out or mounting usb sticks etc.
Rebooting from desktops::
--------------------------------
I have tested this with XFCE at ascii levels of suite / stability.
XFCE does "The Right Thing" [TM] and probably uses *sudo* or something else.
I guess. I can explore that more later.
The short version is that the desktop menu logout button works with XFCE4 at target ascii
(all the way to reboot at least) It has nothing to do with slim and _quite right too_.
Slim Functionality::
With a standard package install. | Built without consolekit (and dbus)
Which includes xconsolekit and dbus But with default /etc/slim.confF1 > lists available X sessions Does NOT list ... as is. [later]
set up YOUR ~/.xinitrc
for anything other than default.
see #26
--------------------------------------------------------------------------------------------------------
F11 > screenshots to /root/scrot.png | Depends on what YOU have installed
(which is reconfigurable) | Same root dir "issue" with Screenshots
------------------------------------------------------------------------------------------------
type - exit | exits
| to tty console
drops you to a linux console / tty. |
This "kills" the running slim instance |------------------------------------------------------------------------------------------------
type - halt | halts
halt >> root pass | asks: shutdown -h now
shutdown -h now
Do not pass GO------------------------------------------------------------------------------------------------
type - reboot reboots
and root pass asks: shutdown -r now
as advertised .
-------------------------------------------------------------------------------------------------type - console | login to on screen Xterm
login to xconsole (xterm) | a simple X session
"exit" from that =>
returns you to slim.
NOTE mouse behaviour. (focus terminal)
Last edited by PeteGozz (2017-07-17 00:35:29)
Offline
type - exit exits
Can't find the smiley with the big-eyed look of shock. Damn. Thanks for that. I didn't know.
Maybe the text over the entry box should say "username or command" instead of just "username". Check with the boss (a.k.a. She who has command over all things visual.)
Offline
Oh man GUI design stuff.
Now there is a bucket of spiders I don't want to upturn !
Offline
Positioning items on the slim screen is challenging to say the least. You have my sympathy. That's why the layout is currently so sparse.
Offline
Positioning items on the slim screen is challenging to say the least. You have my sympathy. That's why the layout is currently so sparse.
This is why in the upstream (not devuan not debian) version I will do a visually basic theme that exposes the engine more.
Not because its pretty or tasked with branding but so that there is a template to do all that design stuff with.
I have the debian 8+ (?) examples as well now to look at.
The first observation is that there are too many release specific directories of themes.
2 should be plenty. We have already dumped all that
They put the instructions greyed out in the entry field. Which is nice.
My thought would be: Icons (generic) first then text as an adjunct.
But not my call ! (and I don't want or think it should be).
Though I'm so _bad_ with GUI things ... maybe
So I'm looking at the incoming ceres/sid stuff later today...
With a view to ascii.
(there is not much at all so far that I have seen)
... Butterflys ... I'm seeing butterfys ... and planets ....
Offline
Will the input layout be the same as currently? I hope it will be for continuity. At a minimum please keep to the minimal swoosh and logo or just a solid purpy BG. (Sorry you'll have to imagine the butterflies and planets . . .)
Note that F11 at slim login screen takes a screenshot with scrot and puts it in /root/slim.png. Thanks to fsr for figuring that out. Should make things easy for you.
Offline
fsmithred wrote:PeteGozz wrote:
type - exit exitsCan't find the smiley with the big-eyed look of shock. Damn. Thanks for that. I didn't know.
Maybe the text over the entry box should say "username or command" instead of just "username". Check with the boss (a.k.a. She who has command over all things visual.)
If I am not mistaken in the other system that would log in user exit and activate the exit daemon and open an exit shocket.
Don't mind me, I may not know what I am talking about, I just skipped to devuan out of pure intuition
Offline
This is a snapshot of a test of what I'm proposing as the failsafe theme.
Its essentially purpy with some tweaks to message positioning and higher contrast font colours.
https://drive.google.com/file/d/0B6DOd- … sp=sharing
There are configure file changes.
I also need to detect if the desktop set is in place at install time.
(and not set this in the configure file or even not install it ...?)
I have not built a working deb yet.
(there may be quilt patch issues)
Offline
I'll leave the technical details to you but I do know that is not the right slim panel. You can download the latest version of the slim theme here. Note the lighter bg color of the input box, different 'login' font and the addition of an F1 message. Username name prompt (and others) appear in #dad9dc over the input box with this theme. You might want to consider the session info placement in relation to the F1 message on the panel too:
Yeah, it's BIG . . .
Offline
I'll put in the slim theme
As per the link.
I wont change anything other than actual visibility.
^<edit>^^^ done ^^^^^
Copied over from the link.
Changes:
Moved messages to an informative position.
Above the entry box
(Where users eye line is
(room for any longer messages))
Maybe a white space or two and a comment.
There appears to be no canonical source for themes ???
</edit>
I will also move it under debian/
so that it only gets installed if there is no previous theme.
Which means its functionally a failsafe.
See also the config file
-simpler(ish) to change screen messages there
git (lightweight) tagged Kafka to remove message layout
Last edited by PeteGozz (2017-07-19 03:52:08)
Offline
All done and hand quilted
Which of course means that there are build issues with the package.
quilt push -a AOK
dpkg-source --commit not so much .
So normal really.
I look again with fresh eyes tomorrow.
So anyway a test build or three I did went well enough
(except for the /etc/slim.conf file)
But hand edits made that all work
essentially it falls over to failsafe OK
This now should be "f i x e d" will see tomorrow.
Offline
Updates:
UP stream fork at git hub has useful updates
https://github.com/PeteGozz/slim
- *new distro _agnostic_ "xamplar" theme*
+ clearer THEME / INSTALL docs
+ tested slim.theme (example) file.
- More examples and comments and tidy of the system conf file.
(some of those already on Devuans git-lab)A simple minimal panel (which can be made smaller).
(some silly colour examples to expose theming a little more)- designed to work with centred backgrounds and colour
- basic alpha level support for slimlock in themes and conf file+ rough and barely tested but it does lock your screen
which requires password access.
- New *hints* messages so that we can more nicely say"press F1" (configurable)
((this is working now to a *solid beta* level))
- runs into slimlock interface "bugs" though ... I will look at that soonish.
- Exposes other (optional) messaging functionality like Welcome to %hostname
Some of these thing I will merge into the Devuan GitLAB version
For packaging tests etc.
The INSTALL file should get you on your way.
Last edited by PeteGozz (2017-07-24 11:46:43)
Offline
I had not realized this before, but slim only exists in jessie and it doesn't on ascii and ceres, although some/all installers use slim?
I had switched to lightdm and had to use it again for troubleshooting a frozen mouse and keyboard on ceres but it behaved just
the same as lightdm and lxdm. So I suspect the problem is fed through Xorg
Just puzzled.
Last edited by fungus (2017-08-14 09:34:44)
Offline
From *bitter* experience:
I would suspect evdev (comes from X "freedesktop" world) or more likely one of the udev alternatives is not past unstable yet. (ceres)
So on ascii (testing) there will be issues.
Unless of course your trying to use wayland alone in which case good luck.
Wayland doesn't do anything but render stuff. (short version).
See if you have an /etc/X11/Xwrapper ?
( there are auth and legacy packages for X )
__the rest of this is just rambling nonsense that may or may not be useful correct or even english_
These days I short circuit all that "system initialisation" total nonsense by testing startx (as root).
If that works then work backwards.
(essentially all is well )
Permission / access / initialisation of pointers graphics cards and so on, are not the task of a Display Manager. Sure loading a module or driver or protocol can be a handy *side effect* but in a "normal" work station / desktop / thin client set of use cases other subsystems are meant to handle access to lumps of plastic, metal and wishes.
Pointer and keyboard may not be fully initialised (no mouse required for example) until you get all the way to your desktop / window manager.
Because:
The Display Manager is usually *and quite rightly* allowed access to a minimal set of files and normally hosts.
Some go further than others in allowing access some do less, its impossible to guess our preferred security needs. So less is best here. The minimum required to get you logged into whatever desktop you use on whatever operating environment.
Slim more or less assumes you are on your own host.
It doesn't even allow you to select a locale TZ or alternative set of languages.
Offline
I edited what was mistyped as non-english (is instead of if)
This is on ceres
# Xwrapper.config (Debian X Window System server wrapper configuration file)
#
# This file was generated by the post-installation script of the x11-common
# package using values from the debconf database.
#
# See the Xwrapper.config(5) manual page for more information.
#
# This file is automatically updated on upgrades of the x11-common package
# *only* if it has not been modified since the last upgrade of that package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command as root:
# dpkg-reconfigure x11-common
allowed_users=console
This is on ascii
# Xwrapper.config (Debian X Window System server wrapper configuration file)
#
# This file was generated by the post-installation script of the x11-common
# package using values from the debconf database.
#
# See the Xwrapper.config(5) manual page for more information.
#
# This file is automatically updated on upgrades of the x11-common package
# *only* if it has not been modified since the last upgrade of that package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command as root:
# dpkg-reconfigure x11-common
allowed_users=console
Offline
The problem appeared on ceres and 2-3 days later it appeared on ascii too.
So whatever flawed from ceres to ascii in a matter of 2-3 days had the effect of freezing the login screen.
There is a debian bug https://bugs.debian.org/cgi-bin/bugrepo … bug=868068 but I have no idea whether it is related.
My old debian installation upgraded the past few days does not have the same problem, it is Devuan only.
Offline
My Xwrapper.config (in ascii) has these lines:
needs_root_rights=yes
allowed_users=console
I'm using slim-1.3.6-5+devuan4rc5a1
I just did update/upgrade, and everything is still working correctly.
Update: I upgraded another installation. This one was a refracta jessie that got upgraded to ascii, and then I replaced lightdm with the same version of slim I named above. The Xwrapper.config in this system only has the one line (like yours) and everything still works.
allowed_users=console
Offline
Ok I did add the extra line on both ascii and ceres, no difference.
Out of curiosity I looked at the arch based artix installation to see how they had it and it was reverse, it had the
needs_root_rights=yes but not the allowed users. Artix came with LXQT but I can't remember which DM they
used. It may have been slim and I switched to lightdm.
My devuan installation came from the official Devuan1 image and was upgraded gradually to ceres.
My other one was a Miyo installation that was upgraded to ascii.
I also did a switch from udev to eudev just in case this had an effect on anything, but no.
Last edited by fungus (2017-08-14 20:40:23)
Offline