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

Tue Feb 3 20:51:49 UTC 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150203/628dbd29/attachment.html>