LXDE still installs on Fedora with one dnf command, and it still logs in. What it does not do out of the box is remember a password. Every LXDE session we started had a broken keyring, so any application that keeps passwords in the Secret Service either failed outright or asked for a brand new keyring password.
This guide covers the full path: what Fedora ships, the install, the graphical boot, logging in through LXDM or GDM, the keyring fix for each case, and a clean removal. We tested on Fedora 45 and Fedora 44 in October 2026, on minimal Cloud Base VMs and on a Fedora 45 Workstation, with SELinux enforcing.
See what Fedora ships for LXDE
LXDE comes as one environment and four groups. List them:
dnf environment list | grep -i lxde
dnf group list --hidden | grep -i lxde
Fedora 45 and Fedora 44 print the same IDs:
lxde-desktop-environment LXDE Desktop no
lxde-apps Applications for the LXDE Desktop no
lxde-desktop LXDE no
lxde-media Multimedia support for LXDE no
lxde-office LXDE Office no
critical-path-lxde Critical Path (LXDE) no
The lxde-desktop group is the desktop itself: Openbox, LXPanel, PCManFM, LXSession, LXTerminal, the LXDM display manager and a handful of small tools such as Leafpad, GPicView and Xarchiver. The environment wraps it with base-x, fonts, multimedia, printing, input methods and hardware support. The three optional groups add applications. lxde-apps brings Firefox, Pidgin, Sylpheed and Transmission. lxde-media and lxde-office add Brasero, Pavucontrol, AbiWord and Gnumeric.
One detail in the group list explains most of this article. Inspect the mandatory packages:
dnf group info lxde-desktop
On Fedora 44 the list includes gnome-keyring-pam. On Fedora 45 that line is gone and pam_oo7 takes its place, the PAM module for the new oo7 secret service. The relevant slice of the Fedora 45 output:
: openbox
: openssh-askpass
: pam_oo7
: pcmanfm
: perl-File-MimeInfo
Keep that in mind for the keyring section.
Install the LXDE environment
One command installs the desktop and the display manager:
sudo dnf install @lxde-desktop-environment
On the minimal Fedora 45 VM the transaction looked like this:
Transaction Summary:
Installing: 1133 packages
Total size of inbound packages is 1 GiB. Need to download 1 GiB.
After this operation, 3 GiB extra will be used (install 3 GiB, remove 0 B).
Fedora 44 pulled 1193 packages for the same download and disk size. On a Fedora 45 Workstation that already runs GNOME, most base groups are present, and the same command installed 252 packages and downloaded 222 MiB.
The environment ships no web browser, no mail client and no office suite. The menu has no Internet section at all until you add the optional groups:
sudo dnf group install lxde-apps lxde-media lxde-office
That added 106 packages and a 267 MiB download on top of the environment. Confirm the core pieces landed:
rpm -q lxde-common lxsession lxpanel pcmanfm openbox lxdm lxterminal xorg-x11-server-Xorg
Fedora 45 output:
lxde-common-0.99.4-1.fc45.noarch
lxsession-0.5.7-1.fc45.x86_64
lxpanel-0.11.1^20260313git4dec3d0d-3.fc45.x86_64
pcmanfm-1.4.0^20251022git09087446-3.fc45.x86_64
openbox-3.6.1-32.fc45.x86_64
lxdm-0.5.3^20220831git2d4ba970-17.fc45.x86_64
lxterminal-0.4.1^20250415gitac5e36f4-4.fc45.x86_64
xorg-x11-server-Xorg-21.1.25-1.fc45.x86_64
LXDE is X11 only. The install drops two session files into /usr/share/xsessions/, LXDE.desktop and openbox.desktop, and nothing into wayland-sessions. The LXDE entry runs /usr/bin/startlxde.
What changed between Fedora 45 and Fedora 44
The desktop is close to identical on both releases. The differences that matter:
| Item | Fedora 45 | Fedora 44 |
|---|---|---|
| lxde-common / lxsession | 0.99.4 / 0.5.7 | 0.99.3 / 0.5.6 |
| openbox / lxdm | 3.6.1-32 / 0.5.3 snapshot, release 17 | 3.6.1-30 / 0.5.3 snapshot, release 14 |
| Environment install on Cloud Base | 1133 packages, 1 GiB, 3 GiB on disk | 1193 packages, 1 GiB, 3 GiB on disk |
| Keyring PAM module in lxde-desktop | pam_oo7 | gnome-keyring-pam |
| Secret Service after first LXDM login | None: “The name is not activatable” | gnome-keyring, but no login keyring |
| Keyring fix under LXDM | Install gnome-keyring + gnome-keyring-pam, reorder /etc/pam.d/lxdm | Reorder /etc/pam.d/lxdm |
| Session type | X11, Openbox | X11, Openbox |
Boot to the graphical target
What happens next depends on whether the machine already had a desktop. Check the boot target and the display manager link:
systemctl get-default; readlink /etc/systemd/system/display-manager.service; systemctl is-enabled lxdm
On a minimal or server install, LXDM gets the display manager link, but the machine still boots to text:
multi-user.target
/usr/lib/systemd/system/lxdm.service
enabled
Switch the default target, then reboot:
sudo systemctl set-default graphical.target
sudo systemctl reboot
On Workstation nothing changes. GDM keeps the link and LXDM stays disabled, which is what you want:
/usr/lib/systemd/system/gdm.service
disabled
enabled
Those three lines came from readlink on the link, then systemctl is-enabled lxdm gdm. Reboot the Workstation anyway so GDM picks up the new session. We rebooted before the first LXDE login and did not test whether GDM shows it without one.
Log in to LXDE
LXDM needs a password. Cloud images often create key-only accounts, so run sudo passwd youruser first if yours has none. On a minimal install, LXDM comes up with a user list. Pick your account and type the password. The Desktop dropdown at the bottom says Default, which starts LXDE:

On Workstation, click your user in GDM, then the gear button at the bottom right. LXDE and Openbox appear next to GNOME and GNOME Classic. Choose LXDE:

We logged out of LXDE and back into GNOME on the same Workstation VM, and GNOME Shell started normally. Unlike Xfce, LXDE does not leave a stale graphical session target behind for GNOME to trip over.
The first login opens a ClipIt dialog asking whether to save clipboard history. History lands in a plain text file, passwords included. Click No unless you really want that.
The panel menu sits at the bottom left. With only the environment installed, it holds Accessories, Graphics, System, Other and Preferences:

Open LXTerminal and confirm what is running. The old trick of building neofetch from Git is unnecessary now: fastfetch is in the Fedora repos and was already on our Fedora 45 VM. We limited it to a few modules so the shot stays readable:
fastfetch --structure Title:Separator:Kernel:Packages:Shell:Display:WM:WMTheme:Theme:Icons:Terminal:CPU:Memory
Window Manager reads Openbox on X11, and the VM reported about 1 GiB of RAM in use with the session and a terminal open:

logind gives the same answer from an SSH shell. Query the session on the physical seat:
loginctl show-session $(loginctl list-sessions --no-legend | awk '/seat0/{print $1}') -p Type -p Desktop -p Service -p TTY -p Remote
Both releases reported an X11 session started by LXDM on tty1:
TTY=tty1
Remote=no
Service=lxdm
Desktop=
Type=x11
Under GDM the same query printed Service=gdm-password and Type=x11. The session itself runs as /usr/bin/lxsession -s LXDE -e LXDE, with Openbox, LXPanel, PCManFM, LXPolkit, nm-applet, ClipIt and XScreenSaver running alongside it. Neither VM logged an SELinux AVC or a coredump after login.
Themes live in Customize Look and Feel (LXAppearance). Do not expect much choice in the Widget tab: on our VM it listed exactly one theme, Raleigh.

Fix the keyring
This bit us on every VM. Test the Secret Service from a terminal in the LXDE session with secret-tool, which is already installed:
echo -n demo-value | timeout 20 secret-tool store --label="cfg test" service cfg-test user demo; echo rc=$?
A working keyring stores the value silently and prints rc=0. The timeout matters: in some broken states the store waits forever, and rc=124 means it hit the 20 second limit. Ours never printed rc=0 before the fix.
Error: “secret-tool: The name is not activatable” (Fedora 45 with LXDM)
Nothing owns the Secret Service name at all:
secret-tool: The name is not activatable
rc=1
Fedora 45 moved GNOME to the oo7 secret service (the oo7 Secrets Service Provider change), and the LXDE group followed only halfway. It installs pam_oo7 and oo7-daemon but not gnome-keyring. At login the PAM module logs “Successfully sent secret to oo7 daemon”, yet pgrep oo7 finds no daemon running. The oo7-daemon.service user unit is disabled, and no D-Bus activation file exists for org.freedesktop.secrets.
Enabling the unit is not the fix under LXDM. We tried it. The daemon started and logged “Created default ‘Login’ collection (locked)”. No unlock prompt appeared on screen, and the next secret-tool store hung until our 20 second timeout killed it. If you tried this, run systemctl --user disable oo7-daemon.service before moving on.
Error: “Choose password for new keyring” (Fedora 44 with LXDM)
Fedora 44 has gnome-keyring, and the journal even claims success at login: “gkr-pam: gnome-keyring-daemon started properly and unlocked keyring”. Then the first application that wants a secret gets this dialog:

Cancel it and secret-tool reports “Object does not exist at path /org/freedesktop/secrets/collection/login”. No login keyring was ever written, and ~/.local/share/keyrings/ stayed empty.
The cause: PAM order in /etc/pam.d/lxdm
Print the session stack:
sudo grep -n "^-\?session" /etc/pam.d/lxdm
On Fedora 44 the keyring line sits above system-auth:
11:session required pam_selinux.so close
12:session required pam_loginuid.so
13:session required pam_selinux.so open
14:session optional pam_keyinit.so force revoke
15:session required pam_namespace.so
16:session optional pam_gnome_keyring.so auto_start
17:session include system-auth
18:session include postlogin
system-auth is where pam_systemd runs, and that module registers the session and sets XDG_RUNTIME_DIR. The keyring module runs one step before it, so it most likely starts its daemon without that variable. The journal later shows a second daemon complaining “couldn’t access control socket: /run/user/1000/keyring/control”. Moving the keyring line below system-auth fixed it on both releases, which points at the order. The Fedora 45 file has the same order, with a pam_oo7 line added next to the keyring one.
Apply the fix on an LXDM machine
You are editing the PAM stack of your display manager. The line we move is optional, but a typo in this file can still break graphical logins. Keep an SSH session or a text console logged in until you have tested a new login. Our tests started from an empty ~/.local/share/keyrings/. If you already clicked Continue in the Fedora 44 dialog or enabled oo7-daemon on Fedora 45, move that directory aside before you log in again, for example to ~/.local/share/keyrings.old. We did not test the fix with an existing keyring in place. Back up the file first:
sudo cp /etc/pam.d/lxdm /etc/pam.d/lxdm.orig
Fedora 45 needs gnome-keyring and its PAM module first. They are still in the repos, and the LXDM PAM file already has lines for them:
sudo dnf install gnome-keyring gnome-keyring-pam
That was a 4 package transaction. Then move the keyring line below system-auth. The Fedora 45 file uses a leading dash on that line:
sudo sed -i -e "/^-session *optional *pam_gnome_keyring.so auto_start/d" -e "/^session *include *system-auth/a -session optional pam_gnome_keyring.so auto_start" /etc/pam.d/lxdm
The Fedora 44 file has no dash, so the pattern differs:
sudo sed -i -e "/^session *optional *pam_gnome_keyring.so auto_start/d" -e "/^session *include *system-auth/a session optional pam_gnome_keyring.so auto_start" /etc/pam.d/lxdm
Run the grep again. On Fedora 45 the keyring line now follows system-auth:
12:session required pam_selinux.so close
13:session required pam_loginuid.so
14:session required pam_selinux.so open
15:session optional pam_keyinit.so force revoke
16:session required pam_namespace.so
17:-session optional pam_oo7.so auto_start
18:session include system-auth
19:-session optional pam_gnome_keyring.so auto_start
20:session include postlogin
We left the pam_oo7 line alone. It still runs at login and does no harm. Log out, log back in through LXDM, and repeat the secret-tool store test. Read the value back:
timeout 20 secret-tool lookup service cfg-test user demo; echo; echo rc=$?
The store had returned rc=0 with no prompt on both releases, and the lookup prints the value back:
demo-value
rc=0
The login keyring now exists on disk. List the directory:
ls ~/.local/share/keyrings
Two files, written by the PAM-started daemon:
login.keyring
user.keystore
We logged out and in once more on Fedora 45, and the lookup still returned the value with no prompt. To undo the change, restore the backup and its SELinux label:
sudo mv /etc/pam.d/lxdm.orig /etc/pam.d/lxdm && sudo restorecon -v /etc/pam.d/lxdm
On Fedora 45, also remove the two packages you added with sudo dnf remove gnome-keyring gnome-keyring-pam. With gnome-keyring installed and the original PAM order, our secret-tool store test hung until the timeout, which is worse than the plain error. We did not test that removal itself.
Apply the fix on Workstation with GDM
Workstation is easier. The journal shows the GDM PAM stack starting an oo7 login helper that stays running after login. In the LXDE session nothing starts the daemon itself, so secret-tool failed with the same “not activatable” error there. Start the user unit for the current session and enable it for future logins, as your normal user and without sudo:
systemctl --user start oo7-daemon.service
systemctl --user enable oo7-daemon.service
The start is silent. The enable links the unit into the default target of your user manager:
Created symlink '/home/jmutai/.config/systemd/user/default.target.wants/oo7-daemon.service' → '/usr/lib/systemd/user/oo7-daemon.service'.
After the start, the daemon logged “Created default ‘Login’ collection (unlocked)” and secret-tool store returned rc=0. To prove the enabled unit works on its own, we rebooted the VM with no other session open and logged straight into LXDE through GDM. The daemon came up with the login and unlocked the keyring by itself:
journalctl --user -b --no-pager -u oo7-daemon | grep -E "collection|Unlock|unlock" | tail -4
The two lines that matter:
Oct 10 11:15:41 lxde-ws01 oo7-daemon[2181]: 2026-10-10T11:15:41.792886Z INFO oo7_daemon::service: Unlocked keyring 'login' from "/home/jmutai/.local/share/keyrings/v1/login.keyring"
Oct 10 11:15:41 lxde-ws01 oo7-daemon[2181]: 2026-10-10T11:15:41.793027Z INFO oo7_daemon::service: Setting up collection 'login' (alias: default).
The lookup returned the stored value and a new store returned rc=0, with no prompt. A GNOME login in between also read the value, since GNOME reads the same oo7 Login keyring, so secrets stored in one desktop show up in the other. We did not need gnome-keyring on Workstation, and we did not test adding it there.
Remove LXDE
We tested removal on the minimal Cloud Base VMs only. The environment shares base groups such as base-x, fonts, multimedia and printing with Workstation, so on Workstation read the dnf remove transaction carefully before you confirm. Removing the environment does not remove LXDE. On Fedora 45:
sudo dnf remove @lxde-desktop-environment
The transaction only covered part of the install:
Transaction Summary:
Removing: 438 packages
Changing reason: 86 packages
After this operation, 2 GiB will be freed (install 0 B, remove 2 GiB).
Afterwards lxde-common, lxsession, openbox, lxdm and the Xorg server were all still installed, both session files were still in /usr/share/xsessions/, and LXDM still held the display manager link. Fedora 44 behaved the same with 497 removed and 82 re-marked. The rest is now marked as dependencies, so autoremove finishes the job:
sudo dnf autoremove
Read the list before you confirm. It removed 296 packages on Fedora 45 and 624 on Fedora 44, and both VMs kept the kernel, NetworkManager, openssh-server and sudo. The Fedora 44 VM went from 1732 packages to 611.
The optional application groups are separate. Autoremove left Firefox, Pidgin and AbiWord on the Fedora 45 VM. Removing the groups by name took them out:
sudo dnf group remove lxde-apps lxde-media lxde-office
That removed 237 packages and freed 1 GiB, and a second autoremove found 5 more. Three things survive every step. First, the boot target stays graphical.target with no display manager left, so on a server run sudo systemctl set-default multi-user.target. Second, an edited /etc/pam.d/lxdm is kept as /etc/pam.d/lxdm.rpmsave. Third, ~/.config/ keeps the lxpanel, lxsession, openbox, pcmanfm and clipit directories.
LXDE on Fedora is a working, small X11 desktop that needs one PAM fix to be usable day to day. If you would rather run something maintained more actively, LXQt on Fedora is its Qt successor, and the Xfce guide covers the other light X11 option. For a fresh machine, start with the Fedora 45 install guide, then work through the post-install checklist. The Budgie and Cinnamon guides use the same dnf group workflow.