Hi Dave and Keith.
Updated webrevs based on your comments are here:
Revised full: (same location)
http://cr.opensolaris.org/~schwartz/100504/webrev/
Delta webrev vs yesterday's:
http://cr.opensolaris.org/~schwartz/100504/webrev.4.5.diff/
Basically I check return statuses now in the svc script, and I added
dependent clauses in the service bundle.
- - -
I took measurements of time differences with the all lang slim CD, and
there was no appreciable change. In fact, the time was a few seconds
less with my changes, probably due to media or other differences.
Without the new smf service:
From grub selection to login prompt: 1:50
From grub selection to first blue screen: 3:21
With the new smf service:
From grub selection to login prompt: 1:50
From grub selection to first blue screen: 3:17
Thanks,
Jack
On 05/ 5/10 01: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.
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.
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.
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.
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.
Jack
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
