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.

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 ;-)

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 ..

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
trond

Thus, 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.

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?

@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=0

username 'devuan'  will be referenced in sudoers, will autologin.. and the system will work normally.

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
user

In 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: ALL

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!

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.

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.

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

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.

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.

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.