Hi Jan,
I will respond to your questions about the content of the images.
On 09/ 1/10 05:20 AM, Jan Damborsky wrote:
Hi Chris, Andrew,
please see my response below. I skipped points
which Clay already mentioned.
Thank you,
Jan
ai_sparc_image.xml, ai_x86_image.xml
------------------------------------
To be honest, I am not quite convinced that modifying existing AI images
to serve network text installer is going to meet our requirements.
The reason is that AI image contains just a subset of text install image.
This is intentional, since it allows to minimize memory footprint in
case of network AI (which is the main AI scenario) when solaris*.zlib
compressed archives reside in memory. And since AI installs from IPS
repository, content of AI image does not limit what is installed on
target system.
On the other hand, text installer just copies media content to the target,
so there is currently 1:1 relationship between what is on media and what
gets installed. This is why text install image contains additional
bits comparing
to AI image.
Looking at 146 x86 AI and text images, the size difference is not
negligible:
146 x86 text:
# ls -l osol-dev-146-text-x86.iso
-rw-r--r-- 1 dambi staff 491134976 2010-08-13 19:50
osol-dev-146-text-x86.iso
# mount -F hsfs `pwd`/osol-dev-146-text-x86.iso /tmp/iso
# ls -l /tmp/iso/solaris*
-rw-r--r-- 1 root root 255856640 2010-08-13 19:47 /tmp/iso/solaris.zlib
-rw-r--r-- 1 root root 25576448 2010-08-13 19:50
/tmp/iso/solarismisc.zlib
146 x86 AI:
# ls -l osol-dev-146-ai-x86.iso
-rw-r--r-- 1 root root 324239360 2010-08-13 17:07 osol-dev-146-ai-x86.iso
# mount -F hsfs `pwd`/osol-dev-146-ai-x86.iso /tmp/iso/
# ls -l /tmp/iso/solaris*
-rw-r--r-- 1 root root 101229568 2010-08-13 17:05 /tmp/iso/solaris.zlib
-rw-r--r-- 1 root root 20375552 2010-08-13 17:07
/tmp/iso/solarismisc.zlib
Assuming that we would like to end up with the same bits installed in
both text install scenarios (media, network) would mean adding
additional stuff to AI image which would considerably increase memory
footprint in case of network AI.
Based on that, I can see following alternatives:
[1]
If keeping AI memory footprint as small as possible is still a
requirement,
then instead of modifying AI images we could go with text ones and modify
those to serve network text installer. That of course brings another
question -
how it would affect deploying those images on AI server, since then we
would
need to manage two types of install services - AI ones and text ones.
[2]
If AI memory footprint is no longer an issue, then we could
consolidate text
install and AI images. Alternatively, we could try to find some
reasonable trade off
with respect to memory footprint and media content.
In that case I believe that the desired outcome is ending up with one
image
per architecture serving both AI and text install.
E.g. something like
ai_x86_image.xml + text_mode_x86.xml => ai_text_x86.xml
ai_sparc_image.xml + text_mode_sparc.xml => ai_text_sparc.xml
I have two answers to this concern. The first answer is that such
considerations are intentionally being ignored with this initial
changeset, with the intent of addressing them later. It was felt that it
would be better to enable the functionality first, keeping the focus on
the code, and then worry about the image content issues later. For now,
I believe that the added versatility of having an interactive, network
booting installer justifies adding the text install packages to the
default AI images (even though it results in a slight increase in image
size; again I think that size increase is acceptable for now, until we
determine the final solution - see below). Even though the installed
target wouldn't have as much as an official, text install media would,
that's relatively easy to remedy after installation using IPS to deliver
whatever additional content is desired.
The second answer is that there definitely should be some discussion in
this area. A few thoughts along those lines:
* The DC manifests should (and will) be updated to consume specific
"clusters" (rather than listing a full set of packages). These clusters
would probably be something like "auto_install," "minimal_install," and
"server_install." In this example, auto_install would define the set of
packages need to boot via AI, and the other two packages would be owned
by RE and define "payloads" for the install target.
* Expanding on the clusters and their usage, we can see that the
assumption that "contents of media" == "desired payload" do not
necessarily coincide. For AI, they definitely are different -
"auto_install" is the media contents, but babel_install is the (default)
payload. For liveCD and text install, they are currently the same
(babel_install and the "server_install" list of packages, respectively).
* With the above points in mind, it becomes a bit clearer that it's now
a question of how to handle the limitation that a CPIO based install can
only ever deliver a payload that is equivalent to the media contents. Is
that an acceptable limitation? If so, then we should define a set of
default DC manifests with that in mind (text, AI, text+AI, etc.). If
not, then obviously the GUI and text installers will need to be expanded
to pick up additional payload (via IPS).
Thanks,
Keith
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
