We can't call this issue a bug, to be precise this is a behaviour change into the kernel about random features. Without entering in deeply explanations, /dev/random is populated by the kernel itself with entropy. Old kernel have a different behaviour concerning this pseudorandom number generators. Kernel should block until this file is not populated entirely. To populate it events on the machine is used to have random numbers, events such a keyboard use, plugin a devices,disk access etc. This is why when we switch between tty, the tty appear more quickly. Is not the fact to switch between them but the use of the keyboard which create more entropy.
So now, we need at boot time to make a choice between rapidity and security.
1)
/dev/random is used by critical services where it's important that the random numbers they use aren't predictable at all. In this case we need to wait a full entropy pool. This is exactly the role of s6-fullfillrandompool, this API will block until the /dev/random file was completely populated. In this case the boot will take time and that's why tty do not appear instantly. The wasted time can be improved if we use some service like haveged which "create entropy".
2)
If we don't use such critical services we can use /dev/urandom ('unlimited', non-blocking) which is the case by default with Obarun. So the boot will go more faster but can be "less secure".
Now, @ marianarlt a new patched release of 66 is available on the 66-repo, this release should fix the bug concerning the haveged earlier service that you reported. So please, test with the following:
update 66 package
change your rwfs-random @ execute field by this one
if { s6-echo -- rwfs-random started }
foreground
{
redirfd -w 1 /dev/urandom
pipeline { if { s6-clock } s6-clock }
sha512sum
}
if { s6-fillurandompool }
s6-echo -- rwfs-random successfully started
and add the haveged service to your boot tree
# 66-enable -t boot haveged
tell us what's happen.