zeppe-lin / rc Goto Github PK

rc mixes the pool, but no longer counts so as to unlock the kernel's CRNG.

The problem code:

/bin/cat /var/lib/urandom/seed > /dev/urandom

Figure out what can we do to seed the real entropy.
See https://lists.crux.nu/pipermail/crux-devel/2019-June/004108.html and https://git.zx2c4.com/seedrng for possible candidates (seems like any of this solution will require to make the manual page).

The rc.fix file is not documented and perhaps would not be at all. This file contains some X11 font-related checks and is executed by rc.multi.

I consider it ugly (in terms of K.I.S.S. & New Jersey) to include this file in the RC package. Xorg font packages already have post-install scripts that are doing the same thing. May be place rc.fix actions into the /etc/X11/xinit/xinitrc.d/ directory as one of the xinit startup script?

Implement support for sysvinit bootlogd(8) to record boot messages.
Currently only dmesg(8) dump is saved to /var/log/boot (see rc:123).

"Cleanup files" contains /usr/bin/find invocations. That violates «separate /usr» boot.

Find a way how to fix that.

printf (as function, not a binary) is not builtin by POSIX sh(1p) but we're using it.

We have the following printf() references:

$ grep -n printf rc*
rc.multi:16:    printf "starting services:"
rc.multi:18:            printf " %s" $SYSLOG
rc.multi:20:                    printf "%s" "[ERROR]"
rc.multi:23:            printf " %s" "$service"
rc.multi:25:                    printf "%s" "[ERROR]"

An alternative like echo -n is not POSIX too. 😄
If we're trying to refer to the printf as binary (/usr/bin/printf) we're breaking separate /usr boot, since the network setup is one of the service. 😄

By the time, dash(1) that we are using as sh(1) have printf builtin and seems like in the present situation, it is the least of the evils.

Figure out what can be done.

instead of

/usr/bin/setterm -blank 15

it could very well be -blank ${BLANKTIME-15}, with an additional optional BLANKTIME in /etc/rc.conf.

Reference:
https://crux.nu/bugs/index.php?do=details&task_id=1922