Re: [OmniOS-discuss] LX chdir bug with steps to reproduce

[Dominik Hassler]

The fix for the issue you reference (OS-5167) has been integrated in r24
and bloody:

hadfl@bloody-build:/build/illumos-omnios$ git log r151022 --grep "cached
v_path"
hadfl@bloody-build:/build/illumos-omnios$ git log r151024 --grep "cached
v_path"
commit e2fc3408efa6cdfc5e33c73c3567efc8c7592707
Author: Patrick Mooney 
Date:   Thu Jun 8 21:57:45 2017 +

8376 cached v_path should be kept fresh
Reviewed by: Jerry Jelinek 
Reviewed by: Robert Mustacchi 
Approved by: Gordon Ross 
hadfl@bloody-build:/build/illumos-omnios$ git log master --grep "cached
v_path"
commit e2fc3408efa6cdfc5e33c73c3567efc8c7592707
Author: Patrick Mooney 
Date:   Thu Jun 8 21:57:45 2017 +

8376 cached v_path should be kept fresh
Reviewed by: Jerry Jelinek 
Reviewed by: Robert Mustacchi 
Approved by: Gordon Ross 


running your python code on bloody does not seem to be broken.


On 03/09/2018 07:34 PM, Mini Trader wrote:
> This simple python code will break on an LX zone (LTS)
> 
> import os
> import time
> 
> os.chdir('/main/documents/test')
> for i in xrange(2000):
>     print i
>     os.chdir('a')
>     print os.getcwd()
>     os.chdir('..')
> 
> 
> On Fri, Mar 9, 2018 at 1:01 PM, Mini Trader  > wrote:
> 
> Would this bug have been fixed in the latest stable version of
> OmniOS CE?
> 
> On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald  > wrote:
> 
> 
> > On Jan 16, 2017, at 5:01 PM, Mini Trader  > wrote:
> >
> > We definitely need:
> >
> > https://smartos.org/bugview/OS-5167
>  (and probably whatever was
> done before it).
> 
> Joyent mentioned that very bug to me earlier this afternoon. 
> During the bringup of LX zones, I didn't cherrypick it from
> illumos-joyent, and now I remember why... it unravels a larger
> ball of yarn.
> 
> To that end, I'm attempting that unravelling now.  I doubt it'll
> be backported into r151020, though.  LX is still considered
> "beta" in 020, and stability of the overall system is why I'm
> loathe to bring in non-LX fixes for LX problems (as these all
> are) into a Stable release.
> 
> I'm going to cut a bloody release this week.  It has lots of new
> things in it, and if I'm lucky, it may include these Joyent
> fixes as well.  If you want to help, get a box up to bloody once
> I cut the release this week.
> 
> Thanks, and sorry I can't be of IMMEDIATE assistance,
> Dan
> 
> 
> 
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Problem with attach

[Dominik Hassler]

Hi,

I am not aware of an entire@11-0.151022:20180108T221634Z in our IPS
repos as we only ship those for r151022:

hadfl@r151022-build:~$ pkg list -avf entire
FMRI
IFO
pkg://omnios/entire@11-0.151022:20171031T101418Z
i--
pkg://omnios/entire@11-0.151022:20170917T145315Z
---
pkg://omnios/entire@11-0.151022:20170511T002513Z
---

Could you please elaborate a bit more how you did the upgrade (i.e.
steps you did, setting publisher etc)


On 01/09/2018 11:07 PM, Software Information wrote:
> Hi All
> I am not sure how this happened. I thought I followed the instructions
> but I now have a problem. My non-global zone is now out of sync with my
> global zone.
> 
>  Global zone version: entire@11-0.151022:20180108T221634Z
>  Non-Global zone version: entire@11-0.151020:20161102T012108Z
> 
> I tried using zoneadm -z zonename attach -u but that failed. Is there a
> way to sync the non-global zone?
> 
> Regards
> 
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ERROR: Could not update attaching zone

[Dominik Hassler]

> Child image publisher configuration must be a superset of the parent
image publisher configuration.

your NGZ is lacking the ms.omniti.com publisher which you have set for
the GZ.

after doing a:
# pkg -R /export/zones/web01/root set-publisher -g
http://pkg.omniti.com/omniti-ms/ ms.omniti.com

attaching the zone should work.

On 11/20/2017 06:26 PM, Serge Fonville wrote:
> Hi,
> 
> When I tried to attach a zone I got the following errors:
> 
> zoneadm -z web01 attach
> 
> Log File: /var/tmp/web01.attach_log.olaaFy
>    Attach Path: /export/zones/web01/root
>     Attach ZFS Dataset: rpool/export/zones/web01/ROOT/zbe-9
> 
>     Installing: Using pre-existing data in zonepath
>  Cache: Using /var/pkg/publisher.
>   Updating non-global zone: Output follows
> 
>     Evaluation: Packages in zone web01 are out of sync with
> the global zone. To proceed, retry with the -u flag.
>     Result: Attach Failed.
> With the log file containing:
> [Mon Nov 20 18:02:28 CET 2017] Log File: /var/tmp/web01.attach_log.olaaFy
> [Mon Nov 20 18:02:32 CET 2017]    Attach Path:
> /export/zones/web01/root
> [Mon Nov 20 18:02:32 CET 2017] Attach ZFS Dataset:
> rpool/export/zones/web01/ROOT/zbe-9
> 
> [Mon Nov 20 18:02:32 CET 2017] existing
> [Mon Nov 20 18:02:32 CET 2017] Installing: Using
> pre-existing data in zonepath
> [Mon Nov 20 18:02:32 CET 2017]   Sanity Check: Passed.  Looks like an
> OpenSolaris system.
> pkg: Search performance is degraded.
> Run 'pkg rebuild-index' to improve search speed.
> [Mon Nov 20 18:02:39 CET 2017]  Cache: Using
> /var/pkg/publisher.
> [Mon Nov 20 18:02:39 CET 2017]   Updating non-global zone: Output follows
> 
> 
> pkg install: Invalid child image publisher configuration.  Child image
> publisher
> configuration must be a superset of the parent image publisher
> configuration.
> Please update the child publisher configuration to match the parent.  If the
> child image is a zone this can be done automatically by detaching and
> attaching the zone.
> 
> The parent image has the following enabled publishers:
>     PUBLISHER 0: omnios
>     PUBLISHER 1: ms.omniti.com 
> 
> The child image has the following enabled publishers:
>     PUBLISHER 0: omnios
> [Mon Nov 20 18:02:42 CET 2017]
>     Evaluation: Packages in zone web01 are out of sync with
> the global zone. To proceed, retry with the -u flag.
> [Mon Nov 20 18:02:44 CET 2017] Result: Attach Failed.
> 
> So I try to run  it with -u
> 
> zoneadm -z web01 attach -u
> 
>  Log File: /var/tmp/web01.attach_log.TNaqaR
>    Attach Path: /export/zones/web01/root
>     Attach ZFS Dataset: rpool/export/zones/web01/ROOT/zbe-9
> 
>     Installing: Using pre-existing data in zonepath
>  Cache: Using /var/pkg/publisher.
>   Updating non-global zone: Output follows
> ERROR: Could not update attaching zone
>     Result: Attach Failed.
> 
> With the log file containing:
> [Mon Nov 20 18:20:23 CET 2017] Log File: /var/tmp/web01.attach_log.TNaqaR
> [Mon Nov 20 18:20:27 CET 2017]    Attach Path:
> /export/zones/web01/root
> [Mon Nov 20 18:20:27 CET 2017] Attach ZFS Dataset:
> rpool/export/zones/web01/ROOT/zbe-9
> 
> [Mon Nov 20 18:20:27 CET 2017] existing
> [Mon Nov 20 18:20:27 CET 2017] Installing: Using
> pre-existing data in zonepath
> [Mon Nov 20 18:20:27 CET 2017]   Sanity Check: Passed.  Looks like an
> OpenSolaris system.
> [Mon Nov 20 18:20:31 CET 2017]  Cache: Using
> /var/pkg/publisher.
> [Mon Nov 20 18:20:31 CET 2017]   Updating non-global zone: Output follows
> 
> 
> pkg install: Invalid child image publisher configuration.  Child image
> publisher
> configuration must be a superset of the parent image publisher
> configuration.
> Please update the child publisher configuration to match the parent.  If the
> child image is a zone this can be done automatically by detaching and
> attaching the zone.
> 
> The parent image has the following enabled publishers:
>     PUBLISHER 0: omnios
>     PUBLISHER 1: ms.omniti.com 
> 
> The child image has the following enabled publishers:
>     PUBLISHER 0: omnios
> [Mon Nov 20 18:20:35 CET 2017] ERROR: Could not update attaching zone
> [Mon Nov 20 18:20:36 CET 2017] Result: Attach Failed.
> 
> On global zone:
> 
> pkg publisher
> 
> PUBLISHER   TYPE STATUS P LOCATION
> omnios  origin   online F
> https://pkg.omniosce.org/r151022/core/
> 
> Any help in resolving this greatly appreciated!!
> 
> Thanks in advance!!
> 
> Kind regards/met vriendelijke groet,
> 
> Serge Fonville
> 
> http://www.sergefonville.nl
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> 

Re: [OmniOS-discuss] Upgrade from 151022 to CE bootadm error

[Dominik Hassler]

It looks like your rpool is running out of free space.

On 09/15/2017 08:10 PM, Jim Oltman wrote:
On Mon, Aug 28, 2017 at 10:00 PM, Dan McDonald > wrote:


Three swaps are three mountpoints using tmpfs.  Please share "zfs
list" and "beadm list" again, please?

Dan

Sent from my iPhone (typos, autocorrect, and all)


Sorry for the super late reply.  Been busy at home and work.  Here's 
Dan's requested output:


joltman@OmniOS-NAS:/export/home/joltman$ zfs list
NAME   USED  AVAIL  REFER  
MOUNTPOINT

rpool 24.1G  37.4M31K  /rpool
rpool/ROOT7.90G  37.4M23K  legacy
rpool/ROOT/20170826_01_Pre_OmniOS-CE   101K  37.4M  2.67G  /
rpool/ROOT/20170826_Pre_OmniOS-CE 2.16M  37.4M  2.56G  /
rpool/ROOT/20170826_Pre_OmniOS-CE-1   7.82G  37.4M  2.55G  /
rpool/ROOT/OmniOS-NAS_20170324_1226125K  37.4M  2.62G  /
rpool/ROOT/omnios 58.9M  37.4M  2.46G  /
rpool/ROOT/omnios-1   1.08M  37.4M  2.52G  /
rpool/ROOT/omnios-2   3.22M  37.4M  2.56G  /
rpool/ROOT/omnios-2-backup-1   166K  37.4M  2.64G  /
rpool/ROOT/omnios-2-backup-2   163K  37.4M  2.53G  /
rpool/ROOT/omnios-2-backup-3   164K  37.4M  2.54G  /
rpool/ROOT/omnios-backup-1 220K  37.4M  1.72G  /
rpool/ROOT/omnios-backup-2 226K  37.4M  1.75G  /
rpool/ROOT/omniosvar23K  37.4M23K  legacy
rpool/ROOT/pre_download_17.01free_1490380649 1K  37.4M  2.61G  /
rpool/ROOT/pre_napp-it-16.07f  220K  37.4M  1.73G  /
rpool/ROOT/pre_napp-it-17.01free   166K  37.4M  2.54G  /
rpool/ROOT/r151020_upgrade_151022 1.89M  37.4M  2.56G  /
rpool/ROOT/r151020_upgrade_151022-backup-112.9M  37.4M  2.55G  /
rpool/ROOT/r151020_upgrade_151022-backup-2 150K  37.4M  2.55G  /
rpool/dump12.0G  37.4M  12.0G  -
rpool/export  26.9M  37.4M23K  /export
rpool/export/home 26.8M  37.4M  26.8M  
/export/home

rpool/swap4.13G  3.89G   276M  -
tank  2.34T  1.17T36K  /tank
tank/backups  77.4G  1.17T  77.4G  
/tank/backups

...
tank/joltman  93.7G  1.17T  60.9G  
/tank/joltman

...
tank/mythtv339G  1.17T   339G  
/tank/mythtv
tank/pictures 34.4G  1.17T  34.3G  
/tank/pictures
tank/public   3.62G  1.17T  3.60G  
/tank/public
tank/seccams20K  1.17T20K  
/tank/seccams
tank/software 73.9G  1.17T  73.9G  
/tank/software
tank/videos   52.5K  1.17T  52.5K  
/tank/videos
tank/voltman  55.3G  1.17T  55.2G  
/tank/voltman

tank_00   14.0T  41.3G   272K  /tank_00
tank_00/videos14.0T  41.3G  14.0T  
/tank_00/videos

tank_01   13.7T   355G   272K  /tank_01
tank_01/videos13.7T   355G  13.7T  
/tank_01/videos

joltman@OmniOS-NAS:/export/home/joltman$

joltman@OmniOS-NAS:/export/home/joltman$ beadm list
BEActive Mountpoint Space Policy Created
omnios-  -  58.9M static 
2016-11-04 15:18
omniosvar -  -  23.0K static 
2016-11-04 15:18
omnios-backup-1   -  -  220K  static 
2016-11-11 15:38
pre_napp-it-16.07f-  -  220K  static 
2016-11-11 15:40
omnios-backup-2   -  -  226K  static 
2016-11-11 15:40
omnios-1  -  -  1.08M static 
2016-11-21 15:28
OmniOS-NAS_20170324_1226  -  -  125K  static 
2017-03-24 12:27
omnios-2  -  -  3.22M static 
2017-03-24 12:27
pre_download_17.01free_1490380649 -  -  1.00K static 
2017-03-24 12:37
omnios-2-backup-1 -  -  166K  static 
2017-03-28 17:06
omnios-2-backup-2 -  -  163K  static 
2017-04-16 18:33
omnios-2-backup-3 -  -  164K  static 
2017-05-13 22:45
r151020_upgrade_151022-  -  1.89M static 
2017-05-13 22:57
pre_napp-it-17.01free -  -  166K  static 
2017-05-18 18:05
r151020_upgrade_151022-backup-1   N  /  12.9M static 
2017-08-26 12:29
r151020_upgrade_151022-backup-2   -  -  150K  static 
2017-08-26 

Re: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos...

[Dominik Hassler]

Hi Oliver,

a pkg archive containing an updated system/library is available:
https://downloads.omniosce.org/pkg/system_library_8543.p5p

Please provide feedback as soon as you could test it. Thanks.

Regards,
Dominik

On 07/31/2017 11:26 AM, Oliver Weinmann wrote:

Hi Andy,

These are great news. Thanks a lot. I'm happy to test. :)

But first I guess I have to upgrade my current omnios 151022 to latest omniosce.

Best Regards,
Oliver

-Original Message-
From: Andy Fiddaman [mailto:omn...@citrus-it.net]
Sent: Montag, 31. Juli 2017 11:19
To: Oliver Weinmann 
Cc: omnios-discuss 
Subject: Re: [OmniOS-discuss] Ldap crash causing system to hang fixed in 
illumos...


On Mon, 31 Jul 2017, Oliver Weinmann wrote:

; Hi Guys,
;
; I'm currently facing this bug under OmniOS 151022 and I just got informed 
that this has been fixed:
;
; https://www.illumos.org/issues/8543
;
; As this bug is causing a complete system hang only a reboot helps. Can this 
maybe be implemented?
;
; Best Regards,
; Oliver

Hi Oliver,

I've opened an issue for you at
https://github.com/omniosorg/illumos-omnios/issues/26
and you can track progress there.

We plan to include this fix in next Monday's release but we're building a test 
update today and somebody will be in touch directly if you want to test it 
early.

Regards,

Andy

--
Citrus IT Limited | +44 (0)333 0124 007 | enquir...@citrus-it.co.uk Rock House 
Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and 
Wales | Company number 4899123

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dominik Hassler]

On 05/16/2017 09:12 PM, Paul B. Henson wrote:

From: Dominik Hassler
Sent: Tuesday, May 16, 2017 8:50 AM

This system has a different mainboard, so I wonder if it is BIOS related
and a BIOS upgrade on system 1 could help?


Perhaps a silly question, but had you tested booting from both drives before
the upgrade :)?



Not a silly question at all. Yes I did, and the device that fails was 
the primary boot device before; so when the initial boot after enabling 
loader failed I tried the second and since that one worked I changed 
primary and secondary now.

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dominik Hassler]

Addendum:

Just upgraded another system and there booting from both rpool devices 
works.


This system has a different mainboard, so I wonder if it is BIOS related 
and a BIOS upgrade on system 1 could help?


Another difference:

System 1 has been set-up in summer 2013, so it went r06 -> r08 -> ... -> r22
System 2 has been set-up in end of 2014, so it went r12 -> R14 -> ... -> r22

Not sure if that might have an impact, when OmniOS was set-up first 
(e.g. how partitions are created by installer)


On 05/16/2017 03:53 PM, Dominik Hassler wrote:

Ok, I did an installboot -mFf on both disks again (-v is not available
for installboot)

$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
/dev/rdsk/c9t5000CCA04103E0B5d0s0
bootblock written for /dev/rdsk/c9t5000CCA04103E0B5d0s0, 223 sectors
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector

$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
/dev/rdsk/c10t5000CCA04103E095d0s0
bootblock written for /dev/rdsk/c10t5000CCA04103E095d0s0, 223 sectors
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector

checked the version:

$ installboot -i /boot/gptzfsboot
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

and compared it to the version of both disks:

$ sudo installboot -i /dev/rdsk/c9t5000CCA04103E0B5d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d


everything matches, but still the system boots only from one disk and
not the other. Since it is not the latest version you mentioned I'll
just wait until it is updated I guess. I can at least boot from one disk
so I am not too worried about it at the moment. Still I would prefer to
be able to boot from both.

On 05/16/2017 03:18 PM, Toomas Soome wrote:



On 16. mai 2017, at 15:58, Dominik Hassler <hassl...@gmx.li> wrote:

Toomas,

using a (forced) installboot on both rpool mirror devices did the
trick. Loader is now being used.

However there is another problem. I can boot w/o problems from the
first device. But booting fails from the second device w/ the
following message:

Can't find /boot/zfsloader

illumos/x86 boot
Default: disk-1:/boot/zfsloader


Somehow the MBR on second disk is not properly updated and I think it
has wrong size recorded for stage2.

The initial installboot was implemented based on installgrub source
and we record the LBA with gptzfsboot start sector, and size (in
sectors) into MBR.

Now the copy of the MBR (the /boot/pmbr file) is also installed into
partition start sector 0), and when the beadm activate is run, the
boot blocks are updates, but with same logic, that with MBR+VTOC case,
the MBR itself is not updated (to keep multi boot setups safe), and
only partition sector 0 and stage 2 are updated. The oversight is that
the MBR is loading stage2 directly, and if the gptzfsboot size was
changed, the result is that not the entire gptzfsboot is read into the
memory and resulting with just the output as you can see.

later we did create the fix for installboot - the fixed installboot
will only record the location and size (1 sector) of the partition
boot recors (partition relative sector 0), and after that the MBR code
will read in the partition block, the partition block will read the
stage2, and so the MBR+VTOC case is not an issue any more.

to fix this, run installboot -mFfv against that second disk to ensure
the MBR block is properly updated - note the -v again, so you can
confirm the MBR and partition block and stage2 are all updated.

With installgrub we actually have the same issue, except, the grub
stage2 size virtually did not change and thats why the problem was
never revealed.

note, if your installboot command does allow to read the version from
/boot/gptzfsboot like that:

$ installboot -i /boot/gptzfsboot
Extended version string: 1.1-2017.5.6.2
MD5 hash: 2907581de9ca6bd4d2c12695a32cb749

then it has the bug fixed, and after installing MBR with such binary,
the MBR is always reading the sector 0 from partition start, and the
future updates are ok.

also note that MBR is always updated with GPT, and hence there the
issue does not appear (which why it took some time to notice it - my
own test systems were all using GPT:)

rgds,
toomas


boot:


Debug info below:

$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

same on both devices


$ sudo format -> select disk -> fdisk
Total disk size is 36481 cylinders
Cylinder size is 16065 (512 byte) blocks

  Cylinders
 Partition   StatusType

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dominik Hassler]

Toomas,

using a (forced) installboot on both rpool mirror devices did the trick. 
Loader is now being used.


However there is another problem. I can boot w/o problems from the first 
device. But booting fails from the second device w/ the following message:


Can't find /boot/zfsloader

illumos/x86 boot
Default: disk-1:/boot/zfsloader
boot:


Debug info below:

$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

same on both devices


$ sudo format -> select disk -> fdisk
 Total disk size is 36481 cylinders
 Cylinder size is 16065 (512 byte) blocks

   Cylinders
  Partition   StatusType  Start   End   Length%
  =   ==  =   ===   ==   ===
  1   ActiveSolaris2  1  3648036480100

same on both devices


$ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
* /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
*  63 sectors/track
* 255 tracks/cylinder
*   16065 sectors/cylinder
*   36480 cylinders
*   36478 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*   First SectorLast
*   Sector CountSector
*   0 16065 16064
*
*  First SectorLast
* Partition  Tag  FlagsSector CountSector  Mount Directory
   0  200  16065 586003005 586019069
   2  501  0 586051200 586051199
   8  101  0 16065 16064


same on both devices


boot: status
Default: disk-1:/boot/zfsloader
boot: statusdisk devices:
disk0:   BIOS drive C ...
  disk0a: root
  disk0i: boot
disk1:   BIOS drive D ...
  disk1s1: Solaris 2
disk1s1a: root
disk1s1i: boot

zfs devices:
  pool: rpool
bootfs: rpool/ROOT/omnios-r151022
config:

NAME STATE
rpool DEGRADED
  mirror DEGRADED
c9t5000CCA04103E0B5d0s2 ONLINE
c10t5000CCA04103E095d0s0 OFFLINE

illumos/x86 boot
Default: disk-1:/boot/zfsloader
boot:


Any hints on how to get the system boot from both rpool devices are 
highly appreciated.



Kind regards,
Dominik

On 05/15/2017 08:40 PM, Toomas Soome wrote:



On 15. mai 2017, at 21:06, Dan McDonald <dan...@omniti.com> wrote:



On May 15, 2017, at 12:49 PM, Dominik Hassler <hassl...@gmx.li> wrote:

Hey,

after the upgrade, the boot loader is still GRUB.

I did the upgrade according to the upgrade notes. Rebooted once, did a:

$ sudo beadm activate omnios-r151022
WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
   generating a new menu.lst file
Activated successfully

checked for a /etc/default/be file. there is none. Still the boot loader is 
GRUB instead of loader.


Are you on a mirrored root pool?  It's possible the libbe code that installs 
loader doesn't do it to all disks in a mirrored pool...

Worst-case scenario is to explicitly install it:

foreach (drive)
installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/

Dan



The problem you have is that beadm activate does not enforce MBR update in case 
of MBR+VTOC partitioning; you need to either run bootadm install-bootloader 
-Mfv or installboot -mv.

Note that installboot and bootadm install-bootloader have slightly different 
flags; -v is good to have there, so you will see if the MBR was updated or not.

The beadm activate and bootadm use the same mechanism to update the bootblocks 
on all pool member disks, bootadm does have extra flag to allow MBR update. 
installboot does only update specified disk.

rgds,
toomas


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?

[Dominik Hassler]

On 03/30/2017 10:00 AM, Andy Fiddaman wrote:



On Thu, 30 Mar 2017, Ludovic Orban wrote:

; I personally don't need ipadm in my LX zones, nerver missed it and I'm
; pretty certain I wouldn't use it even if it was available.

Same here.


+1
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!!

[Dominik Hassler]

Dan,

updated according to your instructions and switched to loader 
afterwards. Everything went smooth.


Thanks!
Dominik

On 02/01/2017 01:34 AM, Dan McDonald wrote:

Hello!

PLEASE READ THIS CAREFULLY BEFORE UPDATING!!!  (And pardon any shouting, there 
are important things to read here.)

Progress on our work for this bloody is going smoother than expected, thanks to 
the good work others have been doing upstream in illumos-gate.  The Python2.7 
switch has gone well (I'm seeing no complaints from bloody users).  The new 
bits we're about to push on to http://pkg.omniti.com/omnios/bloody/ will enable 
another upstream innovation:  BSD Loader.  Unlike previous updates, I want this 
mail on the list before I push packages out to the repo server.

The BSD Loader provides a replacement for GRUB.  Its biggest upfront 
improvements over GRUB 0.97 are that it's an active Open Source project (GRUB 
went to 2.0), and that it eliminates the number-of-boot-environment limits that 
GRUB had.  Furthermore, BSD Loader provides a more stable foundation for future 
improvements such as EFI boot (vs. BIOS boot) and the possibility of booting 
off of raidZ pools.

The official arrival of BSD Loader constitutes an operational flag day for 
bloody users.  This is a substantial enough change to merit its own new wiki 
page to accompany r151022's release.  Current users of bloody may notice the 
presence of this file:  /etc/default/be.  This file has been in place to 
PREVENT the use of loader.  As of this upcoming update, that file disappears, 
but it can be reconstituted.

Before updating, you, the administrator, must make a decision:  Stick with GRUB, or move 
to loader.  The /etc/default/be file, specifically the "BE_HAS_GRUB=true" line, 
tells beadm(1M) what boot loader you wish to use going forward.

I WANT TO MOVE TO LOADER

- This is the default after updating, but Loader does not get installed until you "beadm activate" 
a loader-friendly BE (including the current one). Reboots after an update without the invocation of 
"beadm activate" or "installboot" will mean your machine stays with grub.  You should 
notice an extra message about /rpool/boot/menu.lst being created.

- If you have bloody BE from 2017, it is loader-friendly, so long as you remove 
/etc/default/be from that BE's root filesystem.

- If you have a pre-2017 bloody BE, or an older OmniOS release BE, you can not 
"beadm activate" it, beadm(1M) will fail.

- An old BE CAN be booted from the new Loader menu, but beadm will not work 
properly in that pre-Loader boot environment once booted.


I WANT TO STICK WITH GRUB

- Put "BE_HAS_GRUB=true" into /etc/default/be.  This will instruct beadm(1M) 
and libbe that you wish to continue with GRUB.

- Technically this has been happening since the first bloody release of 2017. The 
difference now is that "pkg update" removes this file from a system-installed 
image.

- Old BEs will work fine, and you can "beadm activate" between all of them.


I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB)

- Remove /etc/default/be on an active 2017 bloody BE.

- "beadm activate " -- you should see a message about 
/rpool/boot/menu.lst being created.

- You are now on loader.

- If the "beadm activate" fails, or you still are booting with GRUB afterwards, 
explicitly install loader by:

  rm /etc/default/be  (or at least remove the BE_HAS_GRUB line if you have 
multiple lines for some reason)
  installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/
  rm /rpool/boot/menu.lst
  beadm activate   (should reconstruct /rpool/boot/menu.lst)

If you have mirrored roots, do the above installboot for each .


I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader)

- You will need to be in an active 2017 bloody BE.

- Invoke the following:

  rm /rpool/boot/menu.lst
  echo "BE_HAS_GRUB=true" > /etc/default/be
  installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/

If you have mirrored roots, use "installgrub -M /dev/rdsk/ 
/dev/rdsk/


This update does NOT include an update to the ISO or USB install media yet 
(that's a problem we're still solving).  It WILL, however, include an update to 
kayak software a day or two after, and the Kayak .zfs.bz2 media.  With this 
update, Kayak will now install both Loader AND use whole-disk GPT partitioning 
for rpools.  We'd appreciate additional feedback on the Kayak changes.

The repo will be updated within 24 hours of the sending of this mail.  The 
Kayak bits, 24 hours after that.

Thanks for your patience as we move forward during this bloody cycle.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] PCI-e x8 only running x4

[Dominik Hassler]

On 01/24/2017 02:22 AM, Dan McDonald wrote:



On Jan 23, 2017, at 8:17 PM, Michael Rasmussen  wrote:

I am aware of that and an upgrade to a 2x08 is on the todo list.


Highly recommend x == 0 or 2, or also consider a 3008.  All of these are 
mpt_sas boards.  x == 1 or 3 are mr_sas boards, which have (eww) HW-RAID on 
them.



are you sure? i have a 2308 flashed to IT firmware and the attached 
driver is mpt_sas not mr_sas



# ./sas2ircu LIST
LSI Corporation SAS2 IR Configuration Utility.
Version 20.00.00.00 (2014.09.18)
Copyright (c) 2008-2014 LSI Corporation. All rights reserved.


 Adapter  Vendor  Device   SubSys  SubSys
 IndexType  ID  IDPci Address  Ven ID  Dev ID
 -    --  --  ---  --
   0 SAS2308_1 1000h86h   00h:02h:00h:00h  15d9h   0691h
SAS2IRCU: Utility Completed Successfully.

# dmesg |grep sas
Jan 20 01:24:06 jupiter scsi: [ID 583861 kern.info] mpt_sas5 at 
mpt_sas0: scsi-iport v0
Jan 20 01:24:06 jupiter genunix: [ID 936769 kern.info] mpt_sas5 is 
/pci@0,0/pci8086,c05@1,1/pci15d9,691@0/iport@v0
Jan 20 01:24:06 jupiter genunix: [ID 408114 kern.info] 
/pci@0,0/pci8086,c05@1,1/pci15d9,691@0/iport@v0 (mpt_sas5) online




Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] upper/lower case of share names smb

[Dominik Hassler]

just did a test:

# $ zfs create -o casesensitivity=mixed -o nbmand=on -o 
sharesmb=name=TeSt,description="test share" tank/test


# zfs get sharesmb tank/test
NAME PROPERTY  VALUE SOURCE
tank/testsharesmb  name=TeSt,description=test share  local

# sharemgr show -P smb -v |grep test
zfs/tank/test
  TeSt=/tank/test   "test share"


so it likely is in the sharing code.

On 01/20/2017 04:47 PM, Dan McDonald wrote:



On Jan 20, 2017, at 2:31 AM, Manuel Oetiker  wrote:

Hi

I have a Omnios 151020 with smb and ad connection.

zfs create -p -o casesensitivity=mixed -o nbmand=on \
 -o sharesmb=name=DataDB,description="Data DB" \
 ssd-a/share/datadb

I think the shares should show up on the windows side as DataDB and not
as datadb.

Is there a way to prevent the the upper/lower case on the sharename side?


Ahhh, you want case-preservation on the share name.

Can you please do me a favor and utter:

zfs get all ssd-a/share/datadb

I'd like to see what ZFS properties are.  It'll help me figure out where the problem might be.  If 
the properties have "DataDB" converted to "datadb", for example, it's likely in 
the ZFS property code.  If it's not, it's likely in the SMB sharing code.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] svcs -Z should ignore LX zones

[Dominik Hassler]

i guess it is this one you mentioned:

https://github.com/joyent/illumos-joyent/commit/32ce5b9ee70c2ead1e46c0fa82f724b4fe8fc54f


and this ones might be worth merging, too:

https://github.com/joyent/illumos-joyent/commit/31a2b4f9f0f4c1f93217bdfb5192d23ec361e414

https://github.com/joyent/illumos-joyent/commit/d07645b17dd983d7abe043763251310332d4c971



On 01/20/2017 02:31 AM, Dan McDonald wrote:



On Jan 19, 2017, at 8:19 PM, Dan McDonald  wrote:

Thanks for finding this, we should fix it before 022 ships, if not sooner,


Don't quite have the precise line numbers, but this:

if (scf_handle_bind(h) == -1) {
if (g_zonename != NULL) {
-   uu_warn(gettext("Could not bind to repository "
+   if (show_zones)
+   goto nextzone;
+
+   uu_die(gettext("Could not bind to repository "
"server for zone %s: %s\n"), g_zonename,
scf_strerror(scf_error()));
-
-   if (!show_zones)
-   return (UU_EXIT_FATAL);
-
-   goto nextzone;
}


is a bit from SmartOS that appears to mitigate your problem, at the cost of skipping over a 
native zone with an SMF problem.  You can, however, target those with "svcs -z 
".

I'll see if I can build it tomorrow.  I'm in the middle of another Joyent 
merge, so I can't until tomorrow.

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] svcs -Z should ignore LX zones

[Dominik Hassler]

just cosmetics, but running 'svcs/svcadm -Z' on a host where LX zones 
are present throws the following warning for each LX zone due to the 
absence of SMF (the same applies for 'svcs/svcadm -z ', but 
here it is run against the zone intentionally, so a warning/error seems 
to be right):


svcs: Could not bind to repository server for zone ...: repository 
server unavailable


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2

[Dominik Hassler]

Thanks for clarifying that. I just checked the cables and they classify
as Cat6a and they are from a respectable german vendor, not that this
would be any guarantee, but at least they're no bulkware from china. ;)

The X540s are either onboard on some Supermicro X10 boards, but also on
a genuine Intel PCI adaptor. I will check some other cables, maybe the
ones I got were somewhat faulty. However, this leaves only a few
options  to the user, finding out, what is actually wrong with the
connection, isn't it?

Regarding the release of omniOS, I will update my RSF-1 node to the
latest r18, the other two new nodes are actually on r20 and thus should
already have the new driver installed.

…any suggestion on some good cables? ;)


Dätwyler:
http://www.cabling.datwyler.com/products/data-centres/copper-technology/patch-cords/product/rj45-patch-cords-cat6a-iec.html

they provide detailed specs and test certificates for all of their cable 
types.




Thanks,
Stephan




___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX zones: configurations

[Dominik Hassler]

Dale,

I am very satisfied to stay in the realm of zoneadm/zonecfg and family. 
This is what I wanted to read:


On 01/11/2017 12:03 AM, Dan McDonald wrote:
>  If there are real, provable show-stoppers in LX, fixes may get 
backported.


Cheers,
Dom



On 01/11/2017 12:04 AM, Dale Ghent wrote:



On Jan 10, 2017, at 5:04 PM, Dominik Hassler <hassl...@gmx.li> wrote:

@Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is there 
a chance to get LX bleeding edge in r20 w/o the risk of breaking something else?


Zones in 020 is still largely in sync with the LX code currently in bloody (021). 
Since zones (beta) was released with 020, we’ve been primarily focussed on other 
items required for 022, the most laborious of which is the Python 2.6 -> 2.7 
upgrade. This is needed for a number of reasons. First, the benefits of getting 
off of 2.6 and on to 2.7 is self-explanatory, but 2.7 is also needed for being 
able to stay in sync with the pkg code, as well as the next big project for 022 - 
a loader-enabled installer (text installer and kayak) to replace the current one.

In the mean-time, we’re always looking for ideas (and even contributions!) from 
the community on how best to handle the management and administrivia involved 
with LX zones. For now, we’d like this to stay within the realm of 
zoneadm/zonecfg and family.

/dale


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] LX zones: configurations

[Dominik Hassler]

Hi,

I thought it might be good to have a public spreadsheet to post LX zone 
setups and how/if they work. It is not meant to be the book of wisdom, 
but should encourage people who are thinking of running the same 
service(s) in an LX zone, to actually try it if they see that someone 
else already did it before. Even if you plan to use a different distro, 
it might give you some confidence to step forward.


This is just a basic start. Feel free to reformat it, add missing 
columns etc... If it is found to be useful, ownership could be 
transferred to OmniTI and linked to the wiki (w/ additional information).


http://tinyurl.com/hajz4ap

@Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is 
there a chance to get LX bleeding edge in r20 w/o the risk of breaking 
something else?

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] pre-release: lxadm

[Dominik Hassler]

Hi,

just wanted to spread the word about lxadm. Its aim is to ease 
creation/editing/duplication of LX zones. Like kvmadm all the 
configuration can be done w/ a single JSON config.


The tool is not very well tested, yet so I am sure there are lots of 
bugs and it lacks tons of features but some of you might want to try it 
already.


By now it only works w/ images from Joyent's images repository (images 
get cached locally) but supporting individual images is on the roadmap.


basic usage:
* list all available images:
# lxadm list-images

* creating a LX zone using e.g. the latest debian 8 (jessie) can be done 
w/ a one-liner
# lxadm create $(lxadm list-images |grep debian-8 |tail -1 |awk '{print 
$1}') 


lxadm can be found on Github:
https://github.com/hadfl/lxadm

To avoid further noise on the mailing list please report issues, feature 
requests on Github only.


Cheers
Dominik


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS/Illumos and entropy

[Dominik Hassler]

Hi,

just a general question. Where does Omnios/Illumos get it's entropy from 
to feed /dev/random.


This is just out of curiosity since I can drain any /dev/random on e.g. 
a linux system (w/o a HWRNG) easily by doing:


$ cat /dev/random

But on OmniOS it is not possible to drain the entropy pool at all on 
/dev/random.


Thanks for any insights.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: How to do networking between host and KVM guest?

[Dominik Hassler]

there is no need for an etherstub for your setup.

I am running the same setup as you mentioned for several kvms (GZ and NGZ) in 
your first e-mail and no issues from guest to {host, outside} or from host 
{guest, outside}.

you shold not assign an address to the vnic that will be used by the kvm.
 
can you ping your guest from the host (hostname and/or IP)? might be a hostname 
resulution problem.

Gesendet: Montag, 15. Februar 2016 um 14:55 Uhr
Von: "Gordon Selisek" 
An: "omnios-discuss@lists.omniti.com" 
Betreff: Re: [OmniOS-discuss] Ang: How to do networking between host and KVM 
guest?

Johan,
 
Thank you, i thought of that, but it's mentioned in oracle docs that Etherstubs 
are a pure software implementation of nics, so the can't communicate with the 
outside word, only and i need that both host and guest can do that, or did i 
misunderstand something?
 
https://docs.oracle.com/cd/E26502_01/html/E28992/gmhfi.html 
 
says:
# dladm create-etherstub etherstub
Perform this step only if you are creating a private virtual network which you 
want to restrict from being accessed by external systems. For a description of 
a private virtual network, see Overview of Network 
Virtualization[https://docs.oracle.com/cd/E26502_01/html/E28992/gfkbw.html#scrolltoc].

 

 

 On Mon, 15 Feb 2016 14:47:29 +0100 Johan Kragsterman 
wrote 

 
 
Hi!
 
 
 
 
-"OmniOS-discuss" 

 skrev: -
Till: "omnios-discuss@lists.omniti.com[omnios-discuss@lists.omniti.com]" 

Från: Gordon Selisek
Sänt av: "OmniOS-discuss"
Datum: 2016-02-15 13:28
Ärende: [OmniOS-discuss] How to do networking between host and KVM guest?
 
Hi all,
 
I ran into a problem, how to do networking between host and KVM guest?
 
I read a lot of oracle documentation, but the virtual networking seems to be 
enough differently implemented, so that i can't wrap my head around it and 
apply it to omniOS.
 
This is what i have, and the guest can communicate with the outside world and 
the host. The host communicate with the outside world, but not the guest. And 
if i assaign an address to vnic0, then the guest can not communicate with the 
host.
 
dladm show-link
LINK    CLASS MTU    STATE    BRIDGE OVER
e1000g0 phys  1500   up   -- --
vnic0   vnic  1500   up   -- e1000g0
 
ipadm show-addr
ADDROBJ   TYPE STATE    ADDR
lo0/v4    static   ok   127.0.0.1/8
e1000g0/lan   static   ok   192.168.200.190/24
lo0/v6    static   ok   ::1/128
 
 
 
Any hints? please?
 
Cordial regards
 
Gordon
 
 
 
You need an internal virtual network, which you get with an internal virtual 
switch: Etherstub. To the etherstub you can connect any virtual interface from 
your host or your guest.
 
/Johan
 
 
 
 
 
 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com[OmniOS-discuss@lists.omniti.com]
http://lists.omniti.com/mailman/listinfo/omnios-discuss
 
 
 
 ___ OmniOS-discuss mailing list 
OmniOS-discuss@lists.omniti.com 
http://lists.omniti.com/mailman/listinfo/omnios-discuss[http://lists.omniti.com/mailman/listinfo/omnios-discuss]
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] zpool fragmentation question

[Dominik Hassler]

Hi there,

on my server at home (OmniOS r16, patched to the latest version) I added a 
brand new zpool (simple 2 HDD mirror).

zpool list shows a fragmentation of 14% on my main pool. I did a recursive 
snapshot on a dataset on the main pool. transferred the dataset via replication 
stream to the new pool (zfs send -R mainpool/dataset@backup | zfs recv -F 
newpool/dataset).

now zpool list shows a fragmentation of 27% on the *newpool* (no other data 
have ever been written to that pool).

How can this be? Was my assumption wrong that send/recv acts like defrag on the 
receiving end?

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 zone has difficulties shutting down

[Dominik Hassler]

Dan,

I remember that in my cases when a zone shutdown got stuck, "zoneadm 
list -cv" showed the state of the hung zone as: shutting_down



On 12/22/2015 02:02 AM, Dan McDonald wrote:

I forgot to mention "zoneadm list -cv".  That would've shown the zone's state.

The pstack for zoneadmd showed this function:

http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/zoneadmd/zoneadmd.c#1089

is waiting for something to only exit a loop after a long wait.

I'm curious which of:  zone_get_state() failing or "zstate == ZONE_STATE_INSTALLED" 
fails?  That's why the "list -cv" would've been nice.

If this happens ever again, some more useful captures:

ptree `pgrep -z `

pargs `pgrep -z `

pstack `pgrep -z `

That'll be a LOT of output, BUT it may provide more clues.

Thanks for this, and sorry I don't have more immediately useful data.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 zone has difficulties shutting down

[Dominik Hassler]

Bob,

I can confirm that this happens occasionally on my systems (all r16 and latest 
patches applied), too. Since it does not happen every shutdown and for a 
different zone every time, I could not find a pattern, yet. Usually I just halt 
the zone if the clean shutdown fails. I don't recall when this occured for the 
first time but it might be after upgrading to r16.
 

> Gesendet: Montag, 07. Dezember 2015 um 01:19 Uhr
> Von: "Bob Friesenhahn" 
> An: omnios-discuss@lists.omniti.com
> Betreff: [OmniOS-discuss] OmniOS r151016 zone has difficulties shutting down
>
> On a freshly installed zone with no additional packages installed (but 
> with one lofs mount to a filesystem), I am seeing a glitch with 
> 'zoneadm -z name shutdown', 'zoneadm -z name reboot' or 'reboot' 
> within the zone.  This message appears on the console and in the 
> /var/adm/messages file of the global zone:
> 
> Dec  6 17:17:22 scrappy zoneadmd[17388]: [ID 702911 daemon.error] 
> [zone 'pkgbuild'] failed to open console master: Device busy
> Dec  6 17:17:22 scrappy zoneadmd[17388]: [ID 702911 daemon.error] 
> [zone 'pkgbuild'] WARNING: could not open master side of zone console 
> for pkgbuild to release slave handle: Device busy
> Dec  6 17:17:22 scrappy zoneadmd[17388]: [ID 702911 daemon.error] 
> [zone 'pkgbuild'] WARNING: console /devices//pseudo/zconsnex@1/zcons@1 
> found, but it could not be removed.: I/O error
> 
> and the shutdown hangs.  If I then do a zlogin to the console (or have 
> already done so) the shutdown immediately completes:
> 
> scrappy:~% pfexec zlogin -C pkgbuild
> [Connected to zone 'pkgbuild' console]
> 
> [NOTICE: Zone halted]
> 
> If I attempt to zlogin into the zone while it is being shut down I get 
> this message:
> 
> zlogin: login allowed only to running zones (pkgbuild is 
> 'shutting_down').
> 
> If I do 'zoneadm -z name reboot', it works fine, although this is 
> documented to be the same as 'shutdown' followed by 'boot'.
> 
> If I do the reboot on the zone console then the reboot works fine.
> 
> This is the second zone that I have installed and the first zone also 
> encountered this issue.  The problem went away with the other zone but 
> still persists for this new zone.
> 
> Have others encountered this issue?  What can be done to fix it?
> 
> Bob
> -- 
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Updates for OmniOS r151014 & r151016

[Dominik Hassler]

> - KVM updates

does this include VND, yet?

On 11/13/2015 09:13 PM, Dan McDonald wrote:

Hello everyone!

I've updated the pkg servers and the install media with updates for r151014 & 
r151016.

Highlights include:

016:
-

- Changing of sendmail in entire.p5m from "require" to "group" (which allows a 
user to uninstall it).
- illumos 6439 (handles KVM guests better)
- KVM updates
- Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
- LSI Fury support
- ilbd memory leak plug.


014:
--

- OpenSSH 7.1p1, including the r151016 method(s) of changing between SunSSH and 
OpenSSH
- Git update to 2.6.1
- tmux update
- illumos 6439 (handles KVM guests better)
- KVM updates
- Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
- LSI Fury support
- TCP timestamping behavior fix (illumos 5850)
- uuidgen(1M) now available
- HW data update to match r151016.
- Several small ZFS fixes (illumos 5219,6288,6267,6367,6319,6385,6334,6386)
- Aggregates no longer attempt to use downed links (illumos 6274)
- glob(3c) now properly deals with large-file 32-bit binaries (you may need to 
locally recompile your custom 32-bit apps)
- Zoneinfo update to 2015g
- ilbd memory leak plug


Happy updating!
Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS r151016: perl build broken?

[Dominik Hassler]

Hi Dan,

after upgrading to r16 I found that znapzend (pure perl program) got stuck in 
maintenance mode. The service status log file revealed the following:
"EINPROGRESS" is not exported by the Errno module

Checking the Errno.pm (core perl module) I found that the %err hash as well as 
the %EXPORT_TAGS hash are empty:
BEGIN {
%err = (
);
...
}

...

our %EXPORT_TAGS = (
POSIX => [qw(
)]
);

The Errno.pm build depends on the errno.h header file (/usr/include/errno.h) 
which I found to be present on some of my OmniOS r16 boxes but not on all of 
them.

As a temporary fix I copied the hashes from another Errno.pm on a non r16 
system.

znapzend users be warned that upgrading to OmniOS r16 will currently stop 
znapzend from working.

Dan, could you please check the presence of errno.h on your building box as 
well as the build of Errno.pm?

Thank you,
Dominik



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 is now out!

[Dominik Hassler]

Hi,

I am facing upgrade problems, too.

Followed the instructions:
- detached all lipkg zones
- unset publisher omnios
- set publisher omnios (to r16)
- did the upgrade to r16
- rebooted

Everything worked as expected so far. However I cannot attach zones anymore.

# zoneadm -z  attach -u
gives the following error:

Installing: Using pre-existing data in zonepath
   Global zone version: entire@11-0.151016:20151102T202622Z
   Non-Global zone version: entire@11-0.151014:20150914T123242Z
 Cache: Using /var/pkg/publisher.
  Updating non-global zone: Output follows
Updating package cache   1/1
Creating Plan (Running solver): /ERROR: Could not update attaching zone
Result: Attach Failed.



If I try to manually update the zone with:
# pkg -R /root update
the following error is shown:

Creating Plan (Running solver): \
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to 
latest available versions.

This may indicate an overly constrained set of packages are installed.

latest incorporations:

  pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z

pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z

pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151016:20151102T183750Z

pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151016:20151102T185924Z

The following indicates why the system cannot update to the latest version:

  No suitable version of required package 
pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z found:

Reject:  pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z
Reason:  A version for 'require' dependency on 
pkg:/package/pkg@0.5.11,5.11-0.151016 cannot be found



Any ideas how to solve this?



On 11/03/2015 10:54 PM, Dan McDonald wrote:



On Nov 3, 2015, at 4:49 PM, Dan McDonald  wrote:


Please check your ms.omniti.com packages.  You can do this by uttering:

pkg update entire@11-0.151016

you will likely see a lot of ms.omniti.com packages that block you from updating 
"entire".  You will either have to uninstall those, or somehow else work around 
that.


I've confirmed on one of my own setups that removing the blocking ms.omniti.com 
packages will cure what ails you.

I've also confirmed the relatively cheesy workaround of uninstalling "entire" 
also works.

Hope this helps,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 is now out!

[Dominik Hassler]

no I can't:

pkg -R /root update pkg:/package/pkg@0.5.11,5.11-0.151016
Creating Plan (Solver setup): |
pkg update: No matching version of package/pkg can be installed:
  Reject:  pkg://omnios/package/pkg@0.5.11,5.11-0.151016:20151102T194048Z
  Reason:  All versions matching 'require' dependency 
pkg:/SUNWcs@0.5.11,5.11-0.151016 are rejected

Reject:  pkg://omnios/SUNWcs@0.5.11,5.11-0.151016:20151102T183755Z
Reason:  This version is excluded by installed incorporation 
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20150929T225300Z
 This version is excluded by installed incorporation 
pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151014:20150402T174324Z
   Global zone has an older version of package: 
pkg://omnios/package/pkg@0.5.11,5.11-0.151014:20150402T184307Z


in the GZ:
$ pkg list package/pkg
NAME (PUBLISHER)  VERSION 
 IFO
package/pkg   0.5.11-0.151016 
 i--




On 11/04/2015 12:07 AM, Michael Rasmussen wrote:

On Tue, 03 Nov 2015 23:17:39 +0100
Dominik Hassler <hassl...@gmx.li> wrote:



The following indicates why the system cannot update to the latest version:

No suitable version of required package 
pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z found:
  Reject:  pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z
  Reason:  A version for 'require' dependency on 
pkg:/package/pkg@0.5.11,5.11-0.151016 cannot be found



Are you able to upgrade pkg before doing pkg update?



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 is now out!

[Dominik Hassler]

I have no ms.omniti.com packages. Just a couple of own packages which 
are not depending on a particular release.


On 11/04/2015 01:21 AM, Dan McDonald wrote:



On Nov 3, 2015, at 7:17 PM, Dominik Hassler <hassl...@gmx.li> wrote:

when the first attach failed I reset the publishers in the NGZ manually, 
however attach/pkg update still failed.

Rebooted now into the old r14 backup BE, attached the zones and am using the 
lipkg update procedure now. Looking good so far. Will report back once 
successfully finished.


If you have any ms.omniti.com packages, watch out.  They often block upgrades.

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151016 is now out!

[Dominik Hassler]

when the first attach failed I reset the publishers in the NGZ manually, 
however attach/pkg update still failed.


Rebooted now into the old r14 backup BE, attached the zones and am using 
the lipkg update procedure now. Looking good so far. Will report back 
once successfully finished.



On 11/04/2015 01:02 AM, Dan McDonald wrote:



On Nov 3, 2015, at 6:15 PM, Dominik Hassler <hassl...@gmx.li> wrote:

no I can't:

pkg -R /root update pkg:/package/pkg@0.5.11,5.11-0.151016
Creating Plan (Solver setup): |
pkg update: No matching version of package/pkg can be installed:
  Reject:  pkg://omnios/package/pkg@0.5.11,5.11-0.151016:20151102T194048Z
  Reason:  All versions matching 'require' dependency 
pkg:/SUNWcs@0.5.11,5.11-0.151016 are rejected
Reject:  pkg://omnios/SUNWcs@0.5.11,5.11-0.151016:20151102T183755Z
Reason:  This version is excluded by installed incorporation 
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20150929T225300Z
 This version is excluded by installed incorporation 
pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151014:20150402T174324Z
   Global zone has an older version of package: 
pkg://omnios/package/pkg@0.5.11,5.11-0.151014:20150402T184307Z

in the GZ:
$ pkg list package/pkg
NAME (PUBLISHER)  VERSION  IFO
package/pkg   0.5.11-0.151016  i--


What's the publisher for /root ?

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] disk failure causing reboot?

[Dominik Hassler]

Jeff,

I have them WD40001FYYG drives in my home server but just as a simple 
mirror. AFAIK those drives are equivalent to the SATA WD Re 4GB drives 
but just w/ a SAS controller instead a SATA controller on top and just a 
little more expensive than their SATA equivalents...


I have no real facts but I assume that these SAS drives (they call them 
nearline SAS) are not 100% like real SAS drives... E.g. they don't 
run automated background scans, that's what I observed. In what extent 
they differ from real SAS drives, I don't know.


On 05/18/2015 09:01 PM, Jeff Stockett wrote:

Hi Dan,

The pool is made up of 36 disks - 6 x 6 raidz2 vdevs with some SSDs for l2arc 
and slog.  I already replaced the drive and the rebuild is nearly done, but I 
was mostly curious why a disk failure would cause a reboot?  I get that it was 
apparently hanging the pool up, and that according to some posts I read the 
developers seem to think it is better the panic/dump/reboot than leave it hung 
until someone notices, but wouldn't it really be better just to drop the failed 
drive out of the array? Is it because the system in question is using a SAS 
expander or is this only expected behavior sometimes depending on how the drive 
fails?  I guess I might expect this with consumer grade SATA drives, but wasn't 
expecting it with $$$ enterprise SAS drives.

Thanks,  Jeff

-Original Message-
From: Dan McDonald [mailto:dan...@omniti.com]
Sent: Monday, May 18, 2015 11:33 AM
To: Jeff Stockett
Cc: omnios-discuss
Subject: Re: [OmniOS-discuss] disk failure causing reboot?



On May 18, 2015, at 2:25 PM, Jeff Stockett jstock...@molalla.com wrote:

A drive failed in one of our supermicro 5048R-E1CR36L servers running omnios 
r151012 last night, and somewhat unexpectedly, the whole system seems to have 
panicked.


The panic was done for protection of your pool:


May 18 04:44:36 zfs01 genunix: [ID 918906 kern.notice] I/O to pool 'dpool' 
appears to be hung.


SNIP!



The disks are all 4TB WD40001FYYG enterprise SAS drives.  Googling seems to 
indicate it is a known problem with the way the various subsystems sometimes 
interact. Is there any way to fix/workaround this issue?


Pull the drive.  I'm assuming you have a raidz or mirrored setup where you can 
do that, right?  Or is it a question of finding *which* drive failed?

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ping rtt for KVM in zone

[Dominik Hassler]

Matthew,

I have 'Intel I350' nics. It is not about virtio performance in general but the 
difference whether the *same* KVM runs in the GZ or in a NGZ.

 Gesendet: Mittwoch, 13. Mai 2015 um 11:11 Uhr
 Von: Matthew Lagoe matthew.la...@subrigo.net
 An: 'Dominik Hassler' hassl...@gmx.li, omnios-discuss@lists.omniti.com
 Betreff: RE: [OmniOS-discuss] ping rtt for KVM in zone

 Some nic's don’t handle the virtio stuff very well (myricom im looking at 
 you) so that could be part of the problem
 
 Intel typically is pretty good about it however so the e1000's working 
 doesn’t surprise me.
 
 What nics are you specifically having issues with that have the extra delay?
 
 -Original Message-
 From: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] On 
 Behalf Of Dominik Hassler
 Sent: Wednesday, May 13, 2015 02:03 AM
 To: omnios-discuss@lists.omniti.com
 Subject: [OmniOS-discuss] ping rtt for KVM in zone
 
 Hi,
 
 I am running my KVMs in individual zones and seeing an increased ping rtt by 
 a factor of approx. 7 compared to ping rtt when running the same KVM inside 
 the GZ (cf. attached smokeping chart).
 
 This does *only* affect virtio nics but not e1000 nics. For e1000 nics the 
 ping rtt remains the same, no matter if the KVM runs in the GZ or a NGZ.
 
 Dan's 'KVM Performance Update' did resolve the throughput issue, but not the 
 strange ping behaviour I am seeing.
 
 Any ideas why it only affects virtio nics and when the KVM is in a zone? Any 
 ideas how to improve it?
 
 

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ping rtt for KVM in zone

[Dominik Hassler]

Hi,

I am running my KVMs in individual zones and seeing an increased ping rtt by a 
factor of approx. 7 compared to ping rtt when running the same KVM inside the 
GZ (cf. attached smokeping chart).

This does *only* affect virtio nics but not e1000 nics. For e1000 nics the ping 
rtt remains the same, no matter if the KVM runs in the GZ or a NGZ.

Dan's 'KVM Performance Update' did resolve the throughput issue, but not the 
strange ping behaviour I am seeing.

Any ideas why it only affects virtio nics and when the KVM is in a zone? Any 
ideas how to improve it?___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] KVM Performance Update

[Dominik Hassler]

I've applied yesterday's kvm performance patch, did performance tests and 
posted the results in tobi's sheet.


Sent from my Samsung device

 Original message 
From: Dan McDonald dan...@omniti.com 
Date: 13/05/2015  20:28  (GMT+01:00) 
To: Michael Rasmussen m...@miras.org 
Cc: omnios-discuss@lists.omniti.com 
Subject: Re: [OmniOS-discuss] KVM Performance Update 


 On May 13, 2015, at 2:14 PM, Michael Rasmussen m...@miras.org wrote:
 
 Has someone made performance test with the patched kvm package?

Tobi's sheet has a preliminary version.  Not sure if he's tested with the one 
that actually is in the repo servers now.

ALSO, 012 got the perf fix because it was easier to bring that along for the 
ride instead of addressing VENOM by itself for 012.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discussi
​___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] KVM Performance Update

[Dominik Hassler]

Well, don't forget, my latest tests were w/ KWMs running inside zones. 
As Dan pointed out today in another thread, the lack of VND upstream 
might have a bigger impact on KVMs running inside zones.


On 05/13/2015 10:13 PM, Michael Rasmussen wrote:

On Wed, 13 May 2015 14:28:22 -0400
Dan McDonald dan...@omniti.com wrote:



Tobi's sheet has a preliminary version.  Not sure if he's tested with the one 
that actually is in the repo servers now.

ALSO, 012 got the perf fix because it was easier to bring that along for the 
ride instead of addressing VENOM by itself for 012.


If I read the numbers correct I still find the performance
disappointing with the patch. Doing the same kind of test using Linux
or FreeBSD host to Linux or FreeBSD guest gives much higher performance.



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Setting up KVM in a zone

[Dominik Hassler]

Dan,

I am about to setting up my KVM's within zones. Making good progress so far. 
However it is not possible to add zvols as dataset resource as mentioned in 
the wiki ( http://omnios.omniti.com/wiki.php/VirtualMachinesKVM ) but as 
device resource:

 zonecfg add device
 zonecfg set match=/dev/zvol/rdsk/rpool/kvm-zvol
 zonecfg end

You might wanna fix the wiki or am I completely wrong?

Kind regards
Dominik
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Potential KVM Virtio Performance Issues

[Dominik Hassler]

Dan,

 After further testing I achieved 952 MBytes on a VM-2-VM
 connection...1
 linux Ubuntu 12.04 vm to another CentOS 6.6 VM running on two
 different SmartOS host machines (through an extreme networks switch).

if I got John correctly, he was running his second test on SmartOS hosts...

We did a lot of testing on OmniOS with -net vnic and -device
virtio-net-pci but sadly to no avail...

I think we have to hope that SmartOS kvm improvements will get
upstreamed sooner or later.

On 03/24/2015 11:47 PM, Dan McDonald wrote:
 
 On Mar 24, 2015, at 5:34 PM, John Barfield john.barfi...@bissinc.com wrote:


 They use this format:

 -device \
 virtio-net-pci,mac=02:08:20:5f:85:0d,tx=timer,x-txtimer=20,x-txburst=12
 8,vlan=0 \
 \
 -net \
 vnic,name=${VNIC1},vlan=0,ifname=${VNIC1} \
 
 I’m not sure if the txtimer values did anything performance gaining or 
 not…I’m pretty sure just switching to the -device configuration instead of 
 the legacy -net nic configuration is what did the trick. 

 If anyone wants me to I’ll test and see if that was the only difference. 
 
 I would be interested, especially so if we have to update our KVM page to 
 mention this.
 
 Thanks!
 Dan
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010

[Dominik Hassler]

never mind, it's getting filled later on.

should have had a look at the whole of it before starting to bark :/

sorry for the noise!

On 02/20/2015 11:14 PM, Dominik Hassler wrote:
 Dan,
 
 I had a look at HVM-807 you mentioned.
 
 Shouldn't line 251 in 'net/vnic.c' be
 for (i = 0; i  MIN(iovcnt, FRAMEIO_NVECS_MAX); i++, iov++) {
 
 instead of
 for (i = 0; i  MIN(iovcnt, FRAMEIO_NVECS_MAX - 1); i++, iov++) {
 
 As otherwise the last element of the frameio will not be used at all if
 iovcnt is greater than the frameio buffer size?
 
 Kind regards
 Dominik
 
 On 02/20/2015 09:17 PM, Dan McDonald wrote:

 On Feb 20, 2015, at 2:58 PM, Tobias Oetiker t...@oetiker.ch wrote:

 Hi Dan,

 I do not have a spare machine to test this, but if the dramatic
 network io performance regression for kvm present in r151012 has
 not been fixed in r151014 then we will be stranded on r151010.

 And the upstreaming of VND is likely not to happen with this release.  That 
 blocks us from properly catching up with illumos-kvm-cmd.

 There are several commits (Starting with the March 19th one we can't bring 
 in w/o VND) here:

  https://github.com/joyent/illumos-kvm-cmd/commits/master

 Currently, we only backport the most recent fix about QEMU using 
 preadv/pwritev recklessly.  IF (big if) there are other commits we can 
 backport, you could try it using the patches/ directory of omnios-build.  
 I'm thinking maybe HVM-807's may help you (provided that's indepdent of VND 
 support).

 Have you seen anything with dtrace or lockstat that could give a clue to 
 what's holding things up?  I don't recall seeing anything observed.

 Judging from the echo on the ML, not many people seem to see this
 problem, or care about it.

 I'm sorry, but that does appear to be the case.

 Next week I disappear for other-customer work, but starting in March, I'm 
 doing nothing but r151014.

 Dan

 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss



 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010

[Dominik Hassler]

Dan,

I had a look at HVM-807 you mentioned.

Shouldn't line 251 in 'net/vnic.c' be
for (i = 0; i  MIN(iovcnt, FRAMEIO_NVECS_MAX); i++, iov++) {

instead of
for (i = 0; i  MIN(iovcnt, FRAMEIO_NVECS_MAX - 1); i++, iov++) {

As otherwise the last element of the frameio will not be used at all if
iovcnt is greater than the frameio buffer size?

Kind regards
Dominik

On 02/20/2015 09:17 PM, Dan McDonald wrote:
 
 On Feb 20, 2015, at 2:58 PM, Tobias Oetiker t...@oetiker.ch wrote:

 Hi Dan,

 I do not have a spare machine to test this, but if the dramatic
 network io performance regression for kvm present in r151012 has
 not been fixed in r151014 then we will be stranded on r151010.
 
 And the upstreaming of VND is likely not to happen with this release.  That 
 blocks us from properly catching up with illumos-kvm-cmd.
 
 There are several commits (Starting with the March 19th one we can't bring in 
 w/o VND) here:
 
   https://github.com/joyent/illumos-kvm-cmd/commits/master
 
 Currently, we only backport the most recent fix about QEMU using 
 preadv/pwritev recklessly.  IF (big if) there are other commits we can 
 backport, you could try it using the patches/ directory of omnios-build.  I'm 
 thinking maybe HVM-807's may help you (provided that's indepdent of VND 
 support).
 
 Have you seen anything with dtrace or lockstat that could give a clue to 
 what's holding things up?  I don't recall seeing anything observed.
 
 Judging from the echo on the ML, not many people seem to see this
 problem, or care about it.
 
 I'm sorry, but that does appear to be the case.
 
 Next week I disappear for other-customer work, but starting in March, I'm 
 doing nothing but r151014.
 
 Dan
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] 6TB HDs

[Dominik Hassler]

AFAIK it depends on what the disks report.

if they report 4k you are fine. if they report 512e, check if they are
on the list, if not, add them:
http://wiki.illumos.org/display/illumos/List+of+sd-config-list+entries+for+Advanced-Format+drives

On 01/15/2015 03:39 PM, Tobias Oetiker wrote:
 Fabio,
 
 Today Fábio Rabelo wrote:
 
 Hi to all

 In a new system, will be used just 6 TB Hard Discs, with LSI controlers, no
 expander whasoever .
 
 there are 6TB 512n disks now ... just saying ...
 
 cheers
 tobi
 
 
 WD RED, TQ chassis from supermicro .

 I need to set Ashift to 12, or the Omni will do it automatically ?

 Thanks in advance ...

 
 
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] KVM within a child zone

[Dominik Hassler]

Michael,

you might wanna give kvmadm a try ( https://github.com/hadfl/kvmadm ).

that'll help you putting your kvms under smf control.

at least you should be able to extract all the infos from there...

On 12/23/2014 09:14 PM, Michael Mounteney wrote:
 Brilliant, with a bit more fiddling I've got it so that the KVM
 instances can be started within the child zone, AND shut down cleanly
 via the command echo system_powerdown | nc -U /var/run/KDE.monsock so
 the next step is to put them into a service so that they can be brought
 up and down within SMF.
 
 Thanks again to all for their help.
 
 Michael.
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] dedup causes zfs/omnios to drop connections.

[Dominik Hassler]

Hi,

we used dedup on a production machine w/ 256 GB RAM, but disabled it
after a couple of days due to huge performance impact.

I would not recommend to use dedup even when having enough RAM.

On 12/15/2014 09:53 PM, Dan McDonald wrote:
 
 On Dec 15, 2014, at 3:43 PM, Rune Tipsmark r...@steait.net wrote:

 hi all,
  
 got a new system I was intending on using as backup repository. Whenever 
 dedup is enabled it dies after anywhere between 5 and 30 minutes. I need to 
 reboot OmniOS to get it back online.
 the files being copied onto the zfs vols are rather large, about ~2TB 
 each... if I copy smaller files, say 400GB or so, it takes longer for it to 
 crash.
  
 what can be done to fix this? after Windows (initiator) looses the 
 connection (both Fibre Channel and iSCSI) I still see a lot of disk activity 
 using iostat - disks remain active for minutes after the copying has died... 
 its like ZFS cannot handle dedup of large files.. 
 
 Dedup is a memory pig and not very well implemented in ZFS.  I'd highly 
 recommend against it in production.  Either that, or really increase your 
 memory for your system in question.  There was some work going on at Nexenta 
 to perhaps put the dedup tables (DDTs) onto a dedicated slog-like device, but 
 I believe that work stalled.
 
 Sorry,
 Dan
 
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HP Z230 as a home server

[Dominik Hassler]

got all the hardware and set up the system. it works great.

wanted to share the final HW setup in case someone plans to build a
similar system:

- MBD-X10SL7-F (LSI 2308 SAS flashed to IT firmware)
- Xeon E3-1231v3
- 2x WD Xe (SAS) 300G (rpool mirror)
- 2x WD Re (SAS) 4T   (data mirror)
- 32G samsung ECC ram according to supermicro compatibility list
- Lian Li PC-V358 case

thank you all for your help!


On 10/25/2014 09:35 PM, Tim Rice wrote:
 On Wed, 22 Oct 2014, Dominik Hassler wrote:
 
 [snip]
 - MBD-X10SLM-F-O mainboard
 - Xeon E3-1231v3 (this time w/ HT)
 - 4x 8 GB KTH-PL316EK4/32G
 - 2x SSD DC S3500 (rpool mirror)
 - 2x WD RE 4T (data mirror)
 - Lian Li PC-V358 case
 [snip]
 does anyone have (good or bad) experience with the kingston RAM
 mentioned above?
 
 Kingston RAM didn't work on a MBD-X9SCM-F-0 board here. Had to buy new ram.
 I recommend you stick with whatever RAM supermicro says is tested
 on your board.
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HP Z230 as a home server

[Dominik Hassler]

On 11/21/2014 05:24 PM, Michael Rasmussen wrote:
 On Fri, 21 Nov 2014 17:03:18 +0100
 Dominik Hassler hassl...@gmx.li wrote:
 
 - 2x WD Re (SAS) 4T   (data mirror)
 Are you sure its SAS and not SATA? I have not seen 2/4T SAS disks before.

yeah, am sure:
- WD4001FYYG (
http://www.wdc.com/global/products/specs/?driveID=1184language=1 )
 
 
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: Ang: Re: Ang: Re: Ang: Re: Ang: Re: Ang: Re: KVM and SMF

[Dominik Hassler]

try to name the dependency 'pfsense' instead of 'kvm/pfsense'. i don't
think that '/' is an allowed character for property names...

it would also help if you attach the manifest you are trying to import.

as lauri mentioned before: you can set all the properties directly with
svccfg, no need to fiddle around with the manifests.

On 11/06/2014 04:07 PM, Johan Kragsterman wrote:
 Here I am Again as a follow up...
 
 
 
 -OmniOS-discuss omnios-discuss-boun...@lists.omniti.com skrev: -
 Till: Lauri Tirkkonen loth...@iki.fi
 Från: Johan Kragsterman 
 Sänt av: OmniOS-discuss 
 Datum: 2014-11-06 15:22
 Kopia: omnios-discuss@lists.omniti.com
 Ärende: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: Ang: Re: Ang: Re: KVM 
 and SMF
 
 Hi!
 
 -Lauri Tirkkonen loth...@iki.fi skrev: -
 Till: Johan Kragsterman johan.kragster...@capvert.se
 Från: Lauri Tirkkonen loth...@iki.fi
 Datum: 2014-11-06 14:31
 Kopia: Jorge Schrauwen sjorge...@blackdot.be, 
 omnios-discuss@lists.omniti.com
 Ärende: Re: Ang: Re: Ang: Re: [OmniOS-discuss] Ang: Re: Ang: Re: KVM and SMF
 
 On Thu, Nov 06 2014 14:27:20 +0100, Johan Kragsterman wrote:
 That is not parsable...

 root@omni:/mainpool/nfs/Backup/KVM# svccfg import pfkvm.xml
 pfkvm.xml:13: parser error : xmlParseEntityRef: no name
 exec_method type='method' exec='/usr/bin/vmpfsense.sh ' 
 name='start' timeout
 ^
 svccfg: couldn't parse document
 root@omni:/mainpool/nfs/Backup/KVM#
 
 Then I guess you need to escape it (amp;). It's easier to set with
 svccfg anyways.
 
 
 
 
 
 
 That did the trick! Thanks! I bet it is many others that have been struggling 
 with this as well...
 
 
 And as well:
 
 I've been looking at svccfg(1M) but can't say I can figure out what to do to 
 get the service to demonize...
 
 Would be nice to learn...
 
 
 Regards Johan
 
 
 
 
 
 
 My kvm/pfsense is of coarse a firewall and router, and I wanted it to start 
 before other VM's, så the other VM's could get a route directly when they 
 start.
 
 So I set a dependency for my kvm/edu for kvm/pfsense, but that wasn't as easy 
 as I thought it would. It failed with this msg:
 
 
 root@omni:/mainpool/nfs/Backup/KVM# svccfg import edukvm.xml
 svccfg: Service svc:/kvm/edu has property group with invalid name 
 kvm/pfsense or type dependency.
 svccfg: Import of edukvm.xml failed.  Progress:
 svccfg:   Service kvm/edu: not reached.
 svccfg: Instance default: not reached.
 svccfg: Import of edukvm.xml failed.
 
 
 For me this seems to be something like the kvm/pfsense service is not 
 properly placed. Like other smf services who has their directories in:
 /lib/svc/manifest and in /var/svc/manifest, like application  device  
 milestone  network  platform  site  system.
 
 Could that be the case? Someone knows something about this, and what could be 
 done? Like creating a directory for kvm? Or putting the service under an 
 already existing directory?
 
 What do OmniTI do for managing this?
 
 
 Regards Johan
 
 
 
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HP Z230 as a home server

[Dominik Hassler]

your inputs made me rethink my strategy. especially IPMI capability of
the X10SLM-F. and all that for a decent price...

so instead of going for a dealer pre-configured HP solution which offers
me very little flexibility, i'll make my own based on your suggestions
whilst saving some money on top:

- MBD-X10SLM-F-O mainboard
- Xeon E3-1231v3 (this time w/ HT)
- 4x 8 GB KTH-PL316EK4/32G
- 2x SSD DC S3500 (rpool mirror)
- 2x WD RE 4T (data mirror)
- Lian Li PC-V358 case

@dan: can you give some details about your SSD wear-leveling setup? is
it basically just a slice of 20GB (why 20?) of unallocated disk space or
is there more magic behind it?

does anyone have (good or bad) experience with the kingston RAM
mentioned above?

thanks
dominik

On 10/21/2014 11:09 PM, R. Matthew Emerson wrote:
 
 On Oct 21, 2014, at 4:24 PM, Dan McDonald dan...@omniti.com wrote:
 

 On Oct 21, 2014, at 3:25 PM, Dominik Hassler hassl...@gmx.li wrote:

 SNIP!

 of course i'd like to have an omnios server at home, too. nothing fancy,
 basically just for data storage (nfs and smb sharing) and 1-2 linux kvms
 for multimedia services and auxiliary stuff. since i don't have a
 dedicated room where noise does not matter i have to consider quiet
 workstation hardware instead of noisy server hardware.

 here is the hardware setup i am planning to go with:
 - HP Z230 (WM583EA#UUZ) which is basically

 http://www8.hp.com/us/en/campaigns/workstations/z230.html

 Interesting.  It's a socket 1150 workstation.  Good for illumos.

 - Intel PCH C226 chipset
 - E3-1225v3 quad core XEON

 Gotta get that ECC support.  Also, while not HT, it does have good clock 
 speed ( 3GHz).

 - Intel I217LM PCIe Gigabit-Controller

 Supported, and relatively new.  Should show up as e1000g.  I notice you can 
 get a 2nd ethernet with an I210. This would show up as igb.

 - 4x 8 GB ECC RAM (HP A2Z50AA)

 Gotta do ECC!

 - 1x 1 TB WD Re, S-ATA III (512n) as rpool
 - 2x 4 TB WD Re, S-ATA III (512n) as a data mirror

 I might swap in an SSD for rpool, but that's just me.  (NOTE:  If you do use 
 an SSD, don't use it for swap, though with 32GB, you won't need swap at 
 all).  And for your data, it doesn't matter (I don't think) if it's 512 or 
 4k sectors, just so long as you know what it is up front, they MATCH, and 
 set things appropriately when creating the pool.

 If others here have opinions, you ought to share 'em.  I'm running a 
 Supermicro not unlike what the HP offers:

  
 http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html

 I got more NICs though.  :)
 
 
 My small home server is a Supermicro X10SLM-F-O with a Xeon 1230v3 in a 
 Supermicro CSE-731i-300B case.  The board is nice because it has two NICs 
 (one e1000g, one igb), and also a dedicated one for IPMI.  I used memory from 
 Crucial (CT2KIT102472BD160B) and a pair of Toshiba 2 TB disks (PH3200U-1I72) 
 as my data pool (on sale at the local Micro Center).  I'm using a 500GB 
 Hitachi disk that I happened to have around for my rpool.
 
 This ended up being around $900, which I thought was way cheap.
 
 If I did it again, I might consider the larger 732 series case, which is 
 supposed to be a little bit quieter.  My desktop box is a pretty quiet 27 
 iMac, and I can hear the Supermicro box's fans from about 5 feet away.  The 
 noise not really objectionable, but it's not silent either.
 
 The only problem I had with this hardware was that fastboot would hang, but 
 the suggestion in http://article.gmane.org/gmane.os.omnios.general/1043 
 solved that.
 
 I would have gone with a factory-built box, but Dell wasn't selling Haswell 
 Xeon E3 systems at the time, and HP was trying hard to discourage customers 
 from using non-HP disks.
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] HP Z230 as a home server

[Dominik Hassler]

hi,

it's about a year since i got in touch with illumos/solaris and zfs for
the first time. i absolutely don't want to miss it anymore, especially
zfs. omniti/dan and the whole illumos community are doing a great job.
thank you!


of course i'd like to have an omnios server at home, too. nothing fancy,
basically just for data storage (nfs and smb sharing) and 1-2 linux kvms
for multimedia services and auxiliary stuff. since i don't have a
dedicated room where noise does not matter i have to consider quiet
workstation hardware instead of noisy server hardware.

here is the hardware setup i am planning to go with:
- HP Z230 (WM583EA#UUZ) which is basically
  - Intel PCH C226 chipset
  - E3-1225v3 quad core XEON
  - Intel I217LM PCIe Gigabit-Controller

- 4x 8 GB ECC RAM (HP A2Z50AA)
- 1x 1 TB WD Re, S-ATA III (512n) as rpool
- 2x 4 TB WD Re, S-ATA III (512n) as a data mirror


what do you think about this hardware setup? any no-gos?

thanks
dominik


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HP Z230 as a home server

[Dominik Hassler]

dan,

i will definitely go for the 2 nic option; did overlook that somehow...
and take an intel S3500 SSD as rpool (non mirrored).


thanks again
dominik

On 10/21/2014 10:24 PM, Dan McDonald wrote:
 
 On Oct 21, 2014, at 3:25 PM, Dominik Hassler hassl...@gmx.li wrote:
 
 SNIP!
 
 of course i'd like to have an omnios server at home, too. nothing fancy,
 basically just for data storage (nfs and smb sharing) and 1-2 linux kvms
 for multimedia services and auxiliary stuff. since i don't have a
 dedicated room where noise does not matter i have to consider quiet
 workstation hardware instead of noisy server hardware.

 here is the hardware setup i am planning to go with:
 - HP Z230 (WM583EA#UUZ) which is basically
 
 http://www8.hp.com/us/en/campaigns/workstations/z230.html
 
 Interesting.  It's a socket 1150 workstation.  Good for illumos.
 
  - Intel PCH C226 chipset
  - E3-1225v3 quad core XEON
 
 Gotta get that ECC support.  Also, while not HT, it does have good clock 
 speed ( 3GHz).
 
  - Intel I217LM PCIe Gigabit-Controller
 
 Supported, and relatively new.  Should show up as e1000g.  I notice you can 
 get a 2nd ethernet with an I210. This would show up as igb.
 
 - 4x 8 GB ECC RAM (HP A2Z50AA)
 
 Gotta do ECC!
 
 - 1x 1 TB WD Re, S-ATA III (512n) as rpool
 - 2x 4 TB WD Re, S-ATA III (512n) as a data mirror
 
 I might swap in an SSD for rpool, but that's just me.  (NOTE:  If you do use 
 an SSD, don't use it for swap, though with 32GB, you won't need swap at all). 
  And for your data, it doesn't matter (I don't think) if it's 512 or 4k 
 sectors, just so long as you know what it is up front, they MATCH, and set 
 things appropriately when creating the pool.
 
 If others here have opinions, you ought to share 'em.  I'm running a 
 Supermicro not unlike what the HP offers:
 
   
 http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html
 
 I got more NICs though.  :)
 
 Thanks, and hope this helps,
 Dan
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Failing zfs send / receive

[Dominik Hassler]

hi chris,

have you ever checked if you run out of entropy?

On 12/28/2013 06:22 PM, Chris Nagele wrote:
 Hi Michael,
 
 I tried those settings with no luck. I also tested network latency,
 routes, throughput with netperf, etc. The network side is perfectly
 fine with no packet loss over a long period of time.
 
 What I do see is ssh hanging for 10 seconds or so if I run commands
 over it. For instance, if I run ssh -vvv host ls -l a bunch of times
 it is usually very fast, but will hang every 30 times for several
 seconds.
 
 Due to the way our backups work we run a lot of remote ssh commands
 (100+ every 60 seconds). Is there something we could try in terms of
 increasing ssh performance? Or is there anything else I can look at to
 troubleshoot?
 
 Thanks for the help.
 
 Chris
 
 On Thu, Dec 26, 2013 at 12:52 PM, Michael Rasmussen m...@miras.org wrote:
 On Thu, 26 Dec 2013 12:31:30 -0500
 Chris Nagele nag...@wildbit.com wrote:


 Any ideas what could cause this timeout or if it is something I can 
 increase?

 Do you have this config in sshd_config on the remote side:
 GSSAPIAuthentication no

 If GSSAPIAuthentication is active you sometimes see timeouts cause by
 the remote side waiting for GSSAPIAuthentication which by default first
 will timeout after 20 sec.

 Other configs of interest:
 LookupClientHostnames no
 VerifyReverseMapping no

 --
 Hilsen/Regards
 Michael Rasmussen

 Get my public GnuPG keys:
 michael at rasmussen dot cc
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E
 mir at datanom dot net
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C
 mir at miras dot org
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917
 --
 Lost: gray and white female cat.  Answers to electric can opener.

 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss

 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] apache22 after upgrading to r151008

[Dominik Hassler]

hmm, my point was the following:

these older versions (installed on my r151006) prevented me from
upgrading, but now can be installed again (the same versions that have
been installed) after the upgrade has been finished.

why does a piece of software prevent me from upgrading if it can be
installed again (same version as before) after upgrading?

sorry i'm quite new to omnios.

On 12/10/2013 04:55 PM, Theo Schlossnagle wrote:
 You are likely getting older versions that don't rely on 151006.
 
 At some point in the lifecycle of ms.omniti.com http://ms.omniti.com
 we opted to make the packages depend on the release.
 
 
 On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler hassl...@gmx.li
 mailto:hassl...@gmx.li wrote:
 
 hi there,
 
 to be able to install omnios-userland@11,5.11-0.151006 and upgrade
 omnios to r151008 i had to remove serveral ms.omniti packages, including
 apache22.
 
 however after successfully upgrading omnios to r151008, if i dry-run
 install apache22 again it looks like there won't be any issues.
 
 # cat /etc/release
   OmniOS v11 r151008
   Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
   Use is subject to license terms.
 
 # pkg list |grep omnios-userland
 incorporation/jeos/omnios-userland   11-0.151008 i--
 
 # pkg install -nv omniti/server/apache22
Packages to install: 4
  Estimated space available: 197.32 GB
 Estimated space to be consumed:  66.73 MB
Create boot environment:No
 Create backup boot environment:No
   Rebuild boot archive:No
 
 Changed packages:
 ms.omniti.com http://ms.omniti.com
   omniti/library/apr
 None - 1.4.6,5.11-0.151002:20120401T205441Z
   omniti/library/apr-util
 None - 1.4.1,5.11-0.151002:20120401T200739Z
   omniti/library/uuid
 None - 1.41.14,5.11-0.151002:20120401T185308Z
   omniti/server/apache22
 None - 2.2.25,5.11-0.151006:20130904T164853Z
 
 
 
 this seems odd to me. how can this be explained?
 
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com mailto:OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
 
 
 
 
 -- 
 
 Theo Schlossnagle
 
 http://omniti.com/is/theo-schlossnagle
 


0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss