Dave Miner wrote: > Evan Layton wrote: >> Dave Miner wrote: >>> Sarah Jelinek wrote: >>> ... >>>> >>>> I was actually thinking we would run the ICT stuff before we did the >>>> pkg image-update. Much like we do a pkg image-update on a live >>>> system today. So, I assume ips would take care of the configuration >>>> changes that are required during an image update. >>>> >>>> The process would be: >>>> 1. Install the bits that match the current booted client. >>>> 2. The normal ICT and post install stuff is run by AI. >>>> 3. Then run pkg image-update if we have detected that the user asked >>>> for later bits than the booted client version. >>>> >>>> Do you think this would work? >>>> >>> >>> I'm sure it would work, since it's exactly the path you'd follow in >>> updating from version R(unning) to version I(nstalled). But I >>> question whether it's necessary... >>> >>>> As for upgrading the zpool version if we detected there was a >>>> version higher that could be supported.. I think this is required >>>> since the user is expecting to get the latest version supported with >>>> their request. We can manage this in a fairly straightforward way I >>>> think. >>>> >>> >>> I think updating zpool versions is a fairly minor issue, not one I'd >>> focus on. The only problem it causes is newer features that aren't >>> available until the upgrade, but that isn't an entirely unexpected >>> path, since if you've been doing updates, you'll have the same >>> problem, and hence there'll be documentation and so on covering the >>> issue. >> >> Good point that this is documented. However This does represent an >> issue where the result of the install is somewhat unexpected. In this >> case the zpool version of the system installed this way could differ >> from say a live CD install where the booted image and installer match >> the bits being installed. We had listed that this unexpected result >> was a problem and that it was a requirement that the installed systems >> should match. Does this seem like a requirement that we should remove >> and not worry about? >> > > It would be better if we can deal with it, but given that the > workarounds are a) install with the matching booted bits or b) run zpool > upgrade, it seems not to be something over which I'd torture the design. > Postponing it to a first-boot task would seem to work well enough, > wouldn't it?
Yes doing this as a first-boot task would take care of it and that seems to be the way to deal with it. I just wanted to make sure this seemed to be a valid requirement. -evan
