Given a set of full+OEM packages for a particular architecture, and the cluster definitions and install software of course, what tools (I hope you guys don't do it by hand) are used to build CD and DVD images? (not counting mkisofs or mkfs -F udfs or the like, just what's used to generate the directories from which the images are made)
If those tools were open (if they aren't already), and the full capabilities of the present (and future, when Caiman is ready) installer were understood, along with what points between packages were suitable for a media change, then perhaps the community could better participate in the development of more automated means of generating media images, download files, etc for more different distribution formats, installation methods, etc. For example, customized installation CDs could be generated by customers (for their own use) that had widely dispersed and varied systems on isolated networks or with very limited bandwidth (making distribution of tailored flash images on media impractical, and JumpStarts impossible or impractical); perhaps they might want to trim out certain packages (deemed unnecessary or inappropriate), use .gz rather than .bz2 compression (faster access in many cases), or make certain other tweaks. As long as they did it properly, the same packages would install as if they'd used the standard media but chosen the packages by hand at installation time, so the resulting installation (although not their customized media or installation methods) should be just as supportable as if an installation that produced identical results had been done from the standard media. (a separate installation validator that checked signatures, dependencies, special hardware or configuration requirements, etc should be able to confirm that, and might perhaps even be run as the final step of such a customized installation to indicate that it was indeed qualified for support) As for new or variations on techniques, imagine a LiveCD that could both report on the hardware that an installation would and wouldn't support, and then, if the network interface over which to install was supported (might or might not be esp. for WiFi), offer a minimal preview mode or a network based installation mode which could be stopped at any point (although it would actually only stop between packages) and by writing to disk a file with the options chosen and progress to date, would be able to be resumed where it left off later (by checking for that file, and validating and using the contents). That could make an install via WiFi (or at least forward progress on it while one's battery held up and one was in range) on a laptop more or less practical. Or imagine something that built flash card images for appliances. My dream appliance would have the option for a 2nd otherwise identical boot media flash card, to allow something very much like LiveUpgrade, with a watchdog timer and extra eeprom or similar setting to indicate fallback media in case of a failed boot, maybe a connectivity test on first boot of new installation media (with fallback to old media again), etc. That could allow reliable remote upgrade of well-connected but physically inconvenient to access appliances and together with other features supporting remote administration, allow physical access throughout the support cycle to be kept down to when replacement of failed redundant parts was needed or on-site diagnosis could not be avoided. Great for dispersed storage, store-and-forward, infrastructure (name or authentication services, network monitoring), specialized server or data collection appliances, kiosks, etc. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
