>
> On 03/11/11 10:59 AM, Robert Milkowski wrote:
> > Hi,
> >
> > I'm trying to deploy AI for Solaris 11 Express and so far it's been
> > challenging... I have some questions and I hope someone will be able
> > to help.
> >
> > 1. disk partitioning on x86
> >
> > There could be multiple partitions or none - how can I force AI to use
> > entire disk and put one large Solaris2 partition regardless of how a
> > disk is currently partitioned? There is such an option for interactive
> > installs.
> >
> > 2. console on ttya
> >
> > If post-install scripts are supposed to be delivered via SMF during a
> > first boot following AI install, how can I put GRUB's menu.lst for the
> > first boot so I can pass options like console=ttya-...? What if I need
> > to get information from an external database about how console should
> > be set-up for a given server? For the AI/install boot it is easy as it
> > is matter of generating a proper menu.lst for a given server. How can
> > I do it for the first boot?
> >
> > Similar issue is with passing specific kernel options on some os/hw
> > combination due to bugs, etc.
> >
> > Basically how can I make sure that a customized menu.lst is used
> > during first boot?
> >
>
> Assuming you are using the same redirection for the console during
> installation, that should be carried through correctly to the installed
instance.
> User-specified modifications to the menu aren't directly possible right
now.
That would be something although still very limiting...
> > 3. pkg performance
> >
> > The solaris.zlib downloads at about 100MB/s on a GbE network - good.
> > However then pkg starts downloading packages and the network
> > utilizations varies between 0.5MB - 30MBs with an average less than a
> > couple of MB/s. I guess the sporadic 15-30MB/s occurrences are for
> > some large files, otherwise the performance is abysmal and it takes
> > far too long to just transfer packages. Not to mention that entire
> > process is basically serialized and doesn't make much use of
> > additional cores on a server. Is there a way for pkg to download
> > multiple files at the same time? This could probably help a little
> > bit... It doesn't have to be able to saturate a GbE link but doing
> > less than 5% is far from being impressive.
> >
> > 4. packages install/uninstall sections
> >
> > In jumpstart if some packages were marked to be uninstalled there
> > would never be installed in the first place. Currently AI+pkg installs
> > all selected packages and then uninstalls packages marked so. Ideally
> > all packages to be installed and uninstalled should be passed to pkg
> > at the same time and pkg should come up with the final set of packages
> > to install.
> >
>
> The uninstall support that's there right now is mostly for dealing with
> deficiencies in the way we've been defining group packages. Those are
> being resolved and revisiting that to instead provide access to the
recently-
> introduced --reject functionality in pkg would be useful.
Good know. Anything that would make it more efficient both in terms of
amount of data transferred over a network and time it takes to install would
be very welcome.
> > 5. tasks
> >
> > I can see in the install_log entries like "current
> > task:set_partition_active". Is there a way to add your own tasks?
> >
>
> No.
This is really bad then. As absolute minimum one should be able to decide
which of the provided tasks should run or not and perhaps they should be
customizable as well.
Then to make it even more useful one should be able to run their own tasks.
> > 6. /export/home
> >
> > How can I prevent it from being created? I don't want to use autofs
> > for /home directories, nor I want to /export, /export/home,
> > /export/home/jack to be created. Unconfiguring it during the first
> > boot via smf is rather silly.
> >
>
> Right now you can't.
Hopefully that would change and rather sooner than later.
> > 7. root disk mirroring
> >
> > how can I set-up rpool to be mirrored during installation? Setting it
> > up post-install during first boot when it will have to resilver
> > several GBs of data is far from ideal.
> >
>
> Again, right now you cannot.
:(
> > 8. /etc/system
> >
> > how can I customize /etc/system before the first boot? This is similar
> > to #2.
> >
>
> Most direct answer right now would be to republish the kernel package with
> your own required /etc/system contents.
That's getting close to tweaking the boot image and making it more flexible
in the first place.
> >
> > Generally AI needs pre- and post- install scripts additional to first
> > boot finish scripts via SMF. There seems to be a mechanism for
> > psot-install sctips already implemented and in use it is just not
> > exposed to end-users which is a mistake. I don't want some of them to
> > be running and to have undo their changes during first boot.
> >
>
> We're happy to consider additional functionality in that needs to be
provided
> by AI, but generalized user scripting within the installation environment
isn't
> up for consideration. You do have the option of building customized boot
> images that provide your own post-auto-install services if you wish, but
you
> own that image.
What do you mean exactly by that? I mean is there some documentation and
easy way to customize the image (I haven't looked yet) even if I will need
to own it?
It looks like this could be the best and most flexible way after all.
Right now I'm evaluating S11 and specifically looking how to integrate it
into the current environment.
To be honest - if it were jumpstart I would have finished setting up a
customized network install long time ago and it would be working for many
years.
Thanks to AI I'm moving from one limitation to another... I'm close to
seriously consider coming up with own scripting which would utilize cpio or
zfs send|recv as it would not only greatly increase the time it takes to
install an OS but also make the entire install as flexible as I want and
much easier to integrate with other OSes and an existing environment. Right
now, apart for very basic *desktop* installations, AI gets more in a way
than it actually solves any real problems. But I'm still trying to be open
minded about AI and want to see how far I can go with it also hoping that it
will improve very soon.
So far from my experience with AI I would very welcome below features in AI
(in no particular order) which would make it actually very usable for me:
1. image based installations
- perhaps one could provide an xml profile with the list of packages
to be installed/uninstalled and some tool would extract all of them from
repo server and store them as one large
signed archive which could be streamed to the system,
even if all pkg actions would have to be executed at the end of it it would
most likely make an installation much faster, right now
it is very slow
1.1 pkg/pkg.depotd performance - well, this is not really AI but still it
impacts AI performance and for now there is much to be improved here
2. ability to use whole disk by wiping out anything what was on it before
(afaik it's been fixed in later builds, so should be coming soon...?)
3. ability to configure mirrored root disks (again, afaik it's been fixed in
more recent builds...?)
4. ability to set any zpool/dataset properties *before* any data is put into
root pool (again, afaik it's been fixed in more recent builds...?)
- mostly compression, atime
5. ability to disable/enable AI tasks and perhaps even customize/parametrize
some of them
Having to undo some of their customizations is silly and counter
productive
- ability to customize menu.lst (remove background, change
console=XXX setting, pass additional kernel parameters, etc.)
- ability to customize /etc/system
6. ability to put your own tasks, especially post-install but before first
boot
- the really (not so) funny thing is that since auto_reboot property
could be set to false one can actually execute a post-install script
manually, it is "just" not possible to do it in a fully automated
way, or other option is to remotely (from a script) log-in via ssh
(with livessh=true), monitor when installation finished and again with
auto_reboot=false then execute a post install script
remotely - I'm pretty sure that many people determined enough to
actually deploy S11 in production will end-up doing something along these
lines. IMHO AI team should make it easier for
them and not harder as it won't really accomplish anything good.
7. disabling/enabling smf services doesn't work entirely, some of them get
re-enabled after lme, looks like this has been fixed in more recent builds
(?)
8. there should be progress displayed on a console, including an option of a
more verbose one (afaik it's planned...?)
9. installadm shouldn't automatically configure and enable tftpd unless ask
to do so, in many environments there are already dedicated tftp servers
10. it should be possible to put /var in a dedicated dataset
11. installadm should use a template name as a suffix to i86pc* directory
name in /tftpboot, same goes for menu.lst.template_name
12. backup/mirroring - how one can easily backup and/or replicvat AI
configuration across different servers?
Best regards,
Robert
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
