Bugzilla – Bug 8647
devices not usable immediately after install
Last modified: 2009-11-16 18:20:01 UTC
You need to log in before you can comment on or make changes to this bug.
After installing the CIFS server, the smbsrv driver needs to be removed and re-added before the service will start. Alternatively, the machine needs to be rebooted. Ideally, the smb/server service would start successfully after installation. See the URL for more details.
We update all the files associated with a driver, but we don't complete the task and load the driver, which is necessary for the driver to start working. The reason we don't is that loading the driver means running code that you just installed, and we're a bit paranoid about that, but there's pretty much nothing else we can do. You should be able to work around this by running "devfsadm -i smbsrv" (or whatever the name of the driver is), though for some drivers, this might not be enough.
The need to reboot OpenSolaris is also an issue with the IPS package 'avs', although not an issue for AVS in SXCE. Manually performing the following before invoking 'dscfgadm' for this 1st time is is a work-around. rem_drv ncall rem_drv nsctl rem_drv nskern add_drv ncall add_drv nsctl add_drv nskern
As I said earlier, you should be able to do this without rem_drv and add_drv, especially since you don't want to muck with the driver databases -- the rem_drv calls will remove the entries from minor_perm, extra_privs, and possibly devlink.tab, while your add_drv invocations won't add them back. Please try using devfsadm -i nskern devfsadm -i ncall devfsadm -i nsctl devfsadm -i sdbc (the last is delivered by the same package as the other three) instead; if it doesn't do the job properly, I'd like to know before I make that automatic.
For each of the following commands: devfsadm -i nskern devfsadm -i ncall devfsadm -i nsctl devfsadm -i sdbc each fails with the following error message: devfsadm: driver failed to attach: .... A couple of observations: - If OpenSolaris is rebooted after installing the "avs" packages, everything OK. - If the rem_drv / add_drv commands are invoked, AVS works without a reboot. - Even if the rem_drv commands "... muck with the driver databases ..." after the next, or any future reboots AVS works. - If instead of using the IPS based "avs" packages, I use the SRV4 packages from the corresponding Nevada build, this same type of driver loading defect exists. These leads me to the conclusion that the repackaging of AVS's SRV4 packages as new IPS packages is not defective, but something in how (pseudo) device drivers exists in devfs. So far my preliminary investigation into this shows the "ls -lt" and "find /dev -ls" can see the newly installed (pseudo) device drivers, but that open() of one of the seen devices, fails.
The AVS aspects of this are important for Solaris Cluster Geographic Edition, since one of the key features of SCGE is that it can be added/removed/upgraded without requiring a reboot with the attendant dent in availability figures.
The (Install) Driver Update project needs this to be fixed. Installers run from a live CD or off the net, and so a reboot is not possible. Driver actions must be enhanced to complete the driver configuration job by loading the driver binary and activating the device(s) the driver operates. After having talked with people on both the driver and pkg teams, I filed bugster bug: 6885060 Provide a way other than reboot to activate drivers installed with add_drv -n to provide the needful for the driver actions to be able to load driver binaries safely as part of an install.
P1s are for bugs which need to be fixed in the current build so I'm lowering this to a P2 which is still correct for bugs that need to be fixed in the next release.
Bug 6885060 was fixed in build 127, so we can start using the interfaces delivered by that fix.
*** Bug 12694 has been marked as a duplicate of this bug. ***