Yannick Robert wrote: > Hello > > it seems i have the same problem after zfs boot installation (following this > setup on a snv_69 release > http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ ). The > outputs from the requested command are similar to the outputs posted by > dev2006. > > Reading this page, i found no solution concerning the /dev/random problem. Is > there somewhere a procedure to repair my install ?
I've been thinking about the /dev/random problem recently and I think I know what the problem is, but not yet how to fix it. I've cc'd the rest of the crypto team. With a UFS boot there is no attempted use of randomness until after svc://system/cryptosvc has run. That service does two important things, first it starts kcfd to put in place the kernel thread pool for async crypto (not relevant to randomness) and secondly it runs 'cryptoadm refresh' which pushes the (private) /etc/crypto/kcf.conf into the kernel. When /dev/random was initially integrated it was monolithic, that is the randomness pool and the entropy gatherer we combined. Later on when KCF came along we split appart the pool (drv/random) from the software entropy provider (crypto/swrand). Unlike UFS when we do a ZFS boot we do use the in kernel interface to /dev/random (random_get_bytes) before svc://system/cryptosvc has run. The message you are seeing is from KCF saying that it has a random pool but nothing providing entropy to it. This is because swrand hasn't yet registered with kcf. Now this was all done prior to newboot and SMF and part of the goal of why KCF works this way with software providers is was to ensure no boot time performance regressions by doing load on demand rather than forcing the loading of all modules at boot time. With newboot on x86, and soon on SPARC, the swrand module will be in the boot archive anyway. -- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
