On 05/ 5/10 04:49 PM, Jack Schwartz wrote:
Hi Dave.
Thanks for your review.
On 05/ 5/10 10:07 AM, Dave Miner wrote:
On 05/ 5/10 12:45 AM, Jack Schwartz wrote:
Hi everyone.
Here is the final webrev for Driver Update:
http://cr.opensolaris.org/~schwartz/100504/webrev/
Delta since last webrev:
http://cr.opensolaris.org/~schwartz/100504/webrev.3.4.diff/
ai_sparc_image.xml et al:
The package names for the DDU are really the old SUNW-style names
rather than new-style names? That doesn't seem right.
I checked with David Comay, and he said the new names will get resolved
after the DDU team goes to the dock. So for now we have the old names.
Sigh, this seems to have been an oversight in the ARC case, as those
normally include package names.
WRT live-var-pkg*:
Ugh on the service name.
What do you suggest?
Does it really need to be a separate service vs. included in one of
the existing?
I thought about this. I originally thought about including this in the
service which starts the live-io-tracing, but thought it would be
cleaner to remove later if I kept it a separate service (as eventually
IPS will implement the needed fix so this service can then be removed).
The work to do either approach would be similar, as I would have changed
the name of live-io-tracing to be something more general had I gone that
route.
Why there and not in live-fs-root or live-fs-usr, perhaps?
I object to this because you've added >150 lines of code that includes a
new, exposed piece of machinery (a new SMF service) to accomplish
effectively <10 lines of work that seems to fit easily into one of our
existing services. I don't buy the "easier to remove" argument.
Also, were we to continue down the proposed implementation, your new
dependent tag is for console-login, but there's no obvious reason that
is the right dependency; why wouldn't it be auto-installer?
Relatedly, the new SMF service appears to have nothing depending on
it, so how are you ensuring that it will be completed (and as Keith
noted, worked correctly) before DDU or anything else tries a pkg
operation?
Thanks for this. I will put the script into maintenance mode (per
Keith's suggestion) and set up so the final state (e.g. console login)
depends on it.
What's the boot time impact with real media (not in a VM, and not now,
but once you've got proper dependencies in place)?
I will let you know that info, when I have the code in place and send
out a revised webrev.
Do we not need an updated iso sort list since we're presumably doing a
heck of a lot of new I/O to the CD that didn't exist previously?
Actually we are not doing new I/O to the CD. The whole /var/pkg
directory is set up as it was before the /var/pkg move. What was put in
RAM is still there. Likewise for lofi-mounted files. Links to pkg
files in /mnt/misc are still used. The data move is a RAM->RAM copy.
OK, but see below.
I expected that moving /var/pkg would involve it no longer being a
sparse set of links on the boot archive but instead a single link at
the top into a fully read-only copy on solarismisc.zlib. Why is this
approach better, as it seems to leave us with lots of non-writeable
areas in /var/pkg still (and consumes more space on the archive than
the single link would)? A nit that find/cpio is generally preferred
over cp -r since it preserves sparse files. Also, you should be
preserving modes and modification times, which your cp usage does not.
Lots of points here:
1) /var/pkg cannot be completely read-only. pkg requires some of the
files to be RW in order to install new packages. This, combined with
how pkg updates its catalogs is the underlying cause of this whole problem.
2) Which non-writeable areas in /var/pkg are left? I do an rm -rf on
/var/pkg after copying the contents to /tmp. There is only the single
symbolic link to /tmp/pkg remaining in the boot_archive.
All of the symlinks to existing files in /mnt/misc/... That would seem
to make it impossible to update an existing package, which, if we're
going to all this trouble to move /var/pkg around, seems worth allowing.
3) I currently do a cp -rP. The cap P preserves the links to the
/mnt/misc files instead of copying the files to /tmp, so as to preserve
RAM space.
4) I will look into use of find/cpio instead of cp. I will make sure
modes and modification times are preserved.
Thanks again for your review. I will send out a modified webrev when
ready. Sending this to you now in case you have more input in the meantime.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
