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 (Yesterday 20:13:51)
Offline
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.
Because it is relevant for the startup issue this thread is about. Furthermore, the Debian live team may not consider it a bug. E.g. if they are against permanent use of live images with persistence, it may be intended behavior. It makes safe use of this more difficult.
Furthermore, we are here to work on alternatives to upstream decisions. At least that was my understanding.
Offline
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)
Thank you for pointing to the mechanisms in use here!
Offline
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.
Are you talking about basic Poor Man's install (PMI) here? That is my use case, and it seems yours is different.
Here is the situation straight from Devuan boot on my ordinary PMI. I haven't had the chance to login...
user@devuan:~$ cat /proc/cmdline
boot=live config quiet splash initrd=(hd0,0)/boot/dev611/initrd.img bootfrom=/dev/sda2 live-media-path=dev611/live0 persistence persistence-path=dev611s/pers0 keyboard-layouts=no noautologin
user@devuan:~$ whoami
userIn a PMI, the live squashfs is copied to hard disk, a persistence volume is prepared, and the original kernel and inird is used for booting. I haven't done any modifications, and if the noautologin directive is honored, which it is not at present, there is no need for further modifications for a rather general use case.
The only way for me to make it work 'out of the box', is deleting the user 'user'. Which is not defined by default in Devuan, I created it for testing. So the bug (which may very well be intentional from the Debian live team) is masked in the default setup.
But it is prepared for 'user', this is the unmodified content of the sudoers extension file:
user@devuan:~$ sudo cat /etc/sudoers.d/live
user ALL=(ALL) NOPASSWD: ALLOffline
Small update:
User 'user' may not be removed safely in the current 6.1.1 release, if it is defined.
I could kill Xfce, which ran as a 'user' process, log in as devuan and delete user 'user'.
But it is clearly noted somewhere. For at next boot, display stayed black - a strong indication that there are remnants of 'user' that block the noautologin directive.
I also tried to modify the configuration scripts, with no luck.
For all the people happy with this state of affairs, you have my empathy. I will not expand on how and why ;-)
Offline
/etc/sudoers.d/live does not exist in the squashfs. It is written dynamically on first boot by /lib/live/config/0040-sudoers .
I haven't done any modifications
@tyder, yes you have, at least inadvertantly. You have booted with incorrect cmdline parameters (omitting 'username=devuan') while using persistence.
If you boot with a new, clean persistence volume using the parameters as configured in the ISO's boot menus:
boot=live username=devuan nottyautologin apparmor=0username 'devuan' will be referenced in sudoers, will autologin.. and the system will work normally.
Offline
You have booted with incorrect cmdline parameters (omitting 'username=devuan') while using persistence.
For me, that's a buggy system. Because it violates the 'principle of least surprise'.
Hard-coding a username in a bootloader commandline is bad practice in my opinion. This should work well with only noautologin, and eventual privileges etc should IMO be fixed with a transparent CLI script.
Eventual transitions to persistence running should also be made transparently IMO. What are the advantages of doing this behind the scenes?
Offline
Somewhat larger update. Think we can consider the problem solved. Still with warts and all :-)
I followed dzz's advice, and that worked. Seems that the username parameter must be used for the conversion to proceed correctly.
I'm very gratefui! Tanks!
When that user is in place, the Debian default 'user' is harmless. May be added and removed without problems, it seems. The noautologin directive works.
And it is _not_ necessary to use the username=devuan parameter afterwards, as shown here:
trond@devuan:~$ cat /proc/cmdline
boot=live config quiet splash initrd=(hd0,0)/boot/dev611/initrd.img bootfrom=/dev/sda2 live-media-path=dev611/live0 persistence persistence-path=dev611s/pers0 keyboard-layouts=no noautologin
trond@devuan:~$ whoami
trondThus, a system boot may be set up without the username parameter, it is only necessary to add it to the cmdline at first startup.
Because this may be kind of trap for new users, and it definitely violates the principle of least surprise for many, it may be regarded as kind of bug. Doing it explicitly, with prompt, at first login as devuan would be better IMO.
Offline
Well done @tyder, you got most of it if not quite all:
When that user is in place, the Debian default 'user' is harmless. May be added and removed without problems, it seems. The noautologin directive works.
And it is _not_ necessary to use the username=devuan parameter afterwards
When a different username is configured, the Debian default 'user' does not even exist, unless you created it manually.
The noautologin parameter is unavailable after first boot if using persistence because live-config is disabled.
The username=* parameter is unavailable after first boot if using persistence for the same reason.
BTW 'keyboard-layouts' is also unavailable for the same reason.
The persistence manual is actually in live-boot not live-config ..
Last edited by dzz (Today 14:45:52)
Offline
When a different username is configured, the Debian default 'user' does not even exist, unless you created it manually.
The noautologin parameter is unavailable after first boot if using persistence because live-config is disabled.
The username=* parameter is unavailable after first boot if using persistence for the same reason.
BTW 'keyboard-layouts' is also unavailable for the same reason.
This does not at all fit with my ca 13 yrs experiences with Debian live with persistence. And before that, a long time with Debian-derivative Knoppix.
Keyboard-layouts and autologin may surely be useful with persistence, so forcing them to be shut off doesn't make much sense to me.
There are lots of very different use cases where persistence is necessary or at least useful. So one size, in the way it is enforced here, does definitely not fit all.
But of course, software freedom is also for being very content with what is offered ;-)
Offline
For the record:
Most people around here may not know the term 'PMI' (poor man's install). Far as I'm aware it originated from Knoppix. AntiX call it 'frugal install'. Klaus Knopper was the trailblazer of 'live' systems early 2000's whose work preceeded both Ubuntu's Casper and (later forked and evolved from casper) Debian's live-boot. Knoppix was where my journey into live ISO's began.
'PMI' simply means booting a live iso located on disk with a persistence overlay. Either directly or from the extracted squashfs, vmlinuz and initrd.
Offline