Autologin and sway spin

Ask Fedora
, , ,
1

I’ve been using Fedora Sway Spin for several months and I like it a lot. I chose drive encryption with LUKS during installation. Now, however, I have to enter my password two times. I was trying to set up autologin but failed to do so.

What I did is:

sudo systemctl edit getty@tty1

and added these lines to the top of the presented override file:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin <user> --noclear %I $TERM

Where user is my username without quotation marks or brackets.

Also, I added these lines to the top of my .bash_profile:

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

After all these modifications, nothing seemingly changed – I still have to enter my password two times.

I tried to comment out .bash_profile changes to see if sway would start automatically, and it did (by sway here, I mean graphical login manager that locks screen – not tty)

Did anyone manage to set up autologin on Sway Spin? If so, I’d really appreciate any advice.

2

If you are using a Desktop Manager like GDM, SDDM, or LXDM, the method to enable autologin will be different. If you want that getty@tty1.service to handle the autologin, you will need to disable your Desktop Manager by running sudo systemctl set-default mult-user.target. (Or by uninstalling all Desktop Managers.)

If you decide you want to re-enable your Desktop Manager, you would run sudo systemctl set-default graphical.target.

2 Likes
3

P.S. Be aware that there is a change proposal in the works for Fedora Linux 44 that might “break” this setup: F44 Change Proposal: UseKmsconVTConsole [SystemWide]

4

Thank you very much!
I’m not prompted for my password a second time now.

1 Like
5

“F44 Change Proposal” – You mean, there may be a time when my system won’t start automatically after installing some updates?

6

Yes, as it stands, it looks like when you upgrade to Fedora Linux 44, your autologin will stop working.

At least for a while, you should be able to work around the problem by uninstalling the kmscon* packages.

For now, it is just something to watch out for. It won’t be a big problem until more significant changes are made to the Kernel configuration that might prevent you from being able to switch back to using agetty. Hopefully by then kmscon will be more compatible with Sway.

7

I see. I’ll create a note for my future self. Thank you.

1 Like
8

If you want to be a little more proactive, I think adding the following to /etc/dnf/dnf.conf should prevent the kmscon packages from getting installed when you upgrade Fedora Linux.

[main]
excludepkgs=kmscon*

But hopefully by then the compatibility problems between Sway and kmscon will be solved and that won’t be necessary.

2 Likes
9

Thanks. I did that as well now.

P.S. for those who will be using this discussion as a guide in the future, If you, as I, find after these modifications that your environment is partly broken, it is because your .bash_profile is not read past this line:

exec sway

So you may want to place the conditional block at the end of this file.

1 Like
10

It will be likely postponed to F45, so you have one release more before it may break.
But you can also adapt it to work with kmscon
Something like:
sudo systemctl edit kmsconvt@tty1

[Service] ExecStart=
ExecStart=-kmscon --vt=%I --seats=seat0 --no-switchvt --login – /sbin/agetty -8 -o ‘-p – \u’ --noclear --autologin <user> – - $$TERM

And in .bash_profile
if [ -z "$DISPLAY" ] && [ "$(tty)" = "/dev/tty1" ]; then
kmscon-launch-gui sway
fi

should work too.

1 Like
11

Will that "$(tty)" command evaluate correctly? IIRC, I was getting a somewhat random /dev/pts/<n> value from the tty command. The value of <n> wasn’t always 0. If you changed to another VT with Ctrl+Alt+F<N>, tty would return something other than /dev/pts/0 and there was no way to get back to the “original” VT, so you couldn’t reliably control whether or not Sway would launch by switching to a specific VT.

12

ah you’re right, this will need some adaptation.
at boot you’ll likely get /dev/pts/0, but it’s not wise to rely on that.
you can instead check that [[ $(cat /sys/class/tty/tty0/active) == “tty1” ]] and ${COLORTERM} = “kmscon”

1 Like
13

I did try a variation of that, but like I said, even though I was able to check $(</sys/class/tty/tty0/active) in my bashrc, I wasn’t able to get (back) to “tty1” after I had changed to another VT.

BTW, If you are involved in the development of kmscon, could you set the terminal status message to show something like (pts/0 on tty1) instead of just (pts/0)? Thanks. :slightly_smiling_face:

14

The login message is written by agetty, and uses /etc/issue, so kmscon can’t change that.

So that would require a change in agetty, and in /etc/issue format.
But it should be possible.

1 Like
15

Also kmscon-lauch-gui.sh uses escape code to tell kmscon to sleep, and to wakeup. If you redirect stdout, those escape code won’t go to kmscon, and you won’t be able to switch back to kmscon.
It would be more reliable to use a socket, or dbus api, but It’s not there yet.

1 Like