autologin on default shell /bin/sh
freebsd at edvax.de
Tue Sep 27 18:13:47 UTC 2011
On Mon, 26 Sep 2011 19:07:47 -0500, Antonio Olivares wrote:
> I had it working (autologin on 8.2 amd64) on two machines, but I
> wanted to test out/install nvidia driver and I used sysinstall to
> install kernel source from 8.2 dvd and then many things I had working,
> like printer, scanner were erased. Shell changed back to /bin/sh, I
> was using bash. For some reason or another, it was not working. I
> did the same thing and now it works again :)
Your autologin configuration is a little bit different from
mine. I'll share and accomodate it to your particular use.
is to be placed _after_ the "default:" entry. This step defines
the "getty profile" for an automated login with the username
"olivares" as associated to the "al=" parameter. Also note
the "tc=" parameter which incorporates the default "Pc"
settings (that you can encounter in the next step's working
In /etc/ttys, the line for ttyv0 is to be changed like this:
ttyv0 "/usr/libexec/getty autologin" cons25l1 on secure
This instructs the "getty" program to use the "autologin
profile" at system startup and automatically log in the
user "olivares" (see step 1).
Attention: Maybe you need a different console configuration;
"cons25" is the system's default. In Germany, I have to use
cons25l1 for the local magic. :-)
There should not be any problem if you have "xterm" there.
Maybe just some terminal capabilities don't work in text
mode, but there should be no effect on autologin functionality.
Make sure you _don't_ have a line calling xdm here - maybe this
In /home/olivares (or where $HOME is located for that user),
make ~/.login end in
[ ! -f /tmp/.X0-lock ] && startx
For bash, this would go to ~/.bash_login. Other shells may
have different startup files; see "man sh", "man csh",
"man bash" and "man <yourshell>" for details.
To become independent from the actual login shell, you can
write this command into a script that is executable by the
user, e. g. "chmod +x /opt/bin/autostartx"; if you have
/opt/bin in $PATH, you just need to call "autostartx" in
the correct startup file. Then _any_ shell startup script
could contain the call that script, like this:
[ ! -f /tmp/.X0-lock ] && startx
You can also make this script local to your user in ~/bin,
maybe you already have that in $PATH.
Attention: This _might_ get you into an "infinite loop" if
something is _really_ wrong. :-)
You can even modify the script to _restart_ X if it should
have crashed, so you don't fall back to the console in
case of a severe error (and enter "startx" again).
Step 4 (optional):
In order to combine the use of xdm (if you want to) and the
different system shells, for your user account there can be
some additional settings.
In ~/.xsession, put
This file will be executed in case xdm is used. I am using the
C shell as a dialog shell here, so this makes sure my shell
settings get incorporated. Then control will be given to the
.xinitrc file, usually executed when you run "startx", but
xdm _may_ have a different opinion.
In ~/.xinitrc, put all your X startup stuff.
[ -f ~/.xmodmaprc ] && xmodmap ~/.xmodmaprc
#xrandr --fb 1400x1050
#xrandr --size 1400x1050
intclock -geometry 186x65+151-0 &
xload -geometry 150x70+0+826 -bg white -fg black -hl gray \
-scale 5 -label "System load" -update 1 &
xmbmon -g 150x100+0+897 -tmin 20.0 -tmax 70.0 -cmtmb CPU \
-cltmb blue -cmtcpu CS -cltcpu cyan -cmtcs SYS \
-cltcs green -vmin 2.0 -vmax 3.0 -cmvc V -clvc red &
xclock -geometry 50x50+50+998 &
xbiff -geometry 50x50+0+998 &
xlogo -geometry 50x50+100+998 -render &
xcpufreq -geometry 183x167+151+826 -cpuscalecolor grey \
-freqscalecolor grey -scales 6 -update 1 -jumpscroll 1 &
xterm -geometry 80x25+0+465 -class NOCLOSE_TERMINAL -fg black \
-bg beige -title Terminal &
xsetroot -solid rgb:3b/4c/7a
xset b 100 1000 15 &
xset r rate 250 30 &
xset s off &
xset -dpms &
The first line (#!) is optional. I'm not fully sure if those
files have to be +x attributes (I _have_ those settings, no idea
where they came from and why they are still here). But it works,
so I don't question it. :-)
> In the beta 2 machine, the /dev/ttys has xterm instead of original
> cons25. Other than that, you are correct with the rest of the
> information. It was strange that someone/some folks have changed
> cons25 to xterm.
Surprises me too, but maybe the console driver now uses
this emulation for I/O... I'm not running 9-BETA here so
I cannot check, sorry.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions