You are not logged in.
This problem may be solved. And it may seem a bit embarrassing.
Here is the current cmdline
root@devuan:~# cat /proc/cmdline
boot=live config quiet splash initrd=(hd0,1)/boot/dev611/initrd.img bootfrom=/dev/sda3 live-media-path=dev611/live0 persistence persistence-path=dev611s/pers0 keyboard-layouts=no noautologin The only 'failsafe' directive left is noautologin. Because, it seems, the default user is not created. Without any user to serve, the display does not come up.
I should have suspected this yesterday, when only root login was accepted. But I couldn't believe it was that simple.
With the default user in place, I would guess this will work out of the box ;-)
Offline
The default user already exists in devuan live isos. In debian live isos, the default user is created during boot if the option 'config' is included in the command line. I think if you remove that, you'll have the default user again.
Offline
the default user is not created. Without any user to serve, the display does not come up
But the cmdline you posted does not contain 'username=devuan' ..
Therefore live-config script /lib/live/config/0130-slim was not told to autologin the already system-configured user 'devuan'!
This is verifiable. Boot without 'username=devuan' and with 'sysv-rc=slim' (disable slim, show a shell login prompt) Autologin is then irrelevant.
cat /etc/slim.conf | lessshows that 'default user' set to 'user' (debian-live standard default) and autologin is set to 'default user'. There is no user 'user' on this system.
Last edited by dzz (2026-02-26 20:54:52)
Offline
The default user already exists in devuan live isos. In debian live isos, the default user is created during boot if the option 'config' is included in the command line. I think if you remove that, you'll have the default user again.
The user 'devuan' is not what the Debian live build procedures expect. I just created the default Debian user 'user' in my PMI install. Works fine. With autologin: User 'user' is logged in.
But I think it may be quite good practice to disable autologin. I just activated it to demonstrate that the problem is there.
Offline
Small update: This is really hard-coded on Debian's part. Even with noautologin, user 'user' is automatically logged in when it exists! ;-)
Offline
See 'man live-build' and 'man live-config' for details about the options for the live system.
Offline
See 'man live-build' and 'man live-config' for details about the options for the live system.
Sure.
Still, there have been uncovered two bugs here:
1. Lacking noautologin parameter makes live image only run in failsafe mode. Extremely simple to fix.
2. When user 'user' is defined, noautologin does not work, 'user' is logged in. Whatever the Debian live people write in their manuals, this is wrong behavior.
None of these bugs should be left for ordinary users to fix.
But, of course doing nothing about it is also an option.
Offline
I don't get the same results as you. The noautologin option is working correctly here on two different live-isos.
The devuan desktop-live iso has user 'devuan' pre-defined, and with noautologin, boot stops at the slim login screen.
A refracta live iso has user 'user' pre-defined, and with noautologin, boot stops at the lightdm login screen.
Maybe I should call it a pre-existing user instead. That user already exists and has a home directory inside the squashfs as opposed to being created when the system boots.
Offline
I don't get the same results as you. The noautologin option is working correctly here on two different live-isos.
It does not work when user 'user' is defined, as I noted. This is common behavior on Debian live for years. As long as persistence may be used, this is a bug.
You have to delete 'user' to make noautologin work.
Offline
This is common behavior on Debian live for years.
You know this is a Devuan forum? Why do you pick here on the Debian live behaviour? If its a bug file it against the Debian bug tracker.
Offline
You have to delete 'user' to make noautologin work.
No, I don't have to delete 'user', and noautologin does work with or without persistence. I've been doing it this way for about 15 years. Before devuan existed I was doing this with debian. I guess we're not doing the same thing.
I use this to make a live-usb: https://get.refracta.org/files/tools/re … ~4_all.deb
Offline
As I understand (and have observed) how persistence affects live-config:
Each live-config script writes a 'state' file to /var/lib/live/config/ . Each script is configured to exit doing nothing if it's own state file exists, meaning it has already run OR another script has written it's state file in order to disable it (example: slim writes a state file for xinit so xinit's script won't run and cause a conflict)
Therefore, live-config scripts should run only on the first persistence boot. They are then surely disabled because their state files remain in the RW overlay. They are certainly not in the squashfs.
This must also include 'noautologin' parameter, which the relevant live-config display manager script (slim) reads. But only once.
If I got that wrong, someone please enlighten me..
I see no mention in live-config manual about the need to specify a preconfigured live user if that live user is other than 'user', although I know it to be true from experience. Perhaps a documentation bug but no more than. A preconfigured user is valid, script 0030-user-setup checks and exits if found.
If future Devuan live images set the username in /etc/live/config.conf(.d/) of the squashfs there would be no need to use the cmdline.
Last edited by dzz (Today 20:13:51)
Offline