Thanks for the review, responses in-line: Alok Aggarwal wrote: > Hi Dave, > > On Mon, 13 Apr 2009, Dave Miner wrote: > >> Caimaniacs, >> >> Please review the fixes for >> >> 6440 Build 106 installer fails to start in 512 MB environment >> 7975 LiveCD still has old branding - desktop background - in B111 >> >> (I've dispensed with links to the above here as the recent webrev updates >> now include d.o.o linkage in the webrev). >> >> webrev for which may be found at: >> >> http://cr.opensolaris.org/~dminer/slim_6440/ >> >> This has been tested extensively on x86, both in live CD and x86 AI >> installations, including in domU's (thanks to John Levon). I'm still in the >> process of testing SPARC, but since it's supposed to be a no-op for SPARC, >> do not anticipate issues. > > DC_defs.py: lines 141-146: I think the following might > read a little better - > > BR_NAME_SPARC = "boot_archive" > BR_NAME_I386 = "x86.microroot" > BR_BASEPATH = "/boot" > BR_FILENAME_SPARC = .. > ..
Yeah, that's a bit more satisfying. Accepted. > > all_lang_slim_cd_x86.xml: line 354: Would "Boot root > archiving (64-bit)" be a better message? > > slim_cd_x86.xml: line 347: Same as above. > Both accepted. > slimcd_generic_live.xml: line 137: Why this change? > We have no need for sendmail-client to run on the CD (which frees up about 4 MB), and the disable of ndp here is ineffective, as the network/routing-setup service always enables it if IPv6 is enabled at all (which is always the case under NWAM). > slimcd_pre_bootroot_pkg_image_mod: lines 130-139: Why > remove this? It seems that it's only a matter of time > before the microroot grows again and so we'll back to > looking for ways like these to curtail the size of the > microroot. > These deviations are generally undesirable to maintain, as they are dependent on implementation details of the particular GNOME version. The direction here is for the desktop group to own providing a reduced-usage session if needed, rather than us building a bunch of hacks into the construction process. The updated branding for 2009.06 meant either xdesign providing a new image for this, or just removing it; looked like about 1 MB of memory usage difference vs. the old branding image, so I judged it better to remove it. > bootroot_archive.py: line 252: s/archive/type > > bootroot_archive.py: line 253: It seems that now that > we're passing the architecture type as an argument, it > would be cleaner to specify "sparc" from the sparc xml > rather than doing this check. > Both accepted. > bootroot_archive.py: lines 267-270: What cases does this > catch that aren't caught by the lines directly above? > For AI, we're going to continue to use the combined 32/64 archive for now. In that case, we're passing "all" from ai_x86_image.xml. > bootroot_strip: line 35, 47: The bootroot_archive script > uses ARCHIVE_MACH whereas this script uses KERNEL_ARCH. Use > one or the other across scripts might be cleaner. > bootroot_archive.py changed to KERNEL_ARCH > bootroot_strip: line 56: Variable unused > Accepted. > ict.py: line 1913: Mostly for my curiosity, will "bootadm > update-archive" still be called on boot_archive so it gets > appropriately updated? > Yes. > --- > > Seems like we should capture the suggestion about reducing > the number of inodes to reduce memory corruption from the > bug report into a separate bug report that can be investigated > post 2009.06. > Yeah, I will do that. I fooled with it some here and it wasn't enough to avoid this work, so I dropped it for now. Dave
