`live.autologin` is enabled even after the installation

[salastro]

Hello,

When I used live.autologin kernel option I noticed that, by default, it enables auto login for default user (anon), but even after installation, the auto login is still for user anon. I think it is possible that someone does not want this behavior, and wants the auto login to work only in the live image. So, I think it is plausible to add an option to allow the change of this behavior. I guess something like

diff --git a/installer.sh.in b/installer.sh.in
--- a/installer.sh.in
+++ b/installer.sh.in
@@ -1245,6 +1245,7 @@ ${BOLD}Do you want to continue?${RESET}" 20 80 || return
         rm -f $TARGETDIR/etc/sddm.conf
         # Remove live user.
         echo "Removing $USERNAME live user from targetdir ..." >$LOG
+        sed -i "s,GETTY_ARGS=\"--noclear -a $USERNAME\",GETTY_ARGS=\"--noclear\",g" $TARGETDIR/etc/sv/agetty-tty1/conf
         chroot $TARGETDIR userdel -r $USERNAME >$LOG 2>&1
         sed -i -e "/$USERNAME ALL=.*/d" $TARGETDIR/etc/sudoers
         TITLE="Check $LOG for details ..."

will do it. I am not experienced with the code base of this project so I believe there are better solutions.

TL;DR: live.autologin enables auto login for anon outside the live image, this behavior should be changed.

Thanks for the time.

[ericonr]

ok, the change is made in dracut/vmklive/adduser.sh:

        sed -i "s,GETTY_ARGS=\"--noclear\",GETTY_ARGS=\"--noclear -a $USERNAME\",g" ${NEWROOT}/etc/sv/agetty-tty1/run

It acts on the run script, not the conf file, which is arguably worse, though it makes sense, since then it affects all services instead of just tty1.

Undoing the change in the installer makes sense to me, if you'd like to open a PR.

Note: this only affects local installs.

[salastro]

It acts on the run script, not the conf file

Actually, the settings was moved from run to conf which made the command useless, I have made a PR to fix that (#207) which was approved by @Vaelatern but did not get merged yet.

Undoing the change in the installer makes sense to me, if you'd like to open a PR.

I think it would be better to open a pull request after that PR gets merged.

[Vaelatern]

It seems the merge pattern for this repository is "just before the next batch of ISOs is produced" which enables better testing.

[salastro]

It seems the merge pattern for this repository is "just before the next batch of ISOs is produced" which enables better testing.

Oh, so it will take some time? I think then I will open another PR and mention that it is related to that other one.

[salastro]

Sorry for the stupid question, but should I make another PR that is based on the previous one or just push a new commit to the already existing PR?

[Vaelatern]

Please open a new PR for the new issue, mention one commit is the same as the other PR.