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
net-fs-root
-----------
lines 333-350:
In order not to waste the precious memory, in case of x86
we should detect how we were booted (32/64 bit mode) and download
only missing boot archive. See ti_install.py for inspiration how
this check might look like.
With respect ot Sparc boot archives, why do we need to
download them at all ? There is only one used for both sun4u
and sun4v, so everything we need was already downloaded and
mounted on '/'.
In AI/text image, sun4v boot_archive is just a symlink to sun4u one:
# ls -l /export/home/ai/images/s-pit-147/platform/sun4u/
total 204062
-rw-r--r-- 1 root root 207440896 2010-08-27 03:29 boot_archive
drwxr-xr-x 11 root sys 12 2010-08-20 08:17 kernel
drwxr-xr-x 4 root bin 4 2010-08-20 08:17 lib
-rw-r--r-- 1 root sys 1185440 2010-08-20 08:10 wanboot
# ls -l /export/home/ai/images/s-pit-147/platform/sun4v/
total 1287
lrwxrwxrwx 1 root root 33 2010-08-27 00:00 boot_archive ->
../../platform/sun4u/boot_archive
drwxr-xr-x 10 root sys 11 2010-08-20 08:17 kernel
drwxr-xr-x 4 root bin 4 2010-08-20 08:17 lib
-rw-r--r-- 1 root sys 1185440 2010-08-20 08:10 wanboot
lines 357-358:
Please make 'svcadm disable' synchronous, i.e.
357 $SVCADM disable $MANIFEST_LOC
358 $SVCADM disable $CLI_LOGIN
->
357 $SVCADM disable -s $MANIFEST_LOC
358 $SVCADM disable -s $CLI_LOGIN
We have recently observed that not doing so might open space for
potential race conditions - see following bug for more details:
https://defect.opensolaris.org/bz/show_bug.cgi?id=16215
ict.py
------
What is the purpose of this check ? In which scenario is that condition met ?
On 08/31/10 09:35 PM, Chris Navrides wrote:
Hi all,
Could we please get a code review of the modifications made to
enable 6971585 Network Text Install
This will enable a client over the network to either do an Automated
Install or a Text Install. The default in the grub menu will lead to
the text install menu. For sparc if no "-install" flag is set then it
will also default to the text-install menu.
Webrev:
http://cr.opensolaris.org/~chris_n/netboot_text_instal
<http://cr.opensolaris.org/%7Echris_n/netboot_text_install/>l/
<http://cr.opensolaris.org/%7Echris_n/netboot_text_install/>
We have done testing with both x86 and sparc using the test bed on the
10.10.45 subnet. There are no changes done to installadm on the server
side.
Thanks,
Chris & Andrew
_______________________________________________
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
