Peter Memishian wrote: > > >> "Could not log for svc:/network/linkmgmtd:default: > > >> open(/var/svc/log//network-linkmgmtd:default.log) failed with > > >> No such file or directory." > > >> > > >> Investigation shows the problem is due to a short period of > > >> unavailability of "tmp/root", between the install-discovery script > > >> mounts tmpfs and unpacks all the writable files into /tmp. > > >> > > >> One way to fix this is to split the current install-discovery service > > >> into two services. The first one does the /tmp mount and /tmp/root > > >> initialization, and the second one does the "ifconfig -a plumb" > > >> network data-link discovery. linkmgmtd needs to depend on the first > > >> service and be dependent of the second service. > > I think there's a simpler fix: just remove .tmp_proto/var/svc/log and > tmp/var/svc/log from the miniroot[1].
I can see why we should remove tmp/var/svc/log, but I don't get why we also need to remove .tmp_proto/var/svc/log? If .tmp_proto/var/svc/log is unpacked to /tmp, /var/svc/log should be available and read/write anyway. - Cathy > This should cause svc.startd to use > /etc/svc/volatile instead -- and since /etc/svc/volatile is mounted as > tmpfs early on in boot (in vfs_mountroot()), that directory should always > be writeable. Further, for a netinstall there is no reason to use > /var/svc/log since there's no need for the logs to persist (and since > /var/svc/log is tmpfs, they won't persist anyway). > > Should be easy enough to test this out and verify it works. If it does, > then we can putback the fix to the install gate at any time, since it is > not dependent on the Clearview bits. > > [1] I haven't dug through the code to see what causes these to be created. >
