Auto login and startx(desktop) without a display manager.

[Deb-fan]

Yet another auto-login and start your prefered desktop/windows manager without a display manager running on the OS thread.

Ok another thread in the forum, brought this to mind, (Wizard10000) mentioned that the only display manager which doesn't launch-run X as root is GDM. This is likely to be irrelevant in future, with Wayland and honestly I don't overly care as it is anyway but still on with the thread.

1. Using systemd to autologin a user.

Create a directory named getty@tty1.service.d and a file in it called override.conf in the following location.

Code: Select all

/etc/systemd/system/getty@tty1.service.d/override.conf

Here's what you'd add to that override.conf file.

[Service]
Type=simple
ExecStart=
ExecStart=-/sbin/agetty --autologin yourusername --noclear %I 38400 linux

That's what it'll do, automatically login the user named, where it says yourusername. Put the desired username there.

2. To automatically startx edit the .profile file in your users /home directory and add this to the bottom.

Code: Select all

#Startx Automatically
if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then
. startx
logout
fi

Ok, that will automatically run startx, when your user logs in.

3. Now say you have several DE's/WM's installed. You'll obviously want to be able to pick and switch between them. This is where update-alternatives comes into it.

Enter the following command to pick which will be the default xsession, until it's changed.

Code: Select all

sudo update-alternatives --config x-session-manager

Select the one you want to be default and you're good to go. ALMOST. Most DE's etc will be well behaved and will add a selection for themselves to x-session-manager for you. However sometimes I've found that won't be the case however you can add an entry for it yourself. ie: Let's take fluxbox by way of example. I want to add it to the x-session-manager section of update-alternatives, so I can choose it there whenever I want. Here's how ...

Code: Select all

sudo update-alternatives --install /usr/bin/x-session-manager x-session-manager /usr/bin/startfluxbox 40

In the above, I'm installing something to the x-session-manager group of update-alternatives, in this case, fluxbox, /usr/bin/fluxbox is where fluxbox errrr, lives and I'm giving it a priority of 40 there. Although it doesn't overly matter. Once it's selected it'll launch as default x-session until something else is chosen.

NOTE: Ok another scenario, the above is perfectly fine for a single user system but what about a multi-user one or one on which you want to be able to login more than one username. Easy, peasy, just skip step 1 (or remove the directory/override.conf file. You'll be met with a command-line login to enter the user and password you want to use.

Finally, you likely already have a display manager running. For all this automagic-ness to work, you'll have to change that. Couple options, remove the display manager from your OS, you can always reinstall it later if desired. Another would be to use "sudo systemctl disable lightdm" to disable lightdm and keep it from automatically starting every time the system boots up. If at some point in future you wish, re-enable the sucker with "sudo systemctl enable lightdm" and you may also need to run "sudo dpkg-reconfigure lightdm" too. After which the sucker should be up and running again.

IMPORTANT NOTE: Make sure you have the xinit package installed "dpkg -l |grep xinit" if not yep, install it ! "sudo apt install xinit", just found out the hard way I didn't have the stupid thing on a 32b/Stretch minimal netinstall OS when went to remove lightdm and set this junk up. Kept getting problems until did the above and installed the dang xinit = startx command.

[Head_on_a_Stick]

http://forums.debian.net/viewtopic.php?f=16&t=123694?

[Deb-fan]

Lol Yeah I know you have one up too Hoas. Was just thinking about this at the moment. No shortage of ways for sure but still are definitely differences between them. No worries, hope you and yours are well fellow nixer.

Btw: Thanks for posting this here too. May snag what you've got for the edit to .profile file. Though yeah, the above works fine. Yours is less text/typing though.

[Deb-fan]

Hey wanted to leave this with an important update and some additional info. Plus I owe Fluxbox an apology some recent borkage was my error/Pebcak, though thing still comes up quite a bit short compared to Openbox imo.

Okay here's the deal, recently was dorking with FB and thing didn't seem to be working. Had installed it to x-session as shown above but it wasn't running it's startup file etc. Sorted out why, checking out "man update-alternatives" is a good idea, knew some of the relevant cmds involved but couldn't remember the syntax anyway try ie: "update-alternatives --display x-session-manager" it'll list out which graphical interfaces you can set as default x-session, here's where I messed up with installing fluxbox to x-session-manager, was in a hurry and probably did "which fluxbox" at the time, which will show /usr/bin/fluxbox but that binary is meant to be used when fluxbox is acting as a window manager for another desktop, startfluxbox is meant to be used as a full stand-alone graphical session, "which startfluxbox" will show the following. Thus when the binary run at /usr/bin/startfluxbox is added and set as default x-session fluxbox will run all it's customized config files in kept in your users home directory, /home/youruser/.fluxbox is where these things go. When /usr/bin/fluxbox is used, it's just running as a bare window manager and doesn't execute any of those files, same goes for openbox-session vs just openbox which the binaries are of course kept in same location, ie: /usr/bin/openbox-session and /usr/bin/openbox. When openbox-session is run, it's a full graphical interface, all it's files such as the autostart are used, not so with /usr/bin/openbox. Same with Icewm .... /usr/bin/icewm-session that's the one to use for this.

So yeah do be mindful of typo's, not really a big deal when using sudo update-alternatives --install really anyway. It's all easy enough sorted out regardless. Just best to double check and is clearly VERY important that you install the right binary to the x-session-manager group if you want them work as a full stand-alone WM session. Have tested all hades out of this with MANY different wm's Openbox of course, Flux, Icewm, Jwm ... bunch of others. Of course this would work fine for setting desktops without using a display manager too. Anyway in parting ... sorry about the pebcak with fluxbox in the OP, it's fixed now. Peace out fellow nixers.

Oops, another cool tip, if you wanted to switch these things without rebooting, while you're in one wm/desktop just set the one you want to use as default in x-session-manager and then logout of the one you're using. Wham ... startx will automatically run and you'll be using the graphical interface you chose.

[Head_on_a_Stick]

Questions, questions, questions...

Why are you checking for $DISPLAY? If the tty command outputs "/dev/tty1" then $DISPLAY will never be set.

Why are you sourcing the startx script rather than just running it as a command?

Why are you using a separate logout command and keeping the login shell open? Use exec() for the startx command to close the login shell, the user will then be logged out automatically when the desktop session ends.

Why are you suggesting that fluxbox users add /usr/bin/startfluxbox as an x-session-manager alternative? The fluxbox package adds that as an x-window-manager alternative, which makes more sense and will also be launched automatically by the startx command (as long as nothing is providing /usr/bin/x-session-manager). The same is true for all of the other simple window managers so manually adding them to the alternatives system is just silly.

And I still don't understand why you've created another version of my HowTo on the exact same subject

[Deb-fan]

Why are you so obviously butthurt about someone else posting a different method to a how to as you did. Many years ago, went searching for and trying out different methods of doing this(same no doubt as where you came by the approach you've got posted), tried it ... has worked for a long time very well. So why, because it works, that's why. This is what the snippet from the Gentoo wiki said would and it did. Should've just not bothered, that way I only have to figure out what works for me. The fluxbox thing was an oversight on my part, I don't use Fluxbox, this is tried and tested on MANY 7-8 windows managers on Stretch and Openbox and fluxbox on Buster. The docs related to fluxbox say yes, startfluxbox is the the proper cmd to use, I made it very clear what /usr/bin/fluxbox will do and why.

This is as easy as plenty of other approaches, atm using a bash alias in .bash_aliases making setting it super easy, some other's related to just making it more convenient too, alias update-alternativesx="sudo update-alternatives --set x-session-manager" then I just add the path to the one I want, ie: /usr/bin/openbox-session at the end of the cmd. Used an xinitrc file with this for quite some time without slightest problem, no errors, no dysfunction, stats all great, system blazing along. The entry as according to the doc's for fluxbox as stand alone is exec startfluxbox in this long used file. I explored the symlinks as to how they're set up in terms of update-alternatives and once done it's easy to see what does what. I can also add the path to the one I want to use after executing startx in the .profile file and works as well /usr/bin/startfluxbox yep, fluxbox fires up, uses it's custom files etc. That last one I haven't dorked with overmuch, $DISPLAY clearly does get setup fine as doing it via this method runs great on my system, shrugs and that cmd used in .profile is fairly well the same as I've ever seen just when booting to a command prompt and running startx with the path to whichever graphical interface I want.

Really shouldn't have bothered, as I'm much more anal about anything I advise other people to do. My system is right here, getting it doing as I wish generally easily done, fixing any issues or bumps encountered while doing so ... same. Again ... why this, why that ? It works great, can you actually demonstrate any issues with it ? My money's on you can't, been doing it like this or via .xinitrc with it too a longgggggg time. Dang dude, take a deep breath, breathe Hoas, breatheeeeee. Are plenty of other ways outside of what you think or approved of. Not like I'm retarded or don't somewhat know what I'm doing after 9 or so years of fanatical gnu/Linux use. You're always telling people, oh stay away from this, don't do that, oh no ... don't dicuss that thing. Like you're the only one who can possibly google, review docs and figure this stuff out. Was already around when you first showed up in #! forums dude.

Sheesh fire up that nice shiny Ryzen (with the kernel and firmware from unstable pinned on the puppy, for better hardware support in Debian stable on that new hardware.), fire up a VM on it, then find anything approximating a reproducible issue or even just some error log output kay ? You're not some final word on gnu/Linux dude. Though you may in fact hold the title of highest post count in gnu/nix forums in history and I'm still 1/2 convinced you're a cyborg.

[Deb-fan]

Ah tad harsh. This was never intended as any kind of slight or a hey this is better than the method Head_on posted deal. Just used it for awhile works well and found it interesting, so why not share? Plus I've been known to use parts of the net like this as a personal notepad. Makes finding stuff easier at times. Tend to make a point of acknowledging you're an intelligent and highly competent techie and nixer, it's clear that's true. Though do give me a tad of credit too, like I'm so stupid wouldn't know if something I were using was causing some meaningful issue. As anal as I am about monitoring system state and performance, would be aware and zeroing in on any cause of borkage on my beloved installs in 30secs or less. No worries, this isn't that serious. Do value your and others input on things. Would be happy with any productive feedback on whatever. Though again, you're not going to find any issues with this, I'd have already ran any down long ago.

*Pops open terminal (runs buncha monitoring cmds/utils.) And how's my widdle Debbie Webbie doing tonight? Whose a good widdle operating system, that's right, you're a good widdle os, yes u r, oh yes ya are. ... Come on don't act like I'm the only one who does that kinda thing!

[Deb-fan]

More babble follows, kind of interesting.

All this starting of X junk does make much sense when you look at how it's setup, startx(xinit) the command itself by preference will look for an .xinitrc file in a users /home cause people starting X via this method are obviously not opting for use of a display manager at that time, window managers of course tend to do likewise, in the presumption that someone whose opting to use a WM may well not be using a DM and otherwise in either case if they are it'll have it's own provisions for launching and adding a given DE/WM and setting whichever default X-session. Some notes as to what overrides which in this setup.

* If login to command-line prompt and run startx, Debian will run whatever is set as default x-session. If someone doesn't have an .xinitrc file in user home anyway or if someone were to specify which graphical interface to use. ie: "startx /usr/bin/startfluxbox".
* If someone amends their .profile file and includes a line to execute startx, it looks for an .xinitrc file first, overriding what's set as default x-session in x-session-manager, if you specify a specific graphical interface as with above in the .profile file, again ie: "startx /usr/bin/startfluxbox", that overrides any .xinitrc file in /home and whatever is set as default x-session too of course. Cause a system can't have fully logged a user in without having read what they've got in their personal .profile file. End of the day however someone is going about it, ends up running whichever binaries which are kept in /usr/bin. All the exec lines in an .xinitrc file are just shorthand for the path to the selected graphical interface. ie:
exec startfluxbox is just saying exec /usr/bin/startfluxbox with the /usr/bin/ omitted on all of them.

And update-alternatives is just a maze of symlinks, dig around using "ls -l" on the suckers. Goes like this ...

Code: Select all

$ ls -l /usr/bin/x-session-manager
lrwxrwxrwx 1 root root 35 Oct 13  2017 /usr/bin/x-session-manager -> /etc/alternatives/x-session-manager


Which in turn just ends up being a dang symlink itself to the graphical interface binary that's set as default x-session.

Code: Select all

$ ls -l /etc/alternatives/x-session-manager
lrwxrwxrwx 1 root root 24 Feb 25 01:05 /etc/alternatives/x-session-manager -> /usr/bin/openbox-session


All the kinda cool commands available for update-alternatives ("man update-alternatives") are just juggling around symlinks. Not overly seeing the point of all this but an effort at standardization can't hurt and did see it being used as the default line in junk like Fluxbox or Icewm, in flux ie: :Exec x-terminal-emulator being set as the default keybind command for launching a terminal, shrugs. Makes sense the people involved at Debian central, wouldn't have bothered with all this or creating a stock x-session-manager group for setting default x-session in update-alternatives if they didn't want people using it or doing so were in any way likely causes borkage.

FUNNY: Just to be an uber super dork I added a line for the following to my .xinitrc file, "exec x-session-manager", I keep a copy of the thing on-hand in home and just rename it xinitrc.bak when not using the thing. Yep worked, lol ... when logged in startx in my .profile file ran, it ran the .xinitrc file, it has "exec x-session-manager" uncommented in it so ran that, LOL, which when run, ran it's symlink, which in turn ran what it's symlinked to, which ended up running the dang binary in /usr/bin/startfluxbox LMAO. Errrrrr, mmmmm ... Wee bit convoluted but funny. Here's a copy of the .xinitrc file used just cause.

Code: Select all

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

 exec x-session-manager
# exec enlightenment_start
# exec i3
# exec mate-session
# exec xmonad
# exec startlxqt
# exec startlxde
# exec awesome
# exec bspwm
# exec gnome-session
# exec gnome-session --session=gnome-classic
# exec startkde
# exec startxfce4
# exec startfluxbox
# exec openbox-session
# exec cinnamon-session
# exec pekwm
# exec catwm
# exec dwm
# exec startede
# exec icewm-session
# exec jwm
# exec monsterwm
# exec notion
# exec startdde       # deepin-session
# exec cwm


[Head_on_a_Stick]

I asked the questions was because I was genuinely curious if there was any reasoning behind your commands but judging by your replies you've just copy&pasted a guide from another distribution's wiki and you don't actually have a clue how it all works.

For example:

$DISPLAY clearly does get setup fine

You're missing the point.

This command line:

Code: Select all

if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then

First tests to see if the DISPLAY variable is zero length and if it is then it tests to see if the tty command returns "/dev/tty" as a result. Only if both tests are true is the startx command sourced.

But my point is that if the tty command returns "/dev/tty" then the DISPLAY variable will always be empty because that result is only returned from the console. So there is absolutely no need to test for the DISPLAY variable at all, just the tty command is needed. Adding the DISPLAY test is entirely superfluous and just slows down the startup unnecessarily.

Also, you've used a bashism for the tests whereas my guide uses POSIX tests, which will work for all login shells.

And yes, sourcing the startx script works but it's weird. Do you source all commands that are also scripts instead of just running them?

Not using exec() and adding a logout command just keeps a process running unnecessarily, which is also a bit weird, and I would have thought you would be keen to get the memory usage as low as possible. Using exec() instead of logout would achieve that.

And you're also missing my point about fluxbox:

Code: Select all

sudo update-alternatives --install /usr/bin/x-session-manager x-session-manager /usr/bin/startfluxbox 40

^ This is stupid because /usr/bin/startfluxbox is already added to the alternatives system. Try this in your system:

Code: Select all

# update-alternatives --config x-window-manager

Can you see my point now?

And please don't presume that Debian users have sudo installed, this isn't Ubuntu.

Finally:

.xinitrc file

From the startx man page:

Note that in the Debian system, what many people traditionally put in the .xinitrc file should go in .xsession instead

Compare the running processes for your desktop when launched with ~/.xinitrc with those when you move ~/.xinitrc to ~/.xsession instead. There may be some significant differences.

Really shouldn't have bothered

No, you shouldn't. Please stop polluting these boards with your noise, they are not paid for by donations so please treat them with a bit more respect and try to keep the signal-to-noise ratio up. Thanks.

[Deb-fan]

Ah thanks for setting me straight Head_on, where would I ever be withoutcha bud, totally lost in all this nixy stuff. Lol ... slows boot eh ? Yeah big time, 40secs to WORKING desktop, meaning of course I can actually do something from a cold boot on a 10yr old laptop. Really bogging me down here, whew thanks again !

Display is again obviously irrelevant, as have done this with TONS of windows managers and with Cinnamon and Mate desktops while briefly dorking with Linux Mint 19.1 or .2 fairly recently, also worked great on them. Yep .. as I'd said in one of these posts it is results of snippets found, tried/tested and proved to be effective. Am sure you've custom tailored your how-to from scratch. Sure if I google it, will find the same stuff laid out in the Archwiki where you found it prior to putting up your tute. Really when comes to the entry in .profile, don't care anyway, it works as long as it runs exec startx, which the . startx part of it does, startx/xinit works just fine, does run the stuff in /etc/X11/Xsession which itself runs the scripts in /Xsession.d and part of what those do is run whatever is set as default x-session-manager to use it as session manager first If nothing's set then It'll also check/use what's set as default x-windows-manager, why not just add it to x-session-manager, when running fluxbox stand alone, that's the clear intent. Running it as a full session, so having the option to easily add it thus is cool and fine.

Though as noted could honestly snatch your line from that other tute, check whether it works, very well should, don't think I've bothered. Main thing is just running startx and letting it handle the rest. If you run startx from a command prompt as laid out above, it runs whatever is set default in x-session-manager on Debian anyway.

As for any other possible issues as noted I've done this now for quite awhile (Stretch and Buster with varied graphical interfaces), system blazes, no errors or quirks blahblahblah. Something of an actual technical nature which demonstrates a meaningful short-coming or problem doing it as described. OS's-installs running smooth as silk here. Either way who honestly gives a whit, wanted to post some interesting dorking related to this which works well. This does, setting and switching works great too, w or w/o reboot necessary blahblah. So if it's okay with you Sire, can I please leave up this info ? Please, oh pritty please Hoasinator ? Just this once ?

You've still not produced much of anything by which to base a real objection as to function. Just reiterating that you don't like or want to do this thing, in this manner. Which is about norm in my experience with you, across many forums and many years now. Anyway done kicking this around with ya, barring you producing anything with actual merit.

PS, and the thing with sudo, again you may want to give people credit for not being dumber than a box of rocks. Folks which see a cmd appended w sudo who don't have the sudo package installed are likely to figure it out. Though that gripe has as much substance as any others you contributed here. Ah it's not that serious, more funny than anything.

[Deb-fan]

Ah it's a push, here I am bickering in a gnu/nix forum and nothing much can ever come of that surely. Though being supra-anal, had to of course compare, so I have a Buster clone on a lil 10gb partition, keep wicd-gtk on the thing for the seldom times this old laptop may be mobile and want easier scan/connect to wifi than doing it via commandline with wpa_supplicant. Had to see, tried it as Head_on advised, tried it the way outlined here. So lil difference in anything doesn't seem to matter. The entries used in various files can even be mixed and matched almost surely. Should go look in the mirror and punch myself in the face for dumping as much time dorking with this as I have lately. Main thing is hopefully there's some nugget of useful or interesting info to be found in this stupe thread.

END TRANSMISSION:

[Head_on_a_Stick]

Wow, two back-to-back posts of almost pure noise. Thanks for that...

I take it the "edit" button is still a mystery to your alcohol-addled brain then?

thanks for setting me straight

You're welcome

And no need to get so defensive, I'm just trying to show you how your guide works and where it can be improved.

slows boot eh ?

Only by a few milliseconds but yes, it does.

Try removing the "[[ -z $DISPLAY ]] &&" bit and you will notice that the stanza still works. You don't need that bit at all, it adds *nothing* except a delay.

You've still not produced much of anything by which to base a real objection as to function.

Okay, try this:

Code: Select all

chsh -s /bin/dash

Then log out & back in again and see how well your snippet in ~/.profile works then.

Spoiler alert:

Code: Select all

-dash: 28: [[: not found

Now try that with my version

EDIT: have you changed the OP to add that last paragraph about the display manager? Either that or I didn't notice before because the "advice" there is just nonsense.

Firstly, not everybody uses LightDM. Secondly, the LightDM unit file doesn't include an [Install] section so it's not meant to be either enabled or disabled directly. Disabling the .service does result in a console login at the next boot but enabling it again does not work (try it for yourself).

See my guide for the correct (and universal) method to switch the display manager on and off. You can steal it if you want, I don't mind.

And also your override.conf file for getty@tty1.service shouldn't have "Type=simple", the stock getty@.service file declares "Type=idle". See systemd.service(5) for an explanation of the differences. Not that the section will be applied anyway because you didn't clear it beforehand. So yet another example of the superfluous crap in this thread.

[Deb-fan]

Lmfrigao, signal to noise ratio? For real you're something else dude, not sure what, cyborg, Android, bot whatever but what you consider noise vs what others might find interesting/useful are clearly very different things. Then most people don't have 16 gnu/nix forum tabs open 24/7 either. All kidding aside with the post count you've amassed 35-40 thousand, it's an actual mental health issue, has to be. What do you have a toilet built into your computer chair, take a mobile device w you when nature calls etc.?

What's described here works great, has for a very long time across more than one Debian stable release(and Mint) many different graphical interfaces. Get over yourself and seek help for this mad-capped nix forum addiction you're clearly suffering from. Like I said to me you're mostly just amusing now.

[oswaldkelso]

^tldr

I've used startx for years (7-8) straight and only really use a DM when trying other distros. xinit is a core package in Debian and if you don't use a display manager should it not use it?

Basically xinitrc point's to the wm or desktop to start. startx is just a front end to xinit and if one looks at man xinit you'll see if startx fails, running xinit should drop you in to X with an xterm on display 0. So surely no matter how borked your paths are in your xinitrc you should be able to start the X server. Unless like in the old days your graphics card wasn't recognised or wayland some how interferes.

I realise it's different systems and Dragora is more like Slackware. Slackware uses xwmconfig and Dragora uses wmconfig neither are available in Debian as Debian uses update alternatives. That said they are different ways of running the same xinitrc.

On my Debian install that died I was using startx fine with icewm. I then installed TWM and ran update-alternatives selected TWM and tried to use startx. It failed to start. It complained about a permissions error so I rechecked that TWM was selected in update-alternatives. I was. I then (iirc) logged in as root in a tty and set xinitrc to point to TWM. I expected this to just make TWM system wide as opposing to using my user .xinitrc.

I then tried to use startx as a user and it still failed. Interestingly it started TWM as root. I used startx several time as root while trying to find out why I couldn't use it as a user. Then I shutdown.... for good!

"The only issue I encountered was when trying it on Buster (this was meant to be in the other thread!) Unfortunately I got a permissions error and could only start it as root! Logged out shutdown and restarted or at least tried to because I'd got a non bootable system. I tried the usual rescue mode and grub-rescue but no go so I repeat via a live CD, still no go so after a little rtfm it seems the disk is likely dying. I try fsck but no luck with that either. Anyway I formatted the drive and installed exe-gnu and the damn thing worked. Shall wait and see if the drive is going to go or if buster is trying to live up to it's name"

Now of course I'm not up to date with the Debian way any-more So it could quite possibly be a PEBKAC but it could also be a rather shitty bug.

[Deb-fan]

^Noise HOAS, sickem!

Sounds like you've been mucking around in your users /home, may have changed permissions on files. Since it's running fine as root. Would just be lazy and recursively chown everything in home "sudo chown -R $USER:$USER /home/$USER" kind of thing. May do it.