Questions on FreeBSD Installerconfig and firstboot

[bobafett]

I was experimenting with installerconfig and I added adduser at the end of installerconfig before powering off. It worked great.

I've built a custom iso (just changed the kernel name) and I wanted the adduser prompt to come up post installation before login prompt so I added a firstboot rc.d script with just adduser. It showed up before login prompt, post installation boot. And I saw the directories in the skel - it was exactly what I wanted but then I did a reboot and logged in as the same user and I got this message:

No home directory. Logging in with home = "/"

This thing happens if I do this post installation and with firstboot. The /home directory just disappears. Never happens with installerconfig.

PS. I also want to know if it's possible to launch a twm session at the end of installerconfig before I shut it down.

This is my adduser.conf:

udotdir=/usr/share/skel
defaultgroups="video operator"
defaultshell=/usr/local/bin/zsh

I also added homeprefix=/home in the adduser.conf earlier but didn't seem to make any difference. I'm not sure what is happening.

I'm in FreeBSD 14.3.

 

[T-Daemon]

I added a firstboot rc.d script with just adduser.

To create /home/<user> directories by adduser(8) from a system startup rc(8) script, the file system has to be mounted first. Accordingly the # REQUIRE: FILESYSTEMS keyword should be set (see rc(8) and /etc/rc.d/FILESYSTEMS for description):

Example firstboot_sentinel (rc.conf(5)) rc(8) script:

/etc/rc.d/firstboot

#!/bin/sh
#
# REQUIRE: FILESYSTEMS
#
adduser

PS. I also want to know if it's possible to launch a twm session at the end of installerconfig before I shut it down.

This shouldn't be a problem as long as xorg, twm, a specific (drm-kmod (Intel, AMD), nvidia-driver), or generic (xf86-video-scfb) video driver is installed, a xorg video driver configuration file created, and startx is executed, all from the installerconfig script.

 

[bobafett]

To create /home/ directories by adduser(8) from a system startup rc(8) script, the file system has to be mounted first. Accordingly the # REQUIRE: FILESYSTEMS keyword should be set (see rc(8) and /etc/rc.d/FILESYSTEMS for description): Example firstboot_sentinel (rc.conf(5)) rc(8) script: /etc/rc.d/firstboot

 #!/bin/sh # # REQUIRE: FILESYSTEMS # adduser

This shouldn't be a problem as long as xorg, twm, a specific (drm-kmod (Intel, AMD), nvidia-driver), or generic (xf86-video-scfb) video driver is installed, a xorg video driver configuration file created, and startx is executed, all from the installerconfig script.

Thanks for the help, I'll give it a try. The REQUIRE: FILESYSTEMS part was something I didn't know about.

 

[bobafett]

To create /home/<user> directories by adduser(8) from a system startup rc(8) script, the file system has to be mounted first. Accordingly the # REQUIRE: FILESYSTEMS keyword should be set (see rc(8) and /etc/rc.d/FILESYSTEMS for description):

Example firstboot_sentinel (rc.conf(5)) rc(8) script:

/etc/rc.d/firstboot

#!/bin/sh
#
# REQUIRE: FILESYSTEMS
#
adduser

This shouldn't be a problem as long as xorg, twm, a specific (drm-kmod (Intel, AMD), nvidia-driver), or generic (xf86-video-scfb) video driver is installed, a xorg video driver configuration file created, and startx is executed, all from the installerconfig script.

I've actually tried it and it worked! Thanks! I now ran into an issue related to the same workflow. Here's basically what I'm trying to achieve with the firstboot script (not during installerconfig but post-installation firstboot xorg session):

1. adduser launches into an xorg session
2. user creates account
3. Exits

then,
a. xdm appears
b. Newly created user can login

But it seems the process is flaky: instead of the xdm appearing, it sometimes gets into a ttyv07 or some random tty.

This is my firstboot:

#!/bin/sh
#
# PROVIDE: firstboot
# REQUIRE: FILESYSTEMS
# BEFORE: LOGIN xdm
# KEYWORD: firstboot

. /etc/rc.subr

name="firstboot"
start_cmd="firstboot_start"

firstboot_start() {
    chmod +x /root/.xinitrc

    export PATH="/usr/local/bin:/usr/bin:/bin"

    su - root -c 'PATH=$PATH; xinit /root/.xinitrc -- :1 vt09'
    
    /bin/sleep 2
}

run_rc_command "$1"

and this is my xintirc for root:

#!/bin/sh
twm &
xterm -geometry 80x24 -e /usr/sbin/adduser

It works sometimes and sometimes doesn't resulting in random ttyv0*. I feel like it's a race condition thing, I tried killing Xorg processes in the firstboot script after xinit, adding sleep at the end, and even changing the vt numbers in firstboot (like vt09) and xdm (

:0 local /usr/local/bin/X :0 vt08

on Xservers in xdm but still ran into the same issue. Also, xdm is already enabled in /boot/loader.conf.

I'm not sure what's causing this.

 

[T-Daemon]

It works sometimes and sometimes doesn't resulting in random ttyv0*. I feel like it's a race condition thing,

Your "firstboot" scripts component "xinit" complains about not finding a library when tested in a 14.3-RELEASE VM. Works fine when setting the script to be executed in a later stage (REQUIRE: FILESYSTEMS nfsd).

But why start an entire Xorg session to launch a window manager, execute "xterm", just to call "adduser"? Moreover as "root".

How do you ensure that the correct video driver is installed, configured, and loaded in order to be able to start an Xorg session in the first place (unless the hardware is always the same) ? Intel, AMD require different video drivers and different configurations.

Wouldn't it be easier to call "adduser" in the console instead of in an xorg/xterm session? Or, dialog menu guided "bsdconfig useradd".

And, regarding XDM, apparently it expects a ~/.xsession file when the user logs in. How is this handled in the below setup?

1. adduser launches into an xorg session
2. user creates account
3. Exits

then,
a. xdm appears
b. Newly created user can login

Also, xdm is already enabled in /boot/loader.conf.

Surely you mean "enabled in /etc/rc.conf".

 

[bobafett]

But why start an entire Xorg session to launch a window manager, execute "xterm", just to call "adduser"? Moreover as "root".

Because in my custom FreeBSD ISO, I'm trying to create a GUI user creation experience post-installation, I'm testing it out with adduser and xterm just so I get the basics right, will create a GUI later, with zenity or something with gtk. New user creates an account signs in as that account.

How do you ensure that the correct video driver is installed, configured, and loaded in order to be able to start an Xorg session in the first place (unless the hardware is always the same) ? Intel, AMD require different video drivers and different configurations.

My custom iso already has the GPU drivers and configs. Hardware will always be the same. This part is sorted.

And, regarding XDM, apparently it expects a ~/.xsession file when the user logs in. How is this handled in the below setup?

There's an ~/.xsession file in /usr/share/skel/.

Surely you mean "enabled in /etc/rc.conf".

My bad!

 

[T-Daemon]

It works sometimes and sometimes doesn't resulting in random ttyv0*. I feel like it's a race condition thing

I can't reproduce. The (modified) script (see below) has not shown the problem you described even once. The xserver always starts in ttyv8. Has /etc/ttys perhaps been modified?

Again, works fine for me when # REQUIRE: FILESYSTEMS nfsd. When FILESYSTEM only is set, "xinit" complains about a missing library. May be a file system read issue (ZFS on the test system). Executing the script in a later boot stage works as expected.

The dependency order of rc(8) script execution can be checked with rcorder /etc/rc.d/* /usr/local/etc/rc.d/*. Your original script is executed in an earlier stage.

 

[bobafett]

I can't reproduce. The (modified) script (see below) has not shown the problem you described even once. The xserver always starts in ttyv8. Has /etc/ttys perhaps been modified?

Again, works fine for me when # REQUIRE: FILESYSTEMS [B]nfsd[/B]. When FILESYSTEM only is set, "xinit" complains about a missing library. May be a file system read issue (ZFS on the test system). Executing the script in a later boot stage works as expected.

The dependency order of rc(8) script execution can be checked with rcorder /etc/rc.d/* /usr/local/etc/rc.d/*. Your original script is executed in an earlier stage.

Thanks a lot for the info and testing it. I tested this out again with the modified script and can't seem to reproduce it either. No ttys wasn't modified. It's probably a mistake from my side or I messed something up earlier and ended up in a wrong tty0*!

I'll also take a look at the ordering:

rcorder /etc/rc.d/* /usr/local/etc/rc.d/*