|
Description
|
SST can't do any automatic flash-installs of snv_83a(RE) without hacking. The problem is that /sbin/dlmgmtd depends on existence of /etc/.dlmgmt_door. There is a CR 6664002 - "pkgchk -n issue with /etc/.dlmgmt_door with SUNWcsr in snv_83" related which copes with a runtime change of /etc/.dlmgmt_door type from "f" to "D". It is delivered as a regular file and than changed to door by /sbin/dlmgmtd. Flar doesn't transfer doors and /etc/.dlmgmt_door is silently excluded from the archive. Later on, on the first reboot, /sbin/dlmgmtd exits with retval 95* and svc:/network/datalink-management:default is transfered to maintenance and system waits for a manual intervention on the console (without any network connectivity).
Here is a console log snippet:
SunOS Release 5.11 Version snv_83 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
WARNING: High-overhead kmem debugging features enabled (kmem_flags = 0xf). Performance degradation and large memory overhead possible. See the Solaris Tunable Parameters Reference Manual.
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/Hardware watchdog enabled
Feb 21 07:55:54 svc.startd[7]: svc:/network/datalink-management:default: Method "/lib/svc/method/svc-dlmgmtd" failed with exit status 95.
Feb 21 07:55:54 svc.startd[7]: network/datalink-management:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details)
Hostname: XXXXXX
Requesting System Maintenance Mode
(See /lib/svc/share/README for more information.)
Console login service(s) cannot run
Root password for system maintenance (control-d to bypass):
Could the submitter provide more details about how the automatic flash
install process works and where precisely the issue is? Are we talking
specifically about the flarcreate command, or something else? Assuming
we're talking about flarcreate, it appears flarcreate's "fdo" command
(/ws/install-nv-gate/usr/src/cmd/inst/flash/fdo) has its own exclusion
logic for doors unrelated to pkgchk.
Regarding fdo: from the comments in the source, it seems that it's
skipping doors because cpio and pax cannot handle them, which means
that we may have bumped into a design flaw with no good solution
(though for now as a workaround one could temporarily disable the
datalink-management service as part of /etc/flash/precreation and
enable it again in /etc/flash/postdeployment).
However, given this and the pkgchk issue, we should explore whether the
dlmgmtd door logic can be changed to work more like other daemons. The
core need for the existing design is that dlmgmtd runs before /etc is
writable and thus cannot create the door file itself. However, it might
be possible for it to create the door in /etc/svc/volatile, which is
tmpfs and thus writable early in boot. It appears that the SMF
repository_door already exists in /etc/svc/volatile (as an aside, if we
go with this approach, .dlmgmt_door should probably become dlmgmt_door).
Yes, we are talking about flar create. Flar skips doors and at the same time it doesn't know about the purpose of /etc/.dlmgmt_door. When a machine boots for the first time after the installation there is no /etc/.dlmgmt_door in the system.
Flar ignores for some reasons special files and it might be a flar's weakness but from my point of view it would be much nicer (and sensible) to solve it inside dlmgmtd and that's why I filled the bug against dlmgmtd.
|
