Just an update on this. I have a b127 server serving a b127 repo without problems (after rebuilding the catalog to pickup the change from repo-iso to opensolaris.org - see separate thread for gory details) I also have a b127 server serving a b125 repo. This required me to initially mount the b125 repo read/write so it could update the b125 repo but is now happy in read-only config.
The only problem I have now is that dhcpmgr won't work on sparc. It fails with a Java Virtual Machine error on sparc 127, but runs happily on x86 127. Is this a known issue? Cheers Frank Ethan Quach wrote: > > > Frank Allan wrote: >> Shawn >> >> Is it possible to do an AI install using a b125 AI server and b127 AI >> images or the more general case of build n server and build n+x AI >> images? From what I have seen I believe it is not. >> >> If it is possible, then at least there is a way forward. Otherwise, >> either the release of SPARC boot images should be a much higher >> priority (preferable) or an AI server should support later AI images >> (also preferable in the longer term). > > I think there's some mixing of constraints going on here. An AI server > running build N, is able to serve AI install services (AI images) for > build N+x. (With the caveat of occasional flag days where we might > have to say "To serve these new build X install services (AI images), > your AI server must be updaetd to build X ...") These should be rare, > but do and will occur as we are developing AI. > > In your case, it sounds like the system you're using as your AI server > is also your repo server. If there are constraints on being able to > host an IPS repo containing build N bits, on a server running build N, > then that constraint seems seperate to the constraints of AI from a > technical point of view. > > > -ethan > >> >> The current situation is untenable for enterprise customers. I have >> seen several people proclaim that OpenSolaris is a released product. >> It may be for single-user desktops, but at the moment it is a long >> way from being suitable for large enterprise customers. >> >> Hopefully the direction is to provide at least the functionality >> which currently exists in the Solaris world, where an older OS >> version can host packages or bootable images for later versions. >> >> Cheers >> Frank >> >> Shawn Walker wrote: >>> Frank Allan wrote: >>>> So this makes the offline repository virtually unusable for SPARC >>>> until the elusive SPARC boot image arrives. >>> >>> The offline repository support is an in-development feature like the >>> rest of the package system. >>> >>> From the pkg(1) man page: >>> >>> ATTRIBUTES >>> ... >>> ____________________________________________________________ >>> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >>> |_____________________________|_____________________________| >>> | Availability | SUNWipkg | >>> | Interface Stability | None / Under Development | >>> |_____________________________|_____________________________| >>> >>> Reasonable efforts are made to attempt to maintain compatibility. >>> But it is implicitly assumed that depot server maintainers will stay >>> up to date for now. >>> >>>> Surely you are not going to change the repository format with every >>>> build? I can understand upgrading it occasionally, but without the >>> >>> No, and it does not. But it can and will change as project >>> development progresses. >>> ... >>>> We need something for the pkg tools like the current situation with >>>> the lu packages on Solaris, where you can add the latest lu >>>> packages to an existing OS so you can upgrade to a new version. >>> >>> The pkg(5) project is not yet at a sufficient level of stability to >>> permit this. In particular, project dependencies are sometimes tied >>> to specific packages delivered only in specific OS builds or newer. >>> As such, it is not yet possible to achieve this. >>> >>> Cheers, >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
