Hi Alan,
Please see my response inline.
On 11/16/11 03:34 PM, Alan Steinberg wrote:
Again maybe naive questions, but:
On 11/16/11 14:52, Karen Tung wrote:
Hi Alan,
DC requires the OS version to be the same as the image that's being
built because DC
executes commands during the build process. For example, the svccfg
command is used
for pre-loading the SMF repositories.
Is this assuming the svccfg interface is going to change? I'm
assuming that S11 interfaces are now stable. What exactly is required
that cannot be accessed from elsewhere?
Most of the problems we ran into previously are related to change in
interfaces.
In the past, we tried to execute all commands
from DC's build area, and we also setup the LD_LIBRARY_PATH to point
to the libraries
in DC's build area, since we do have all the latest binaries there.
There's no need to mount another BE like you suggested.
This works most of the time, but it does not cover all cases. For
example, if a command
running from DC's build area relies on a kernel module that's newer
than the one on the system, we can't load and use that module in real
time.
So in order to create a bootable ISO image, the kernel modules that
will be used must also be run from the live system?
No, that's not what I meant. What I meant is that even if we change DC
to run the command's from DC's build area,
and setup the LD_LIBRARY_PATH to use the libraries from DC's build area,
there might still be cases where
a command is making calls to kernel modules, and those "corresponding"
kernel modules used by the command
are not loaded into the system running DC.
Other examples of incompatibility is if the command requires an
updated configuration
file in the OS, we can't point it to that either.
Why does the configuration file have to be on the live OS?
Sorry, I guess configuration files are not the right term to use here.
I meant other data files.
One time, I ran into a problem where a manifest used by a SMF service is
updated, and
while importing that SMF service, it's trying to use the manifest on the
build system instead
of the updated one in DC's build area. So, what I say configuration
files earlier, I was trying to refer
to other data files certain commands might need to refer to.
Therefore, we decided that the safest thing to do is to always build
on a machine that is running the same OS as the images being built.
In development, we do build images on systems with older OS versions
than the the image we are building. However, that's absolutely
*unsupported*,
and it's not guaranteed to work.
If one would assume that interfaces are not changing, what would it
take to support running a DC build on the Solaris 11 release in order
to build repo ISOs for an update or SRU build? I'm hoping that based
on the stability of the release this will actually be supported.
In the first version of DC, we did try to run all commands from DC's
build area and set the LD_LIBRARY_PATH
to point to DC's build area. We were doing that hoping to support
building images with OS version different
than the DC build system. We ran into different problems. I forgot
whether they were
related to interface changes or not. When we completely re-wrote DC, we
placed
the requirement that the supported way is to build images on machines
that have the same OS level.
We removed all the code that runs commands from the DC's build area and
setting the LD_LIBRARY_PATH.
So, in order to support building on a OS version different than the OS
version of the image, we would at least
need to update DC to run things from DC's build area again. Also, we
need to decide
how do DC support cases where there is an interface change.
Finally, we also need lots of testing to see whether there's any problems.
--Karen
-- Alan
For your case, one idea is to maintain the different OS env as
different BE,
and just boot the BE with the "right" OS version when you want to do
DC build.
Thanks,
--Karen
On 11/16/11 10:32 AM, Alan Steinberg wrote:
We are looking at how to share systems, but with the DC requirement
to build on the latest OS, it makes it difficult.
The manpage says:
"And, the operating system release version on your system
must be the same release version as the image that you are building."
Would it be possible to make the tools work by using a mounted BE
rather than the live one? For example, we would mount s11u1_bld02 as
something like /oldbes/s11u1_bld02, then point distro_const at that
BE for any files that need to be referenced.
Is this too naive? If so, it would be useful to know *exactly* what
parts of the build env. are required for building ISO images for a
particular build, and to know if it may be possible to eliminate
some of these dependencies.
-- Alan
_______________________________________________
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
