Jan Damborsky wrote: > Dave Miner wrote: >> Jan Damborsky wrote: >>> Sanjay G. Nadkarni wrote: >>>>> <div id="jive-html-wrapper-div"> >>>>> >>>>> Hi everyone.<br> >>>>> <br> >>>>> Sorry for the late response. I just saw >>>>> this...<br> >>>>> <br> >>>>> Live CD isn't always a throw-away environment, as the >>>>> booted >>>>> environment is cpio-ed onto a target hard drive when >>>>> installed. Driver >>>>> Update is a project which takes advantage of this, >>>>> using the DDU to >>>>> install missing drivers in the booted environment, >>>>> before the booted >>>>> environment is cpio-ed to the hard drive.<br> >>>>> <br> >>>>> DDU (Device Driver Utility) will be enhanced to >>>>> install SVR4 packages >>>>> to get drivers. The contents file will need to >>>>> be accurate on the hard >>>>> drive w.r.t. these SVR4 packages.<br> >>>>> <br> >>>> Even with DDU, LiveCD by definition is a throw away environment. If >>>> for instance the system reboots the user will have to redo all the >>>> pkgadds. So there's no need for the contents file to consistent across >>>> reboots. >>> Hi Sanjay, >>> >>> I agree that we don't need to keep contents file consistent across >>> reboots (and thus pkgserv SMF service can be disabled), but >>> as Jack pointed out, since contents file on target is the one copied >>> from LiveCD, I think we need to keep it consistent for the installation. >>> >>> I concur with Jack that it could be done by calling 'pkgadm sync -q' >>> before CPIO transfer phase begins - it would force pkgserv daemon >>> to flush the log file into contents file making sure that contents >>> file is accurate. >>> >> It's not clear to me why this needs to be done in the live CD >> environment. The contents log would also be copied by the >> installation process and can then be sync'ed during first boot by the >> pkgserv service. > > To be honest, I am not sure if there might be a space for race condition. > Might it be possible that pkgserv daemon decides to flush the contents > log into contents file in the middle of CPIO operation ? Then theoretically > contents log and/or contents file might get out of sync. > But since I am not familiar with the internals, CCing Casper who might shed > a light on this. >
Unless the installer deliberately holds a lock that prevents any SVR4 package operations (including a sync) during the critical region, yes, there's a possible race. The realistic case we care about here is that the ops done by driver update are not subject to such a race. Having driver update execute a pkgadm sync at the conclusion of each op would be a simple way to handle this, I think. Dave > Thank you, > Jan >
