Hi Dave.
On 12/08/09 11:07, Dave Miner wrote:
> 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.
So I'm no longer sure we have to do the pkgadm sync, since per your
comments above, it sounds like the rebooted system can automatically
sync up by itself. This question we need to answer first.
To respond to your latest comments: if we do need to call pkgadm sync, I
think it is better that the installer does it.
- Firstly, remember that for live CD, Driver Update only invokes the
DDU. Driver Update isn't a program, per se, so it cannot call pkgadm
sync. DDU would have to call it.
- If the installer did the pkgadm sync instead of DDU, then it could
handle all SVR4 updates including any made by the user manually, not
just those done by the DDU. Processing of all SVR4 packages would be
more consistent.
- The DDU can be run independent of Driver Update. If the DDU called
pkgadm sync, the packages it installed would get different treatment
than other packages added via a straight "pkgadd". Inconsistent again.
- The DDU can be run on environments other than live CD. Here, the SMF
service takes care of calling pkgadm sync, so the DDU doesn't have to.
Overall, all SVR4 packages would be handled by pkgadm sync on a more
consistent and as-needed basis if pkgadm sync were done by the installer
rather than the DDU.
Thanks,
Jack
>
> Dave
>
>> Thank you,
>> Jan
>>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
