As far as I can tell the whole thing is a matter of some unfortunate timing: My assumption is that the reported specified group 'vboxusers' unknown message is a consequence of the execution of the sudo /sbin/udevadm trigger command in '/usr/bin/tce-load' when the 'virtualbox-ose.tcz' extension gets installed. This extension contains in file '/lib/udev/rules.d/60-virtualbox.rules' an entry of
KERNEL=="vboxdrv", GROUP="vboxusers", ENV{ACL_MANAGE}="1"
The same extension also contains in it's startup file '/usr/local/tce.installed/virtualbox-ose' the two commands which first create the group in question (via addgroup -S vboxusers) and then add the (default) user to that group (via addgroup ${TCUSER} vboxusers).
So far so good, BUT the execution of the startup script of an extension in '/usr/bin/tce-setup' (via the sudo "$TCEINSTALLED"/$2 command, if the installation is NOT for an "onboot case") happens after the execution of 'udevadm trigger'. Well, in case of an "onboot" installation the execution of all startup scripts is even further delayed as they are not executed by '/usr/bin/tce-load' but at the very end of the execution of '/usr/bin/tce-setup' (which itself calls 'tce-load').
I guess any extension that contains kernel modules and hence results in the execution of 'udevadm trigger' will cause the reported message until the 'vboxusers' group becomes available.
Given all this I somewhat fail to see how moving those two 'addgroup' commands into '/opt/bootlocal.sh' or restoring from backup a version of '/etc/group' and '/etc/gshadow' that contains a 'vboxusers' entry would help in avoiding the warning messages. As in '/etc/init.d/tc-config' the execution of '/usr/bin/tce-setup' occurs before the call to '/etc/init.d/tc-restore.sh' and '/opt/bootsync.sh' I'm a bit puzzled over this.
In my testing I've only seen the message twice showing up per boot process and I have as dependencies of 'virtualbox-ose.tcz' the 'graphics-KERNEL.tcz', 'i2c-KERNEL.tcz' and 'virtualbox-ose-modules-KERNEL.tcz' extension that would need to be installed. Additional extensions with kernel modules might trigger the message more often.
I guess in the end it's only important that 'udevadm trigger' gets called once with the 'vboxusers' group in place. OTOH having done this whole exercise mostly in theory I'm not sure which one is the "lucky call" that ends up creating '/dev/vboxdrv', but as long as it still works I'm not going to loose my sleep over it.