Dan Groves wrote: > upgrade: > > For example, going from S10U4 to Nevada. > > - write a preinstall script for the package or packages that include > aggregation.conf and linkprop.conf. > - The script would parse the existing aggregation.conf and > linkprop.conf, then write commands to /var/svc/profile/upgrade to load > the information from those files into the linkmgmtd SMF repository.
At what point do commands from that file get run? > - The commands could either be dladm or SMF commands. I understand the > preference is for SMF commands. dladm commands would be easier. SMF > commands are harder because what do I use for a link ID? I could use an > invalid link ID and then have linkmgmtd recognize that a link ID needs > to be allocated for such entries. Is linkmgmtd running when that upgrade script gets run? That would be my only concern. > alternate root: > > - dladm would write out dladm commands to the /var/svc/profile/upgrade > script off of the alternate root. SMF commands would be fairly easy > here because we could use linkmgmtd to come up with unique linkids. You mean dladm commands rather than SMF commands, right? Again, my only question would have to do with the timing of the upgrade script and starting linkmgmtd. > One problem is what if the alternate root is for an environment that > predates linkmgmtd? Is such a thing possible? Yes, it is certainly possible to mount a BE that isn't the same OS version as the one which is running, and issue dladm -R commands for that BE. I'm not sure what the error handling would look like in that case, nor if this is expected to work. There's nothing in the existing documentation stating that the -R option needs to be used with an alternate-root that has a matching OS version as the one that's currently running, but I don't see how any other case can easily be made to work. -Seb
