zfs discuss - Jun 2007 - /dev/random problem after moving to zfs boot:

I have one thing happening now at boot which must have happened during the
migration to zfs boot. I get an error message about /dev/random: "No
randomness provider enabled for /dev/random. Use cryptoadm to provide one."
Does anyone know how to fix this?

Another thing: Is it possible to upgrade to a higher build when using zfs boot?
Is this what LiveUpgrade does? And is there a step by step instruction on how to
use LiveUpgrade with zfs boot?
 
 
This message posted from opensolaris.org

Hi Nicolas,

Nicolas Linkert wrote:
> I have one thing happening now at boot which must have happened 
 > during the migration to zfs boot. I get an error message about
 > /dev/random: "No randomness provider enabled for /dev/random.
 > Use cryptoadm to provide one." Does anyone know how to fix this?

Yep, Constantine spotted this before as well - see Darren''s response
at http://www.opensolaris.org/jive/thread.jspa?threadID=28795&tstart=195

Oh, wrt. the sharetab part of that mail, I think the zfs-boot install
script I had wasn''t creating a mountpoint for the new sharetab mount
that went in recently, I need to update that at some stage.
> Another thing: Is it possible to upgrade to a higher build when 
> using zfs boot? Is this what LiveUpgrade does? And is there 
> a step by step instruction on how to use LiveUpgrade with zfs boot?
Unfortunately not yet - I''ve been simply doing fresh installs
of Solaris, preserving the slices with ZFS pools I want to keep data
from, and then re-setting up my ZFS root install after that.

If you''re using the zfs-actual-root-install.sh, and want to install to
an existing pool, you can create your filesystem first, the set the
$ROOT_FS environment variable to the filesystem you''d like to install
ZFS root on (assuming that filesystem is contained in a pool with a
supported configuration)

Eg. after a reinstall/upgrade do:

  * remove any old zfs root entries from /etc/vfstab
     if you did an upgrade

  * zpool import tank, if you did an fresh install

  # zfs destroy tank/old-root-fs
  # zfs create tank/new-root-fs
  # ROOT_FS=tank/new-root-fs
  # export ROOT_FS
  # ./zfs-actual-root-install.sh foo

Alternatively, you could boot back into ufs-root, perform a LiveUpgrade
of that, and again re-setup your root pool. Not ideal but it should
work.
	cheers,
			tim

What about the /dev/random issue? Is there any way to fix this? I''d be
delighted to name a provider with cryptoadm, but I have no clue at all how this
works ...
 
 
This message posted from opensolaris.org

***************************************************************

# cryptoadm list -p 

Provider at user level:
====================/usr/lib/security/$ISA/pkcs11_kernel.so: All mechanisms are
activated.
/usr/lib/security/$ISA/pkcs11_softtoken.so: All mechanisms are activated. random
is activated.

Kernel software provider:
=========================des: All mechanisms are activated..
aes: All mechanisms are activated..
arcfour: All mechanisms are activated..
blowfish: All mechanisms are activated..
sha1: All mechanisms are activated..
sha2: All mechanisms are activated..
md4: All mechanisms are activated..
md5: All mechanisms are activated..
rsa: All mechanisms are activated..
swrand: random is activated.

Kernel hardware provider:
=========================
******************************** ********************************

# cat /etc/crypto/kcf.conf
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets "[]" replaced with your own identifying
# information: Portions Copyright [yyyy] [name of copyright owner]
#
# CDDL HEADER END
#
#
# Copyright 2007 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)kcf.conf 1.10 07/04/10 SMI"
#
# /etc/crypto/kcf.conf
#
# Do NOT edit this file by hand. An administrator should use cryptoadm(1m)
# to administer the cryptographic framework. A developer for a kernel software
# provider package or a cryptographic provider device driver(s) package should
# provide an input file and use the {i,r}.kcfconf class action scripts to
# update this file during the installation and removal of the package.
#
# This document does not constitute an API. The /etc/crypto/kcf.conf file may
# not exist or may have a different content or interpretation in a future 
# release. The existence of this notice does not imply that any other 
# documentation that lacks this notice constitutes an API.
#
# 
#
# Start SUNWcsr
des:supportedlist=CKM_DES_CBC,CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB<
br>aes:supportedlist=CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR
arcfour:supportedlis t=CKM_RC4
blowfish:supportedlist=CKM_BLOWFISH_ECB,CKM_BLOWFISH_CBC
sha1:supportedlist=CKM_SHA_1,CKM_SHA_1_HMAC_GENERAL,CKM_SHA_1_HMAC
sha2:supportedlist=CKM_SHA256,CKM_SHA256_HMAC,CKM_SHA256_HMAC_GENERAL,CKM_SHA384,CKM_SHA384_HMAC,
CKM_SHA384_HMAC_GENERAL,CKM_SHA512,CKM_SHA512_HMAC,CKM_SHA512_HMAC_GENERAL
md 4:supportedlist=CKM_MD4
md5:supportedlist=CKM_MD5,CKM_MD5_HMAC_GENERAL,CKM_MD 5_HMAC
rsa:supportedlist=CKM_RSA_PKCS,CKM_RSA_X_509,CKM_MD5_RSA_PKCS,CKM_SHA1
_RSA_PKCS,CKM_SHA256_RSA_PKCS,CKM_SHA384_RSA_PKCS,CKM_SHA512_RSA_PKCS
swrand: supportedlist=random
# End SUNWcsr
# Start SUNWdcar driver_names=dca
# End SUNWdcar

***************************************************************
***************************

# dd if=/dev/random bs=10 count=1 | od -x
1+0 datasets in
1+0 datasets out
0000000 285a 16c1 e017 b6ee 05eb
0000012

********************************************************
***********************************
 
 
This message posted from opensolaris.org

I think the problem is a timing one.  Something must be attempting to 
use the in kernel API to /dev/random sooner with ZFS boot that with UFS 
boot.  We need some boot time DTrace output to find out who is 
attempting to call any of the APIs in misc/kcf - particularly the random 
provider ones.

It seems like the problem resolves itself later since the output you 
sent indicates that /dev/random is all working correctly by the time you 
have shell access available.

--
Darren J Moffat