[OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, please read)

Schweiss, Chip chip at innovates.com
Tue Feb 3 20:56:28 UTC 2015


Excellent!

I'll put it on my current project system and get you some feedback.

Of particular interest, were there any mpt_sas patches in there?

Cheers!
-Chip

On Tue, Feb 3, 2015 at 2:51 PM, Theo Schlossnagle <jesus at omniti.com> wrote:

> Fantastic work Dan!  We're all looking forward to 014!
>
> On Tue, Feb 3, 2015 at 3:35 PM, Dan McDonald <danmcd at omniti.com> wrote:
>
>> There is no TL;DR for this.  Please read all of this before you upgrade.
>>
>> This is a big one.  I've updated install media AND the repo servers.
>> Users who use "pkg update" will be getting a big wad (I'm not taking
>> chances with missed packages or components).  I'm sorry it took longer than
>> I expected, but there was an illumos-gate ZFS bug (5531) I wanted fixed
>> before I released the next bloody update.
>>
>> This is r151013-20150203:
>>
>> - omnios-build master branch, revision 0c38601
>>
>> - NEW UPDATE to pkg(5).  This carries a LOT with it, and gets its own
>> section below.
>>
>> - OpenSSL is now at 1.0.2.
>>
>> - One bugfix to illumos-kvm-cmd that needed to be cherrypicked (because
>> we can't catch up until VND is upstreamed from SmartOS).
>>
>> - Longstanding bug with GCC 4.4.4's "cc1" not being properly linked.
>> (Thanks Richard Yao of ZFS-on-Linux for catching this.)
>>
>> - Curl is now at 7.40.0.
>>
>> - NTP dependency fix, from the community. (Thanks to "takashiary".)
>>
>> - Git is now at 2.2.1.
>>
>> - ncurses have their auxiliary libs now in /usr/gnu/lib.  (Thanks to
>> Lauri "lotheac" Tirkkonen.)
>>
>> - illumos-omnios master branch, revision aef6850 (last illumos-gate merge
>> 6309835)
>>
>> - Several ZFS enhancements, and sometimes followup fixes for them (one,
>> 5531, was what made this release take longer than it should have).
>>
>> - dis(1) supports cross-target disassembly  (Illumos 3317)
>>
>> - NFS improvements in the authentication cache (Illumos 5509)
>>
>> - Several ELF safety improvements from Rich Lowe.
>>
>> - kmem_reap() performance improvements
>>
>> - preadv() and pwritev()
>>  NOTE: KVM's poor handling of these (assuming all the world's Linux) is
>> why we have a cherrypick above.
>>
>> - illumos-side hwdata (PCI & USB) updates.  (NOTE: OmniOS keeps a copy in
>> omnios-userland, that will be updated closer to 014's release).
>>
>> - Developer prototypes updated to 2015
>>
>> - Introducing the linked-ipkg ("lipkg") zone brand.  See below about how
>> this relates to the new pkg(5) changes.
>>
>> - Reducing RAM used in managing ZFS cache devices
>>
>> - Many new, corrected, and updated man pages.
>>
>> - Longstanding mailx(1) overflow fixes now in place.
>>
>>
>> NEW FOR 2015 -- updated pkg(5)
>>
>> You may have known this from previous bloody releases, but we've been
>> using the same oldish version of pkg(5) since at least r151006 in OmniOS.
>> Bloody releases have had a half-finished pkg(5) that breaks things like
>> "zoneadm -z <zone> attach -u".  When a release came, we reverted to the old
>> r151006 version of pkg(5).  That changes now.
>>
>> If you're interested in source, our new repo for pkg(5) is
>> http://github.com/omniti-labs/pkg5 or src.omniti.com:~omnios/core/pkg5.
>> It's a downstream of OI Hipster's for now.
>>
>> The OpenIndiana Hipster folks have done some work to bring pkg(5) more up
>> to date with its upstream. The new pkg(5) contains many under-the-hood
>> improvements. It also includes two user-visible improvements:
>>
>>         - A bit more visible status information during pkg(1) operations.
>>
>>         - The ability to link images.
>>
>> Linked images is the big one.  Way upstream, linked images are the new
>> default for ipkg-branded zones (i.e. the zones all OmniOS folks use). In OI
>> Hipster, linked-images are currently disabled.  We decided to take a middle
>> ground:
>>
>>
>> THE LINKED IPS BRAND (lipkg)
>>
>> Currently deployed ipkg-branded zones stay the same as they have in
>> previous OmniOS releases.  You update them how you're used to updating
>> them:  Either the documented OmniOS way, or "Dan's way", where you mount
>> the newly upgraded BE and then update each zone prior to reboot.
>>
>> If you detach a zone:  (zoneadm -z <zone> halt ; zoneadm -z <zone>
>> detach) you may change its brand the the new linked-ipkg (lipkg) brand.
>> The default for a new zone is still "ipkg", so if you want lipkg, you must
>> explicitly "set brand=lipkg" in the zonecfg interaction or script.
>>
>> How to convert an existing "ipkg" zone to an "lipkg" zone:
>>
>> 1.) Install the "lipkg" brand:  "pkg install lipkg".
>>
>> 2.) Halt and detach the zone.  "zoneadm -z <zone> halt ; zoneadm -z
>> <zone> detach"
>>
>> 3.) Change the zone's brand:  "zonecfg -z <zone> set brand=lipkg".
>>
>> 4.) Attach the zone with the -u flag. pkg(5) needs to run its update
>> check regardless:  "zoneadm -z <zone> attach -u".
>>
>> 5.) Boot the zone: "zoneadm -z <zone> boot".
>>
>> The zone <zone>'s image will be linked to the global zone's image.
>>
>> Once you are running with lipkg zones, new things happen upon subsequent
>> "pkg update"s.  Any packages in the global zone that get updated will also
>> be updated in the lipkg zones at the same time.  This includes more than
>> just the "omnios" publisher as well, which is why lipkg zones aren't for
>> everyone.  If, like me, you tend to currently use the "Dan's way" of
>> upgrading, lipkg zones will save you time.  "pkg update" where all zones
>> are lipkg is the equivalent of an automatic "Dan's way" upgrade.  The new
>> BE is created, and all of the zones in the new BE are already updated.
>> Furthermore, if you want to have the semantics of not losing log data
>> during the upgrade, you now merely need to halt the zones, then "pkg
>> update", and reboot.  If your zones are autoboot (which they should be)
>> everything's up and running with shiny new bits.
>>
>> Attached as a .txt file is a sample transcript of a linked-image upgrade
>> with a global zone and a non-global zone.
>>
>> Please give this one a try, and we'd really appreciate results from:
>>
>>         * lipkg-branded zones.
>>
>>         * Kayak images.
>>
>>         * The ISO installation experience.
>>
>>         * ZFS stressing (there may be some residual issues here from
>> upstream, so be warned).
>>
>> We will really appreciate the feedback.
>>
>> Thanks,
>> Dan
>>
>>
>>
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
>
> --
>
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150203/e72e1b53/attachment-0001.html>


More information about the OmniOS-discuss mailing list