Re: [OmniOS-discuss] Local zone regression in CE bloody
I couldn't find any specific instructions for moving to bloody so I kind of made them up based on the previous omnios upgrade instructions. I went ahead and set the signature-policy to ignore and now I'm good. On Fri, Jul 21, 2017, at 08:54 PM, Dan McDonald wrote: > In the past, bloody was never signed. Has CE changed that policy? > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > > On Jul 21, 2017, at 7:11 PM, Ryan Zezeski <r...@zinascii.com> wrote: > > > > Hey everyone, > > > > I've been trying to reproduce this but can't seem to get my omniosce > > onto bloody. I see the following: > > > > root@midgar:~# pkg unset-publisher omnios > > Updating package cache 1/1 > > root@midgar:~# pkg set-publisher -P --set-property > > signature-policy=require-signatures -g > > https://pkg.omniosce.org/bloody/core/ omnios > > root@midgar:~# pkg update --be-name=bloody -rv > > > > pkg update: The policy for omnios requires signatures to be present but > > no signature was found in > > pkg://omnios/locale/gu@0.5.11,5.11-0.151023:20170718T063512Z. > > > > Should I change the signature-policy? > > > > -Ryan > > > >> On Fri, Jul 21, 2017, at 06:17 AM, Andy Fiddaman wrote: > >> > >> > >> On Fri, 21 Jul 2017, Jim Klimov wrote: > >> > >> ; Hi all, > >> ; > >> ; I have an OmniOS bloody box that was last running 151023. Yesterday I > >> updated it to latest available original omnios from May 15 or so, and > >> updated that BE to omniosce bloody. Between the two, zone shutdown > >> stopped working for me (both ipkg and lx), with the ce variant claiming > >> that "datalinks remain in zone after shutdown / unable to unconfigure > >> network interfaces in zone / unable to destroy zone". > >> ; > >> ; When the zone boots it seems okay and usable, but when trying to halt > >> it - becomes "down" and I can not change the state (no > >> boot/mount/ready/... options succeed); killing its zoneadmd and wiping > >> then/var/run/zones also does not help - only GZ reboot. > >> > >> Thanks Jim, confirmed here too. > >> We are building a new bloody at the moment so will test with that and > >> then > >> work on a fix. I've opened an issue for this at > >> > >> https://github.com/omniosorg/illumos-omnios/issues/18 > >> > >> 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 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Local zone regression in CE bloody
Hey everyone, I've been trying to reproduce this but can't seem to get my omniosce onto bloody. I see the following: root@midgar:~# pkg unset-publisher omnios Updating package cache 1/1 root@midgar:~# pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniosce.org/bloody/core/ omnios root@midgar:~# pkg update --be-name=bloody -rv pkg update: The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/locale/gu@0.5.11,5.11-0.151023:20170718T063512Z. Should I change the signature-policy? -Ryan On Fri, Jul 21, 2017, at 06:17 AM, Andy Fiddaman wrote: > > > On Fri, 21 Jul 2017, Jim Klimov wrote: > > ; Hi all, > ; > ; I have an OmniOS bloody box that was last running 151023. Yesterday I > updated it to latest available original omnios from May 15 or so, and > updated that BE to omniosce bloody. Between the two, zone shutdown > stopped working for me (both ipkg and lx), with the ce variant claiming > that "datalinks remain in zone after shutdown / unable to unconfigure > network interfaces in zone / unable to destroy zone". > ; > ; When the zone boots it seems okay and usable, but when trying to halt > it - becomes "down" and I can not change the state (no > boot/mount/ready/... options succeed); killing its zoneadmd and wiping > then/var/run/zones also does not help - only GZ reboot. > > Thanks Jim, confirmed here too. > We are building a new bloody at the moment so will test with that and > then > work on a fix. I've opened an issue for this at > > https://github.com/omniosorg/illumos-omnios/issues/18 > > 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] Riak on OmniOS
henr...@henkis.net writes: > Hi, > > Not related directly to OmniOS but to software supported. > > Anyone running Riak on OmniOS? Seems lika a good match since basho have > recommended ZFS and there are Dtrace probes available. But when talking to > basho they say the no longer support OmniOS/illumos/Solaris. Anyone else > heard this, should I be worried and be forced to run on Linux with ZoL or god > forbid LVM? > Former Basho employee and Riak contributor here. Riak and OmniOS should get along fine; it's just not a first class platform for Basho anymore. Anyone who had an interest in illumos-based operating systems left the company. They don't have the people to properly field support calls for it. If you run into issues I'm happy to provide consulting services. OmniTI should also have the knowledge to do the same. -Z ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Panic, BAD TRAP, r151014, VMWare Fusion 8.1.0
While running a nightly build of illumos-gate the kernel panicked with "BAD TRAP". Running OmniOS r151014 on VMWare Fusion. This is not urgent. I am posting in case I have stumbled onto a bug. VMWare Fusion Version 8.1.0 (3272237) # cat /etc/release OmniOS v11 r151014 Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. # uname -v omnios-d08e0e5 You can find the full crash dump here: http://zinascii.com/pub/illumos/cores/bad-trap-12-29-15/ crash dump info --- > ::status debugging crash dump /var/crash/unknown/vmcore.0 (64-bit) from omnislash operating system: 5.11 omnios-d08e0e5 (i86pc) image uuid: a43f56bd-f5a4-6643-92e6-84262b07c26a panic message: BAD TRAP: type=e (#pf Page fault) rp=ff001010c010 addr=fb8484b0 dump content: kernel pages only > ::panicinfo cpu2 thread ff02e40fb160 message BAD TRAP: type=e (#pf Page fault) rp=ff001010c010 addr=fb8484b0 rdi ff001010c110 rsi fb8484b0 rdx2 rcx0 r8 fbc723a0 r9 78 rax fbc72420 rbx fee19000 rbp ff001010c110 r10 fbcf8cb0 r11 ff02e40fb160 r120 r130 r14 ff02fb5e1c00 r15 fb8484b0 fsbase0 gsbase ff02dbcb4080 ds 4b es 4b fs0 gs 1c3 trapnoe err 10 rip fb8484b0 cs 30 rflags10202 rsp ff001010c108 ss0 gdt_hi0 gdt_lo b1ef idt_hi0 idt_lo afff ldt0 task 70 cr0 8005003b cr2 ff02d90f0ff8 cr3234af6000 cr4406b8 > ::msgbuf MESSAGE pcieb16 is /pci@0,0/pci15ad,7a0@17 PCI Express-device: pci15ad,7a0@17,1, pcieb17 pcieb17 is /pci@0,0/pci15ad,7a0@17,1 PCI Express-device: pci15ad,7a0@17,2, pcieb18 pcieb18 is /pci@0,0/pci15ad,7a0@17,2 PCI Express-device: pci15ad,7a0@17,3, pcieb19 pcieb19 is /pci@0,0/pci15ad,7a0@17,3 PCI Express-device: pci15ad,7a0@17,4, pcieb20 pcieb20 is /pci@0,0/pci15ad,7a0@17,4 PCI Express-device: pci15ad,7a0@17,5, pcieb21 pcieb21 is /pci@0,0/pci15ad,7a0@17,5 PCI Express-device: pci15ad,7a0@17,6, pcieb22 pcieb22 is /pci@0,0/pci15ad,7a0@17,6 PCI Express-device: pci15ad,7a0@17,7, pcieb23 pcieb23 is /pci@0,0/pci15ad,7a0@17,7 PCI Express-device: pci15ad,7a0@18, pcieb24 pcieb24 is /pci@0,0/pci15ad,7a0@18 PCI Express-device: pci15ad,7a0@18,1, pcieb25 pcieb25 is /pci@0,0/pci15ad,7a0@18,1 PCI Express-device: pci15ad,7a0@18,2, pcieb26 pcieb26 is /pci@0,0/pci15ad,7a0@18,2 PCI Express-device: pci15ad,7a0@18,3, pcieb27 pcieb27 is /pci@0,0/pci15ad,7a0@18,3 PCI Express-device: pci15ad,7a0@18,4, pcieb28 pcieb28 is /pci@0,0/pci15ad,7a0@18,4 PCI Express-device: pci15ad,7a0@18,5, pcieb29 pcieb29 is /pci@0,0/pci15ad,7a0@18,5 PCI Express-device: pci15ad,7a0@18,6, pcieb30 pcieb30 is /pci@0,0/pci15ad,7a0@18,6 PCI Express-device: pci15ad,7a0@18,7, pcieb31 pcieb31 is /pci@0,0/pci15ad,7a0@18,7 pseudo-device: stmf_sbd0 stmf_sbd0 is /pseudo/stmf_sbd@0 PCI Express-device: pci15ad,790@11, pci_pci1 pci_pci1 is /pci@0,0/pci15ad,790@11 NOTICE: e1000g0 registered NOTICE: e1000g0 link up, 1000 Mbps, full duplex pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 pseudo-device: zfs0 zfs0 is /pseudo/zfs@0 WARNING: drmach_init: number of logical CPUs (3) in physical processor is not power of 2. This Solaris instance has UUID a43f56bd-f5a4-6643-92e6-84262b07c26a dump on /dev/zvol/dsk/rpool/dump size 4096 MB pseudo-device: pm0 pm0 is /pseudo/pm@0 pseudo-device: power0 power0 is /pseudo/power@0 pseudo-device: srn0 srn0 is /pseudo/srn@0 iscsi0 at root iscsi0 is /iscsi ISA-device: fdc0 fd0 at fdc0 fd0 is /pci@0,0/isa@7/fdc@1,3f0/fd@0,0 audioens#0: AC'97 codec id Cirrus Logic 0x43525913 (43525913, 2 channels, caps 0) PCI-device: pci1274,1371@1, audioens0 audioens0 is /pci@0,0/pci15ad,790@11/pci1274,1371@1 ATAPI device at targ 0, lun 0 lastlun 0x0 model VMware Virtual IDE CDROM Drive ATA/ATAPI-4 supported, majver 0x1e minver 0x17 PCI Express-device: ide@1, ata1 ata1 is /pci@0,0/pci-ide@7,1/ide@1 UltraDMA mode 2 selected sd1 at ata1: target 0 lun 0 sd1 is /pci@0,0/pci-ide@7,1/ide@1/sd@0,0 device pciclass,03@f(display#0) keeps up device sd@0,0(sd#1), but the former is not power managed pseudo-device: pool0 pool0 is /pseudo/pool@0
Re: [OmniOS-discuss] ILB memory leak?
Al Slater writes:
> On 21/10/2015 17:35, Dan McDonald wrote:
>>
>> That should enable user-level memory debugging. If you get a
>> coredump, save it and share it. If you don't and the ilb daemon
>> keeps running, eventually please:
>>
>> gcore `pgrep ilbd`
>>
>> and share THAT corefile. You can also do this by youself:
>>
>> mdb > ::findleaks
>>
>> and share ::findleaks.
>>
>> Once you're done generating corefiles, repeat the steps above, but
>> use "unsetenv LD_PRELOAD" and "unsetenv UMEM_DEBUG" instead of the
>> setenv lines.
>
> Thanks Dan. As we are talking about production boxes here, I will have
> to try and reproduce on another box and then I will give the process
> above a go and see what we come up with.
You can also use the DTrace pid provider to grab the user stack on every
malloc(3C) call, and the syscall provider to track mmap(2) calls. That
poses no harm to production and might make the cause of memory usage
obvious.
Something like:
dtrace -qn 'pid$target::malloc:entry { @[ustack()] = count(); }
syscall::mmap*:entry /pid == $target/ { @[ustack()] = count(); }' -p
Let that run for a while as the memory grows, then Ctrl-C.
-Z
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] New metapackage --> illumos-tools
Dan McDonald writes: > IF you want to build illumos-omnos or illumos-gate on an OmniOS r151014 or > later installation, you can do so now simply by uttering: > > pkg install developer/illumos-tools > > illumos-tools is a metapackage that brings in all of the required packages > one needs to build illumos-gate or illumos-omnios. You can then just > download the closed-binaries, git clone your favorite illumos-gate child, > construct a .env file and get going. > > I wanted to have this be a feature of r151016, but it was easy enough where I > backported it. > > Sorry I didn't have something like this sooner. I've also updated the How to > Build illumos page on the illumos wiki. > > Happy installing! > Dan Thank you Dan! Changes like this may seem small but they make all the difference to a beginner. -Z ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Compiling GNUCOBOL : pre-requisites present?
On Oct 27, 2014, at 9:13 AM, Mayuresh Kathe mayur...@kathe.in wrote: GNU MP (libgmp) 4.1.2 or later GNU Libtool (libltdl) Berkeley DB (libdb) 1.85 or later Ncurses (ncurses) 5.2 or later Unix curses From what I can tell, there are packages for all of these on the base system except for BDB. For BDB it looks like you'll need to add the ms.omniti.com publisher. http://omnios.omniti.com/wiki.php/Packaging Keep in mind that the OmniOS folk encourage you to build your own application stack so that you can own it and tailor it to your specific needs. Because of this philosophy they keep the base system as thin as possible. http://omnios.omniti.com/wiki.php/KYSTY -Z ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] [developer] Initial review -- Changes that allow illumos-gate to (mostly) build on OmniOS
On Oct 23, 2014, at 9:56 PM, Dan McDonald via illumos-developer develo...@lists.illumos.org wrote: * You can still build with NO NOISE on OpenIndiana - i.e. it's a NOP to OI builders. I'd like both the illumos developer community and the OmniOS community to look, and share their reviews and opinions. If you have a distro that's not OI or OmniOS, see if these mods help things work on YOUR distro. If I can get more non-OI distros to build or mostly-build stock illumos-gate, it's better for everyone. I'm very excited to see changes that make the build easier across distributions, thank you Dan. I did not review any of the webrevs but I did test the build on my OI 151a8 node. It came out clean with no modifications to my environment. Attached is my mail_msg. -Z mail_msg.gz Description: GNU Zip compressed data ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
