Re: [OmniOS-discuss] the right card for a server
On Jan 9, 2014, at 3:23 PM, Entfernt mou...@landcroft.com wrote: This question covers OmniOS and the usual Supermicro hardware base. I want to add a four-port gigabit ethernet card to a 5017C-LF: http://www.supermicro.com/products/system/1u/5017/sys-5017c-lf.cfm So that's PCI Express x8. Most cards for the machine are two-port but this one: http://www.iphase.com/products/product.cfm/PCI%20Express/399 appears to fit the bill. In particular, it has the Broadcom® BCM5704C chipset which appears on the HCL: https://www.illumos.org/hcl/ This is a pretty good one to pick. It's supported by open-source 'bge'. but I'm a programmer rather than a sysadmin or hardware person. Can anyone see any obvious reason for the card not working ? Thanks in expectation. If you want something a bit more modern, you could try the Intel I350: http://www.newegg.com/Product/Product.aspx?Item=N82E16833106129 But the one you mentioned SHOULD work just fine. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] iscsi timeouts
On Jan 21, 2014, at 7:21 AM, Narayan Desai narayan.de...@gmail.com wrote: We've seen problems like this when we have a SATA drive in a SAS expander that is going out to lunch. Are there any drives showing errors in iostat -En? or any drive timeout messages in the ring buffer? Generally speaking -- you use a SATA drive in a SAS expander at your own risk. I used to be at Nexenta, and they would not support customers who deployed SATA drives on SAS expanders. These days, the price delta between SAS and SATA (for enterprise) is small enough to be worth it for the headaches you avoid. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
On Feb 18, 2014, at 9:41 PM, Marion Hakanson hakan...@ohsu.edu wrote: Derek Yarnell wrote: So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped as a Pliant-LB206S-D323-186.31GB via format. Richard Elling wrote: Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for lots of concurrent I/O operations. This is not the kind of workload generated by the ZIL, which is more contiguous, single thread-like. Derek Yarnell wrote: I realize that they may not be as good as Stec/HGST ZeusRAM drives for the slog. I still can't wrap my head around that it is as bad as having no discrete slog. Hi Derek, No better than with the ZIL running on the pool's HDD's? Really? Out of curiosity, what HBA is being used for these drives (and slog) in this R720xd, H710 or H310? Something else? I'm also looking at the R720xd here, though I was thinking of using the Intel DC S3700 SSD for a log device (in one of the internal flex-bay's), with the pool drives being of the 2.5 form-factor. The H710 sticks you with HW-RAID. Ick. The H310 allows you to use raw SAS disks, BUT I've encountered problems with BIOS failing INT13 reads on H310 raw disks, which makes booting difficult. (Also some Dell-issued disks require power entries in /kernel/drv/sd.conf.) Just be cautious when using the Dell HBAs. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] How do non-rpool ZFS filesystems get mounted?
On Mar 5, 2014, at 12:46 PM, Bryan Horstmann-Allen b...@mirrorshades.net wrote: +-- | On 2014-03-05 12:29:57, Dan Swartzendruber wrote: | | Any explanation as to what was happening? This is the bug I was hitting: http://smartos.org/bugview/OS-2616 Devices wouldn't be available at boot, but would once the system was up. I believe that bugfix is in illumos-gate now as: https://www.illumos.org/issues/4500 which was fixed by this changeset: https://github.com/illumos/illumos-gate/commit/da5ab83fc888325fc812733d8a54bc5eab65c65c and it *should* be in bloody now: https://github.com/omniti-labs/illumos-omnios/commit/da5ab83fc888325fc812733d8a54bc5eab65c65c Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem with using omnios-build
On Mar 25, 2014, at 12:27 PM, Carl Brunning ca...@flamewarestudios.com wrote: HI am playing with the omnios-build but when trying to do pkg build i find on the git clone it having a problem the line is this logcmd $GIT clone -b $PKG_BRANCH s...@src.omniti.com:~omnios/core/pkg the branch is r151006 I fixed some things in master to this. It should've just swapped out src@ for anon@. this is wanting a password but I don't know what it is i did see on the latest version of the build you have changed to this logcmd $GIT clone -b omni a...@src.omniti.com:~omnios/core/illumos-omni-os Hmmm. This is a very old artifact. The master version has this changeset: osdev2(build/pkg)[0]% git show --stat 85f25c28 commit 85f25c28969c859fb9bc838a6779dd3a70286896 Author: Theo Schlossnagle je...@omniti.com Date: Sat Mar 24 20:06:12 2012 + move pkg to git and make it work build/pkg/build.sh | 47 --- 1 file changed, 28 insertions(+), 19 deletions(-) osdev2(build/pkg)[0]% that eliminates the need for the clone to happen. Generally speaking, though, it's illumos-omnios: a...@src.omniti.com:~omnios/core/illumos-omnios Perhaps fixing that will work? so why it asking for a password for the first one lol That's a bug. I didn't fix it in anywhere other than master, though. and what is it and i hope you fix it all I'm curious if pkg can be re-rewhacked to use headers from a completed omnios build? I'm introducing new features into omnios-build to make it completely fire-and-forget. One new feature not yet back is the PREBUILT_OMNIOS feature, that can point packages that depend on a populated illumos-omnios proto area. Perhaps I should include PREBUILT_OMNIOS support in pkg as well?! Pardon any slowness on my part. I'm new at pkg, and at the build outside of illumos-omnios itself. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Networking Performance Tips on HP Microserver N40L ?
On Mar 26, 2014, at 11:47 AM, Svavar Örn Eysteinsson sva...@januar.is wrote: Hello people. I recently installed my first true NAS box at home, which is a HP Microserver N40L with 16GB in RAM, 1x250GB for OS and 4x 2TB Enterprise SATA disks provided by HP in a RAIDZ. I'm using the newest/updated OmniOS v11 r151008 and also Napp-it and other services. What I would like to know is, have there been any issues/problems and do people have some performance tuning tips regarding networking issues on the BC5723 controller provided by the HP Microserver ? It's the bge module/driver ? Sometimes I find the speeds to the BOX will rock up down. I haven't configured a gigabit network, thats on the plan this weekend. I have full-duplex and flowctrl enabled. For an example, I noticed after building my small ipf firewall rules and enabled the firewall the speed did go down, specially with CIFS and NFS(didn't test the AFP). Was performance okay pre-ipf? If so, it's probably ipf that's tripping you up. So, any performance tips out there ? I have to ask, are you using ipf to protect the box? Or for NAT? If just to protect the box, you may be able to use something NOT ipf to help you out, depending on the problem(s) you're trying to solve. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Networking Performance Tips on HP Microserver N40L ?
On Mar 26, 2014, at 1:12 PM, Svavar Örn Eysteinsson sva...@januar.is wrote: No, the performance was a little shaky before, and after the ipf activation. So I just disabled the firewall part. The reason I activated the firewall is not for NAT, just to protect the box. As I have configured my router to portmap some ports into the HP server, and I use ipf to deny/accept by source. As my stupid router firewall configuration never works. Okay. Just checking. I tend to use ipsecconf(1M) and drop actions for this sort of thing, but it's stateless, and it appears some of your FW rules are stateful. Yes, bge is the driver for what you have. I do know that bge needs some updating, but nobody's been contributing in the Illumos community on that front. Sorry I can't be of more immediate assistance, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem with using omnios-build
On Mar 27, 2014, at 12:56 PM, Carl Brunning ca...@flamewarestudios.com wrote: HI just to say I've fixed it so it all good now Good! Sorry I didn't respond earlier. A recent push into omnios-build has cause one of my works-in-progress some problems, so I've been debugging that. How did you fix your problem? Is it something we need to fix properly? Do you want to contribute if it is? Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kernel panic
On Apr 16, 2014, at 12:39 PM, Kevin Swab kevin.s...@colostate.edu wrote: SNIP! Traversing all blocks to verify checksums ... assertion failed for thread 0xfd7fff162a40, thread-id 1: c SPA_MAXBLOCKSIZE SPA_MINBLOCKSHIFT, file ../../../uts/common/fs/zfs/zio.c, line 226 Abort (core dumped) # # zpool import -F -f -o readonly=on -R /mnt data1 plankton console login: panic[cpu1]/thread=ff000ef07c40: BAD TRAP: type=e (#pf Page fault) rp=ff000ef07530 addr=278 occurred in module unix due to a NULL pointer dereference Interesting. We've seen one (just one) panic just like this in-house. In our case, some very strange corruption was written to disk, and ZFS couldn't cope. I have a request out to the ZFS community to improve the coping mechanisms. :) I've some dumb questions: 1.) Earlier in the thread, you mention these are SATA drives. When the panic occurred, were they attached via AHCI? Or to a controller of some sort? You mention you tried attaching these disks to an mpt_sas controller to try and recover them. Our machine was using plain SATA drives attached via AHCI. 2.) Is the kernel coredump available? If this is what we were seeing, I'd VERY much like to see what your corruption actually looks like. Knowing might help us root-cause the corruption in the first place. The corruption is of the blkptr_t, in particular its size, which ZFS now assumes is sane. zdb indicates this via an assertion failure, a non-debug kernel will just panic when it goes dereferencing a pointer in hyperspace. The coping mechanism involved would throw an IO error if an insane size is read off disk. The biggest question, of course, is how the corruption was introduced. THAT's why I want to see your coredump. If your corruption is close to ours - ours has a disk name of all things scribbled there - we share a common source of corruption. I really want to recover the data on this pool if at all possible. I can provide crash dumps if needed. Barring recovery, I would at least like to understand what went wrong so I can avoid doing it again in the future. If we can get a version of ZFS that can cope with corrupted blkptrs, that may help in recovery. I know *IN THIS PARTICULAR CODEPATH* how to cope, but I'm concerned it would expose other errors, and even read-only, I don't want to perform such experiments on a customer's data. :) It does seem, however, that our box is in the same state, so I will try it there. If I have success, I can share the modified zfs module. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kernel panic
Doesn't matter where the panic is from -- it's caused by a corrupt block on the disk. A vmdump.N would be nice. You're running 008, I see, so I can use an 008 box to examine the dump. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Hang on Dell R710 with r151004?
On Apr 28, 2014, at 1:21 PM, st...@linuxsuite.org wrote: Hi, I have 2 Dell R710's as a ZFS storage that are running r151004. About every 2 or 3 weeks they will hang with all services unresponsive and must be power cycled. I do not Hmm... read something about cstates on dell r710's You should disable C-states. Also, upgrading to r151006 or r151008 will get you mpt_sas improvements as well. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] move dump and swap to other pool
On May 8, 2014, at 4:30 AM, Johan Kragsterman johan.kragster...@capvert.se wrote: Hi! I got a relatively small(20 GB) SLC SSD as rpool, and I would like to move the dump and swap devices to another pool. ATM the pkg update process isn't possible, because I got too little space left on the rpool. Can someone give me some advices here, how I would do this in the best way? About dump: Unless you have r151008 or later, you can only use a zvol on a mirror or single-disk pool. Having said that: zfs create -V size newpool/dump dumpadm -d /dev/zvol/newpool/dump And for swap (which should be good regardless what newpool is...): zfs create -V size newpool/swap swap -a /dev/zvol/newpool/swap swap -d /dev/zvol/oldpool/swap Hope this helps, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] compiling mediatomb #error non-amd64 code depends on amd64 privileged header!
You are trying to build a 64-but object , right? Are you adding -m64 to the compiler flags? Dan Sent from my iPhone (typos, autocorrect, and all) On May 11, 2014, at 3:00 PM, Natxo Asenjo natxo.ase...@gmail.com wrote: hi, trying to use my home omnios server for streaming media I get this error when making mediatomb: g++ -DHAVE_CONFIG_H -I. -I.. -I../tombupnp/upnp/inc-I../src -I../tombupnp/ixml/inc -I../tombupnp/threadutil/inc -I../tombupnp/upnp/inc -I.. -I/usr/local/include-D_REENTRANT -pthreads -I/usr/include/amd64-g -O2 -MT libmediatomb_a-action_request.o -MD -MP -MF .deps/libmediatomb_a-action_request.Tpo -c -o libmediatomb_a-action_request.o `test -f '../src/action_request.cc' || echo './'`../src/action_request.cc In file included from /usr/include/sys/regset.h:420:0, from /usr/include/sys/ucontext.h:36, from /usr/include/sys/signal.h:245, from /usr/include/sys/procset.h:42, from /usr/include/sys/wait.h:43, from /usr/include/stdlib.h:40, from ../src/memory.h:35, from ../src/common.h:36, from ../src/action_request.h:36, from ../src/action_request.cc:36: /usr/include/amd64/sys/privregs.h:42:2: error: #error non-amd64 code depends on amd64 privileged header! #error non-amd64 code depends on amd64 privileged header! ^ make[2]: *** [libmediatomb_a-action_request.o] Error 1 make[2]: Leaving directory `/root/mediatomb-0.12.1/build' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/mediatomb-0.12.1' make: *** [all] Error 2 There are quite a few hits on google regarding this #error non-amd64 code depends on amd64 privileged header! on omnios, but so far I could not find a solution. I am building this on a zone with gcc-4.8.1. Any help greatly appreciated. -- Groeten, natxo ___ 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] Ang: fmdump help?
On May 12, 2014, at 11:06 AM, Johan Kragsterman johan.kragster...@capvert.se wrote: Thanks again, Dan! Some more questions further down... Does this mean it is the PCI-X bus? And/or a device on that bus? It makes sense if so, because the e1000g3 is on an Intel quad port PCI-X adapter on the only PCI-X bus on the system. And I had severe issues with a client connected to that port. But could a port issue really crash the system? Wouldn't it be more likely that it is the bus? The error message originates from the pcieb (PCI-E bus controller): 161 f8077000 4440 228 1 pcieb (PCIe bridge/switch driver) and yes it's likely the bus, as that message/panic happens after a bus scan. I indicated e1000g3 so you could maybe see if the slot it was in was bad. First step will be that I'll change the connections to that port to another port on the same nic, and see if it'll be some changes. If I still got problems, I'll change the nic to a similar, and if that doesn't help, I put another nic on a PCIe-bus instead. That's what I'd do. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: fmdump help?
I'm not sure if that code is common to PCI-X as well. After all, the printf message mentions PCI-X (but maybe as a typo)? And interrupts from PCI-X may still sabotage PCIe. I'd continue to focus on that NIC for starters (and save the dumps if you've the disk space). Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Comstar Disconnects under high load.
On May 12, 2014, at 6:13 PM, David Bomba turbo...@gmail.com wrote: Hi guys, We have ~ 10 OmniOS powered ZFS storage arrays used to drive Virtual Machines under XenServer + VMWare using Infiniband interconnect. Our usual recipe is to use either LSI HBA or Areca Cards in pass through mode using internal drives SAS drives.. This has worked flawlessly with Omnios 6/8. Recently we deployed a slightly different configuration HP DL380 G6 64GB ram X5650 proc LSI 9208-e card HP MDS 600 / SSA 70 external enclosure 30 TOSHIBA-MK2001TRKB-1001-1.82TB SAS2 drives in mirrored configuration. 1.) What was your previous configuration? And running 006 or 008? 2.) What is running on your new HW? 006 or 008? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Comstar Disconnects under high load.
On May 12, 2014, at 6:34 PM, David Bomba turbo...@gmail.com wrote: Previous configurations were HP DL180 G6 96GB RAM Areca 1882-ix using passthrough 25x600Gb Toshiba MBF2600RC SAS 10k drives in mirrored config L5640 Proc We have 4 of these using a mixture of 006 and 008 New hardware runs 008. Hmmm, and the same kind of load works on your older boxes?!? One other thing -- 010 is out now. You may wish to upgrade your newest HW to our newest stable release. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] The OmniOS bloody repo - now updated!
I've uploaded new bits (r151011) to the bloody repo, and I've made available ISO and USB images. I've installed with the ISO successfully on a VM. You can visit the Get OmniOS page: http://omnios.omniti.com/wiki.php/Installation and see the links. Remember the difference between bloody and stable: http://omnios.omniti.com/wiki.php/StableVsBloody If you've still a bloody machine somewhere, know now that the http://pkg.omniti.com/omnios/bloody/ URI now serves r151011 packages. This is the first time bloody has been active in a while, from what I can tell (it wasn't active when I started here). If you like bleeding edge (and officially unsupported) bits, this is your place. I may be upgrading all packages wholesale (which may make upgrading take longer), but I may only do them as they change. I don't think I'll spin release media nearly as often as I will update the IPS server either, but again, this IS bloody, so that's the chance you and I take. :) There's not a WHOLE lot of difference between r151010 and bloody right now (just a few commits on illumos-omnios mostly), but that'll evolve over time. Thank you folks, and please engage here with your feedback on the bloody repo. Dan McDonald -- OmniTI illumos engineer ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS Panic on high ZFS Write Load
On May 15, 2014, at 10:41 AM, Dan McDonald dan...@omniti.com wrote: What OmniOS version are you running? Also, how much memory do you have on this system, and have you done any crazy tunings to increase kernel memory usage? Sorry, you said you tried this on many versions. If you can, stick with r151010 (our latest stable) and get a system dump from this box. It's possible too, as Narayan points out, checking for HW errors is helpful. Also, I may ask you to reproduce this bug with kernel memory debugging enabled. If something is using freed memory, that'd be nice to know. And finally, are you using 3rd-party binary drivers? Or the native ones in your distro? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Kernel Panic - ZFS on iSCSI target and transferring data.
On May 21, 2014, at 5:53 AM, Svavar Örn Eysteinsson sva...@januar.is wrote: SNIP! panicstr = BAD TRAP: type=8 (#df Double fault) rp=ff04e3069f10 addr=0 panicstack = unix:real_mode_stop_cpu_stage2_end+9de3 () | unix:trap+ca5 () | unix:_patch_xrstorq_rbx+196 () | zfs:zio_vdev_delegated_io+86 () | zfs:vdev_queue_aggregate+298 () | zfs:vdev_queue_io_to_issue+5e () | zfs:vdev_queue_io_done+88 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | zfs:zio_execute+88 () | zfs:vdev_queue_io_done+78 () | zfs:zio_vdev_io_done+80 () | Oh how cute, the kernel somehow managed to infinitely recurse, causing a stack overflow! The only feature that I have enabled on this zPool and or ZFS dataset is a Lz4 compression on the zfs dataset. Hmmm, lz4 compression and stack overflow? I see one illumos bug related to that: https://www.illumos.org/issues/3705 But that bug's fix has been in OmniOS since r151006. You're not running something older, are you? There ARE new ZFS fixes in r151010, and if you can, I'd highly recommend the upgrade. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] DHCP server of choice for OmniOS?
On May 23, 2014, at 3:23 AM, Steffen Kram s...@kram.io wrote: Hi Dan, I’m using ISC DHCP. It’s not a big deal to build it for Omnios. You can as well use my version or my build scripts from http://scott.mathematik.uni-ulm.de. I ended up downloading, compiling, and smoke-testing the latest ISC DHCP without any build scripts (sorry Steffen). Oddly enough, thanks to some work from Oracle for S11, ISC DHCP is far more suitable for Illumos and OmniOS than even I'd imagined in the first place. It seemed to work okay for my simple smoke test, and if I don't so something more substantial in the next week, I'll give it a more thorough smoke test when we have company over to my house soon. Would people be interested in seeing OmniOS ship with ISC DHCP? Would people wish to be rid of the old Sun DHCP server? (Or are there Sun Ray owners out there who use OmniOS to serve them? IIRC, Sun Rays need the old Sun DHCP server.) Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Status of TRIM support?
On May 27, 2014, at 9:11 PM, Dan Swartzendruber dswa...@druber.com wrote: SNIP! Does over-provisioning help? It might. I'm no ZFS performance expert. You're better off asking that question on the Illumos ZFS list. I've mentioned before here that Nexenta had a prototype of TRIM/UNMAP use by ZFS, but I do not know what its status is. Again, that's a better question for the Illumos ZFS list than here. I'm sorry I can't be of more immediate assistance, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Intel X540-AT2 WARNING: ixgbe01 : Failed to initialize adapter
On May 28, 2014, at 8:06 PM, Andrew Brant andr...@icc-usa.com wrote:
Trying to sort this out on a new build running the latest OmniOS release, the
adapter is on the Illumos HCL and works like a charm when the system is
booted into the live CentOS environment.
Tried the X540 based Supermicro add-on card for comparison and that
initialized just fine.
Any suggestions?
The error message you have corresponds to this code:
/*
* Initialize driver parameters
*/
if (ixgbe_init_driver_settings(ixgbe) != IXGBE_SUCCESS) {
ixgbe_error(ixgbe, Failed to initialize driver settings);
goto attach_fail;
}
If you can, could you please run the attached dtrace script as follows:
./downstack.d ixgbe_init_driver_settings
and then run ifconfig ixgbe0 plumb (assuming ixgbe0 is one of the bad ones)
to narrow it down to where it fails? The output may be quite large.
One thing else:
# cat /etc/*release
OmniOS v11 r151011
This is the bloody release, not the latest supported one, FYI.
Regardless, the X540 board you mention SHOULD work.
May 28 12:00:06 omnios ixgbe: [ID 611667 kern.warning] WARNING: ixgbe0:
Failed to initialize adapter
May 28 12:00:14 omnios ixgbe: [ID 611667 kern.warning] WARNING: ixgbe1:
Failed to initialize adapter
Is there any other ixgbe output around here? Uttering dmesg | grep ixgbe and
seeing if there's anything else complain-y would be nice.
It'll be even larger than the DTrace output, but can you put the output of
prtconf -v from your system somewhere, even in a mail here as an attachment?
Thanks,
Dan
downstack.d
Description: Binary data
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Intel X540-AT2 WARNING: ixgbe01 : Failed to initialize adapter
H. My fault. Wrong code.
Failed to initialize adapter
That's what you said.
THIS code:
/*
* Initialize chipset hardware
*/
if (ixgbe_init(ixgbe) != IXGBE_SUCCESS) {
ixgbe_error(ixgbe, Failed to initialize adapter);
goto attach_fail;
}
And do use the DTrace script I sent, but use ixgbe_init instead of
ixgbe_init_driver_settings as the argument.
Sorry about that,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Status of TRIM support?
On May 29, 2014, at 11:25 AM, Doug Hughes d...@will.to wrote: The higher price is the reason I tend to prefer the 320 series that come in around $1/GB and have smaller sizes available. I use them for OS + slog. What about the S3500? I've heard that's more the drop-in replacement for the 320 series. (ObDisclosure: I use a pair as part-rpool/part-mirrored-slog for my home server. Blog post about HDC2.0 coming RSN.) Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Status of TRIM support?
On May 29, 2014, at 11:58 AM, Saso Kiselkov skiselkov...@gmail.com wrote: On 5/29/14, 5:48 PM, Dan McDonald wrote: On May 29, 2014, at 11:25 AM, Doug Hughes d...@will.to wrote: The higher price is the reason I tend to prefer the 320 series that come in around $1/GB and have smaller sizes available. I use them for OS + slog. What about the S3500? I've heard that's more the drop-in replacement for the 320 series. (ObDisclosure: I use a pair as part-rpool/part-mirrored-slog for my home server. Blog post about HDC2.0 coming RSN.) The DC S3500 is reported to have only about 1/3 - 1/2 the performance of the DC S3700, see: http://www.anandtech.com/show/7065/intel-ssd-dc-s3500-review-480gb-part-1/3 May be more than enough for SOHO, though. Likely yes, but it was a helluva lot cheaper, and seems to be a helluva lot more reliable that the two POS drives it replaced. :) Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] IBM micron ssd
On May 31, 2014, at 6:03 AM, Johan Kragsterman johan.kragster...@capvert.se wrote: Hi! I've seen some Micron 1.8-inch 64 GB SSD's around, that is supposed to be enterprise class. They're called Micron RealSSD P400e, and come in different sizes. IBM sells them with IBM brand for their servers. If it's the one reviewed here: http://www.tomshardware.com/reviews/p400e-review-endurance,3199.html It looks like any other SATA SSD. You just plug it in like any other SATA drive and it works. They apparently use the Marvell 9174 SATA 6Gb/s controller and 25 nm MLC NAND, and is, according to Micron, equipped with firmware designed for read-heavy enterprise workloads, including 28% over-provisioning and data protection via memory path error correction. So I wonder if anyone on this list has any knowledge about these drives, and if the controller is compatible with omnios? As for the internal controller (since it's acting as a disk drive, not acting as a PCIe card), you'll have to ask how good it is. Since it's a drive, it should just work with OmniOS (or any other illumos variant for that matter). If it DOESN'T, that'd be interesting to know. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Users of bloody - please update ASAP
This fix in illumos: commit adf340778b67ab4c04c186099a69e0a5435609c7 Author: Jerry Jelinek jerry.jeli...@joyent.com Date: Fri May 30 19:19:45 2014 + 4901 zfs filesystem/snapshot limit leaks Reviewed by: Matthew Ahrens mahr...@delphix.com Approved by: Dan McDonald dan...@omniti.com Is now in illumos-omnios, AND in the bloody repo server. Please run pkg update at your earliest convenience for continuing reliable ZFS service. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] usb hid ups monitoring
On Jun 2, 2014, at 9:18 PM, Paul B. Henson hen...@acm.org wrote: From: Denis Cheong Sent: Monday, June 02, 2014 2:40 AM these days very few motherboards come with RS232 onboard That is true of desktop hardware, but I think almost all server grade motherboards have at least one if not two classic serial ports available. My new Socket 1150 mobo has a serial port. (See http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html for details.) Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Any bloody users in the audience? ISC DHCP
I'm close (1-2 weeks) to pushing ISC DHCP into the bloody OmniOS repo. I'm concerned, having little operational experience with this daemon beyond simple home-network configurations, that I'm not getting some of the SMF interfaces right. The package will deliver four SMF services: network/service/dhcp:ipv4 network/service/dhcp:ipv6 network/service/dhcrelay:ipv4 network/service/dhcrelay:ipv6 The dhcrelay services will have required service properties that need filling in. It's POSSIBLE I'm missing some things. I would appreciate if there are bloody users in the audience who want to start serving ISC DHCP letting me know. I'd like some real operational experience on this before ISC DHCP lands in the next stable release. Thanks, Dan McD. -- OmniOS engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] PLEASE UPDATE YOUR OPENSSL!
Hello folks! Per here: https://www.openssl.org/news/secadv_20140605.txt we've updated openssl on LTS (006), Stable (010), the previous stable (008), and bloody (011) to the latest version (1.0.1h). Please pkg update as quickly as you can. Thanks, Dan McD. -- OmniOS engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] New update for bloody
I've pushed out eight updates and one new package to the bloody repo for OmniOS. The new package is network/service/isc-dhcp. It is a work in progress. It provides these SMF services: network/service/dhcp:ipv4 network/service/dhcp:ipv6 network/service/dhcrelay:ipv4 network/service/dhcrelay:ipv6 This is the bloody distro, so these are very rough, and in some cases untested. I expect to deliver more configuration properties for all of these prior to the next stable release. I would appreciate some feedback here. Speaking of feedback, I know NOBODY tried mozilla-NSS (or at least asked my why it wasn't actually updated), because I botched something about it in the last update -- namely missing an update to the incorporation/jeos/omnios-userland. Highlights of this update to bloody include: Userland - ISC DHCP (need feedback) - REAL update to NSS and NSPR (also need feedback) - Git is now at version 2.0 (I'll be using this myself, but more feedback is nice) And from illumos and illumos-omnios - zdb can now dump all metadata - pkcs11 now behaves better post-fork (this often tripped up Jenkins) - Embedded-data block pointers (zero block compression) - Fix for the tricky Illumos 4390, which fixes I/O errors during dataset deletion from corrupting the space map. Happy updating! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Onboard Intel X540-T2 10gbe NIC shows 1gbit
On Jun 9, 2014, at 7:14 PM, Rune Tipsmark r...@steait.net wrote: As stated above, Got a Super Micro X9DRE-TF+ with onboard Intel X540 10Gbase-T with a cat6 cable straight into another server (with Windows) using a PCI-E Intel X540-T2 10Gbase-T as well. Both ends are set to autosense, however only 1gbit is detected on OmniOS, I can force 10Gbit on Windows, but it won’t come up because the other end supports max 1Gbit. I tried changing link speed manually in OmniOS, no luck, says not supported. Why does it not detect proper 10Gbit on the OmniOS end of things? Any suggestions as how to get this working? Version is 151010 , tried reinstall already – no difference. 10Gig on here should work. I've not had hands-on experience with built-in ones, but I've used add-on cards with X540 to great success. Did you inspect /var/adm/messages for any complaints from ixgbe? You're using cat6, which is good. One silly question -- on the BIOS on the OmniOS box, did you enable PCIe mappings for only the low 32-bits? That's a longshot, I know, but it may be an issue. ALSO, we recently had someone else on-list post about X540, and it turned out they needed a firmware upgrade to get it to work. Please make sure your BIOS and device firmware are up to date. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Win 8.1 NFS client
On Jun 13, 2014, at 7:54 AM, Schweiss, Chip c...@innovates.com wrote: You may have revealed the cause of a problem I've seen a few times, but have not made the correlation. In my case we have 100+ CentOS NFS clients and a periodic use of 2012R2 server connecting via NFS. I have had a few drop offs of the NFS server with out a single line in the event logs, just complete non-responsiveness. I will definitely be digging deeper into this. This is most likely Illumos wide, not just OmniOS. I will report back to both lists if I can get anything reproducible. A possible cause for the problem is the new open-sourced NFS lock daemon. (It may have some residual bugs.) I have MacOS 10.6 and 10.9, and I'm seeing occasional problems as well. If you get it going offline, please utter: svcs -xv on the OmniOS/Illumos box and see if anything reports as being faulty. I've seen the NFS lock manager flake out. By itself svcs -xv will not show any output if things are working. The SMF service in question (here shown working properly) is: hdc(~)[0]% svcs -xv nlockmgr svc:/network/nfs/nlockmgr:default (NFS lock manager) State: online since June 9, 2014 08:33:04 PM EDT See: man -M /usr/share/man -s 1M lockd See: /var/svc/log/network-nfs-nlockmgr:default.log Impact: None. hdc(~)[0]% Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Win 8.1 NFS client
On Jun 16, 2014, at 4:30 AM, Valrhona valrh...@gmail.com wrote: And per the Illumos.org documentation, the fix is pretty simple: svcadm clear nlockmgr That'll get nlockmgr trying to restart again. Any insights as to why this is happening, and what can be done to prevent it? This is more a question for the illumos list than for here. In Win 8.1 Enterprise, I am using: mount -o fileaccess=777 192.168.1.123:/mydata g: In Linux: mount -t nfs4 192.168.1.123:/mydata /mnt/mydata/ In OpenIndiana: mount -F nfs 192.168.1.123:/mydata /mnt/mydata/ Is there anything else I should be doing? Again, these commands have worked for years; only after introducing Win 8.1 has the NFS dropping out been a problem. Thanks! My first suspicion is NFS4. I didn't notice much of this myself until I upgraded one of my household macs to 10.9. I use autofs with all of my household Macs, but I didn't see weirdness until I brought one of them up from 10.6 to 10.9. I wonder if there's some NFS4.1 path, perhaps, that's triggering an untested Not supported case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Win 8.1 NFS client
One other thing. IF you can easily reproduce this (I can't), capturing raw packets starting before the reproduction would be immensely useful. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] trouble building DBD::mysql (perl)
On Jun 16, 2014, at 2:10 PM, John D Groenveld jdg...@elvis.arl.psu.edu wrote: In message CAHBEJzXYkr3cv5oFNLy=yefmcixdu2d6zwxm7-+4knhqjbq...@mail.gmail.com , Natxo Asenjo writes: yes, I thought that at first, but I need that because otherwise I get this: ld: fatal: file dbdimp.o: wrong ELF class: ELFCLASS64 ld: fatal: file processing errors. No output written to blib/arch/auto/DBD/mysql/mysql.so because: # /usr/local/mysql/5.6/bin/mysql_config --cflags -I/usr/local/mysql/5.6/include -m64 -fPIC -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing Rebuild your custom Perl with -m64 or install a set of 32-bit MySQL libraries to which you can link your 32-bit DBD::mysql. The resultant perl will be built for i86pc-solaris-thread-multi-64. We do both for the 5.16.1 we ship with stock OmniOS, BTW. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] i217 driver
On Jun 18, 2014, at 2:04 PM, Brogyányi József bro...@gmail.com wrote: Hi I'm new here but I'm not green entirely because I use OI. Unfortunately OI not contains the new igb driver. Really? Maybe oi_151a9 doesn't have it, but I thought hipster did. Oh well, you're here now! (And I remember testing the I217 back at Nexenta. That will work if you're up to date with it.) I found description on the web and it's not work for me. The OmniTI knows the i217. My problem is on your site has 4 different iso. Which one is fit for me? Four? I thought we only had three: Long-Term Support (r151006), Stable (r151010), and Bloody (r151011). Oh, and BTW, it's not igb for the I217, it's e1000g: r151011(~)[1]% grep 8086,153a /etc/driver_aliases e1000g pci8086,153a e1000g pciex8086,153a r151011(~)[0]% I read about this os often has a update. How to know when issued the new update and how to do it? These two command are enough? pkg refresh --full pkg image-update Those two are enough for a given release. To jump releases (for example, once r151012 becomes Stable, and Bloody goes to r151013) you may have to do a bit more with pkg set-publisher, but that won't happen for a few more months. I'd recommend Stable for the new user like yourself. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] i217 driver
On Jun 18, 2014, at 2:40 PM, Brogyányi József bro...@gmail.com wrote: Dan Thank you for your quick respond. You're right I found as a e1000g. Unfortunately the kernel not recognize it or I have to set manually. When I issued the ifconfig command then I didn't see any e1000g0 line or igb0. What is the next step? You have to plumb the interface. First step is to see what datalinks you have available: dladm show-link You *should* see an e1000g0. If that's the case, you'll need to configure it. Old-school is with ifconfig(1M) and /etc/hostname.e1000g0 files. New-school is with ipadm(1M). Before we go down either of those paths, see if dladm shows you anything. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Help setting up a boot server
On Jun 24, 2014, at 5:41 AM, Natxo Asenjo natxo.ase...@gmail.com wrote: SNIP! all the pieces are there I think. Recently the isc-dhcp server got into the packages if I remember correctly and there is a tftp package as well.. ISC DHCP is only in the bloody repo for now. It still needs some work, but it does perform basic IPv4 DHCP services (i.e. anything you can configure in the file for IPv4). If you wish to test it, your best bet is to start using the bloody repo. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] HP Microserver G8
On Jun 24, 2014, at 9:51 AM, Nicolas Di Gregorio nicolas.digrego...@gmail.com wrote: I think everything is there : http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04128132 My main concerns are about: - : the network card based on BCM5720 There's your first problem right there. :( Broadcom support has always been a bit iffy. There IS a version of bge that supports the 5720, but under testing load it has sometime been flaky. - : the ability to uses the drives connected to the b120i controller in ahci mode AHCI shouldn't be a problem. - : using the microsd port connected on the ilo to install omnios If it's a USB MASS STORAGE device, you're okay. The big bottleneck here, alas, is the 5720. If you like rolling your own drivers, you can take a gander here from my old job: http://ma.nexenta.com/~danmcd/webrevs/git-jbge/ I *think* these changes may already be in SmartOS's illumos already. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] HP Microserver G8
On Jun 24, 2014, at 10:32 AM, Nicolas Di Gregorio nicolas.digrego...@gmail.com wrote: I don't plan to run a datacenter on that box, just as a home nas, so it would not be on intensive load. True... is this usable: http://www.broadcom.com/support/ethernet_nic/netxtreme_server.php? Maybe the Solaris 10 version, but I can't recommend you use these due to potential incompatibility with illumos. What's the difference with yours? What's does mean using my own drivers? problems at every kernel update? It would mean that, yes. sorry if thoses questions seems odd but I'm not an expert with solaris-like systems They don't seem odd at all. The 5720 support from the nexenta webrev is *probably* stable enough where it could go back into illumos-gate, if not OmniOS's child. I'm sorry I can't be of more immediate assistance. The earliest I could get 5720 support into ANY OmniOS would be in the bloody repo, and unless I have paying customers beating down the door, it would be a low priority project. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] HP Microserver G8
On Jun 25, 2014, at 7:12 AM, Nicolas Di Gregorio nicolas.digrego...@gmail.com wrote: I did an installation of the stable OmniOS. The network card was working with the stock driver :) I did not made any futher tests but I was able to ping outside. Well I'll be damned... I just had a look, and well before I got here, someone put the 5720 support into illumos-omnios. I guess this means at least for OmniOS you're good. (I should really get that bit upstreamed, however.) Thanks! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] ISC DHCP for OmniOS - how compatible?
Anyone here who uses bloody repos has noticed that I put in an initial package for the ISC DHCP server and DHCP relay. It's sketchy right now, there are SMF services, but with very few SMF service properties (which would correspond to command-line options). Currently both Oracle Solaris and OpenIndiana have ISC DHCP with a set of SMF service properties. Would it be safe for me to assume that people here would like to see the OmniOS version's SMF options match those in OI and Oracle Solaris? Or do people here really not care what we do? Please respond, I'd like to get a feel from the community. Thanks, Dan McD. - OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ISC DHCP for OmniOS - how compatible?
On Jun 25, 2014, at 4:41 PM, Theo Schlossnagle je...@omniti.com wrote: If the OI manifest options seem reasonable, compatibility with those seem only positive. OI manifest == Oracle Solaris manifest. I'd have chosen differently in some cases, but what do I know. Also, I do have issues with their defaults. I'm thinking I'll go with the names (for compatibility), but I may change the defaults (for least-surprise w.r.t. people migrating from their own ISC DHCP deployments). Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ISC DHCP for OmniOS - how compatible?
Thanks everyone for the feedback so far. I plan on having at least an updated dhcp:ipv[46] service with svcprops like the ones in OI/Oracle-Solaris arrive in this week's update to bloody. I'm not QUITE sure if I'll have dhcrelay:ipv[46] ready, but I'm going to try. When I next update the bloody repo and announce it here, you'll know. Those of you who gave me feedback, PLEASE TRY THIS so I can get *in-use* feedback. I'm using dhcp:ipv4 here at home, but it's a simple deployment. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] June 26th update to the bloody repo
Back on the Wed/Thurs every two weeks schedule now again. :) The bloody repo has been updated. Updates have happened to these packages: pkg://omnios/system/library@0.5.11,5.11-0.151011:20140626T141241Z pkg://omnios/SUNWcs@0.5.11,5.11-0.151011:20140626T141112Z pkg://omnios/system/kernel@0.5.11,5.11-0.151011:20140626T141235Z pkg://omnios/avs@0.1,5.11-0.133:20140626T141134Z pkg://omnios/system/extended-system-utilities@0.5.11,5.11-0.151011:20140626T141228Z pkg://omnios/service/file-system/nfs@0.5.11,5.11-0.151011:20140626T141217Z pkg://omnios/system/library@0.5.11,5.11-0.151011:20140626T141241Z pkg://omnios/system/header@0.5.11,5.11-0.151011:20140626T141232Z pkg://omnios/network/service/isc-dhcp@4.3.0,5.11-0.151011:20140626T160821Z Highlights include: - ISC DHCP support now contains compatible-with-OI-and-Oracle-Solaris SMF service properties. IF you are using ISC DHCP with OmniOS already, consider updating to bloody and using the version we plan on shipping. - A few NFS and ZFS bug fixes. - EOF of several old DDI functions. This is a relatively small change, modulo the ISC DHCP improvements. Thanks, and please provide feedback here on this list if you're using bloody! Dan McD. - OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] HEADS UP: omnios-build Packages now build with pkgdepend
Thanks to lotheac's pull request (#40), starting now, if you build OmniOS packages from the master (aka. bloody) branch, pkgdepend will be run prior to package publication. Here's lotheac's commit: https://github.com/omniti-labs/omnios-build/commit/19e0c6b5ad3e819dc66359277a66105a6db81ba1 and here's my followup to correct hiccups in code I don't control: https://github.com/omniti-labs/omnios-build/commit/1ff18471aa18300bb912cfcc7bf7c419a12ae27e The changes in my followup are the equivalent of lint-suppression directives in illumos-omnios source. Generally, these are discouraged, unless the source (or compiled binaries) has third-party provenance, or other strange properties (like a unix binary in kayak). There's a good chance the next update to bloody will replace the whole wad of packages. This will mean a longer upgrade time, of course, but it will mean all of the packages were built with pkgdepend. Thanks, and FYI, Dan McD. -- OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Issue with LSI 3108 MegaRAID ROMB card
On Jul 17, 2014, at 11:07 AM, Youzhong Yang youzh...@gmail.com wrote: Hi All, We have problem using the LSI 3108 card, just wondering if anyone here has any success story using this card in production. SNIP! When mr_sas(7d) was updated for 2208, it included untested 3108 support. 3108 was untested because people didn't have 3108 cards at the time it went back. The messages you're seeing indicate the card's timing-out an IO operation, followed by a reset-the-card failure. Beyond that, I can't help you much right now. I have no such card available to me. For the record, are you stuck using this, or did you choose a 3108? I'd recommend choosing something else if it was your choice. If it's not, please tell me what platform stuck you with a 3108, as it may be a harbinger of future complaints. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Issue with LSI 3108 MegaRAID ROMB card
On Jul 17, 2014, at 11:59 AM, Youzhong Yang youzh...@gmail.com wrote: Thanks Dan. We ordered these Supermicro X9DRW-CF/CTF boxes which have ROMB LSI 3108 on the motherboard and got stuck. We will probably add 9211-8i HBA cards to the machines and get them move forward. Before I saw this, one of my OmniTI co-workers mentioned that model of mobo as one possibility. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Who's using bloody out there?
I'm spinning what will be this week's update to bloody right now. There's at least one bugfix in there that I'm kinda surprised nobody noticed or complained about. Can people who are using bloody quickly send a reply to the list on this thread? Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] OmniOS bloody repo has been updated
Hey everyone! Once again, I've updated the install media for this update as well as the IPS repo. It's a big one, and includes one new device I'd *REALLY* like folks to test upon. Broken down by category, what's new in this update? userspace - zsh to 5.0.5. - mandoc now in the man pages. headers - POSIX 2008 locale support devices - mpt_sas now supports 12G WOULD APPRECIATE TESTING zones - virtualized load average for zones - per-zone CPU kstats Files sharing - Several ZFS bugfixes and enhancements. - rpcbind bugfix - NLM bugfixes TCP/IP - tcp_strong_iss defaults to 2. - ipsec_policy_log_interval to 0. Happy updating! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] NOT YET (was Re: OmniOS bloody repo has been updated)
AH! Shoot, this update isn't ready yet. But everything mentioned below will be included. Sorry, Dan On Jul 23, 2014, at 10:22 AM, Dan McDonald dan...@omniti.com wrote: Hey everyone! Once again, I've updated the install media for this update as well as the IPS repo. It's a big one, and includes one new device I'd *REALLY* like folks to test upon. Broken down by category, what's new in this update? userspace - zsh to 5.0.5. - mandoc now in the man pages. headers - POSIX 2008 locale support devices - mpt_sas now supports 12G WOULD APPRECIATE TESTING zones - virtualized load average for zones - per-zone CPU kstats Files sharing - Several ZFS bugfixes and enhancements. - rpcbind bugfix - NLM bugfixes TCP/IP - tcp_strong_iss defaults to 2. - ipsec_policy_log_interval to 0. Happy updating! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] dd does not work as expected with count=0 option
I suspect this is an Illumos bug. I'm top posting this because it's my phone, and I think the Illumos developers mailing list should confirm my suspicions. Dan Sent from my iPhone (typos, autocorrect, and all) On Jul 29, 2014, at 8:21 AM, Janne Savikko jsavi...@niksula.hut.fi wrote: Hi, I've used dd to create sparse files, and I noticed that dd does not work as expected with count=0 option, but keeps writing indefinitely. This does not happen with dd of Ubuntu 12.04,14.04, Solaris 11 Express (snv_151a), OSX 10.10 beta or OpenBSD 5.5. OmniOS build that I've tested this problem: omnios-b281e50 i86pc This behavior happens also with old Solaris 10 (Generic_139555-08 sun4v). Manual pages state count=n, Copies only n input blocks. So according to documentation I expect it to copy only 0 blocks. Is this desired behavior (and should documentation be fixed) or a bug? Cheers, Janne ___ 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] Status of VAAI
Someone needs to take the time to port the Illumos-nexenta bits upstream. Nobody has yet stepped up to the plate. Are you volunteering? ;) Dan Sent from my iPhone (typos, autocorrect, and all) On Aug 5, 2014, at 1:44 AM, Floris van Essen ..:: House of Ancients Amstafs ::.. i...@houseofancients.nl wrote: Hi Guys, Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR Does anyone know if there’s any progress in that area ? https://www.mail-archive.com/omnios-discuss@lists.omniti.com/msg02095.html best regards, Floris ___ 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] Status of VAAI
Pardon the top post. Testers are ALWAYS appreciated for new things. I'll remember this. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) On Aug 5, 2014, at 12:27 PM, Floris van Essen ..:: House of Ancients Amstafs ::.. i...@houseofancients.nl wrote: Hi Dan, Sometimes i wish was a programmer J Infra dude here, with plenty of stuff to test thing, but a programmer I am not, however if you need testers…. Van: Dan McDonald [mailto:dan...@omniti.com] Verzonden: dinsdag 5 augustus 2014 18:48 Aan: Floris van Essen ..:: House of Ancients Amstafs ::.. CC: omnios-discuss@lists.omniti.com Onderwerp: Re: [OmniOS-discuss] Status of VAAI Someone needs to take the time to port the Illumos-nexenta bits upstream. Nobody has yet stepped up to the plate. Are you volunteering? ;) Dan Sent from my iPhone (typos, autocorrect, and all) On Aug 5, 2014, at 1:44 AM, Floris van Essen ..:: House of Ancients Amstafs ::.. i...@houseofancients.nl wrote: Hi Guys, Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR Does anyone know if there’s any progress in that area ? https://www.mail-archive.com/omnios-discuss@lists.omniti.com/msg02095.html best regards, Floris ___ 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] Status of VAAI
On Aug 5, 2014, at 8:38 PM, Schweiss, Chip c...@innovates.com wrote: I used to do a lot of Linux kernel work, but haven't jumped in on Illumos, mostly because the information to get started seems sparse and often outdated on the few wiki pages that exist. The wiki isn't bad. Also look at this old blog post for building small bits: http://kebesays.blogspot.com/2011/03/for-illumos-newbies-on-developing-small.html After our Surge conference this year, we're having an Illumos Day. Would an intro-to-new-developers talk be useful? One curiosity I have is could a hybrid distribution of OmniOS with a Nexenta kernel be built and be useable. Nexenta keeps everything out in the open on Github. How hard would it be to build that kernel and utilize it? You might as well spend the effort to upstream bits of illumos-nexenta that you find interesting. My next mail on this thread will discuss this. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] JOB POST - Illumos System Administrator Support Engineer
From the job posting: The role of Solaris/Illumos System Administrator is a highly technical role, and requires thorough understanding of all components of a modern web application stack, including front-end, networking, and systems level knowledge. You will be supporting our internal infrastructure and teams, as well as providing managed services support, open source product development, and data center infrastructure support for our customers. We're actively seeking someone. I've wired the mail headers to prevent list-followup traffic. Honor the reply-to field and your name will get to the right people. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] JOB POST - Illumos System Administrator Support Engineer
On Aug 6, 2014, at 12:58 PM, Dan McDonald dan...@omniti.com wrote: From the job posting: Forgot the URL, sorry: http://www.omniti.com/is/hiring/system-administrator Pardon the second post, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Anyone here run Wordpress on OmniOS?
I'm contemplating hosting some blogs on the the HDC. I'd like to use Wordpress. Anyone here have experience using Wordpress on OmniOS? If so, I'd LOVE to see your experiences shared here on this thread. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Please pkg update for OpenSSL 1.0.1i
OpenSSL issued an update last night to address some issues, documented here: https://www.openssl.org/news/secadv_20140806.txt The repo servers for Long-Term Support and Stable should be updated. If you're on Long Term Support (r151006) or the current active Stable (r151010) you'll also be getting a bugfix for a tricky inter-zone/intra-node socket problem (Illumos 5026) an OmniOS customer found. If you're still on r151008, you're only getting the OpenSSL fix, and you should update to r151010. The bloody release is NOT fixed yet, but as that's going out in the next 12-36 hours ANYWAY, those fixes will be landing soon enough. Thank you! Dan McD. -- OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Please pkg update for OpenSSL 1.0.1i
On Aug 7, 2014, at 3:41 PM, Paul B. Henson hen...@acm.org wrote: Cool. I see the release notes (http://omnios.omniti.com/wiki.php/ReleaseNotes/r151010) haven't been updated? It looks like there was also a perl update (runtime/perl/module/sun-solaris 0.5.11,5.11-0.151010:20140428T192845Z - 0.5.11,5.11-.151010:20140806T221302Z) and I was just curious what it included. 5026 doesn't impact my use case, so I updated just the perl and openssl packages to avoid an extraneous reboot :). Sorry about that. Fixed. (Someone else had been doing those.) The Perl update was done because (and I'm shocked we didn't discover this sooner), building all of illumos-omnios's r151010 branch ON r151010 would fail. It had to do with very strange Perl interactions. I chose to backport the perl updates from upstream (and tested in bloody) into r151010. I wanted to build the world because the sockfs fix was in system/kernel, which is a lot of stuff. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] August 7th OmniOS bloody repo update
This would've been done sooner, but with the supported repos needing OpenSSL updates, this one got pushed out a bit later. This one is a small amount of changes, relative to the last one. Obviously the OpenSSL update is here. The list of what's new is: - OpenSSL updated to 1.0.1i - Various man-page updates, including modern man-page tools - ZFS bugfixes and performance improvments: - Including improved UNMAP performance for large datasets - ztest now uses larger device sizes by default - intra-node/inter-zone packets now deliver SIGPOLL to the receiver. - Localhost connections choke less in TCP's TIME_WAIT state. NOTE: This update does not change the uname -v string (omnios-8e364a8), but its default /etc/motd contains omnios-faf4446, which reflects the git commit in illumos-omnios that built this update. This was because there were no updates in system/kernel/platform, which contains unix, and the uname -v string. Happy updating! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] FTP server leaving illumos. Replacement suggestions?
If you follow Illumos bug 5069 (https://illumos.org/issues/5069), you'll see that the FTP server (based on wuftpd) is being removed from illumos-gate, and subsequently, illumos-omnios. I'd like to put a replacement FTP server into omnios-build, so it can still be there. I can stick with the identical version that's being ripped out, but I'd rather, if possible, put something newer in its place. We may lose some of the PAM and other integration features, unless that's a show-stopper for anyone (esp. paying customers) out here. If you have suggestions, please let me know. I'm leaning toward being lazy for now and just moving the source to be ripped out into something consumable by omnios-build. I can be convinced otherwise without much effort, though. I'd appreciate it if you speak up on this thread with your suggestions. Thanks, Dan McD. -- OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] FTP server leaving illumos. Replacement suggestions?
On Aug 8, 2014, at 10:10 AM, Stephen Nelson-Smith step...@atalanta-systems.com wrote: Hi, On 8 August 2014 15:06, Eric Sproul espr...@omniti.com wrote: IMHO the existence of an FTP daemon in the base OS runs counter to the OmniOS minimalist philosophy. +1 for me. SNIP! This is a valid perspective. I do believe, however, that we need to have SOMETHING available once the illumos rip-out happens. I suppose it can live in omnti-ms, but I do think it needs to live somewhere. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] FTP server leaving illumos. Replacement suggestions?
On Aug 8, 2014, at 11:08 AM, Eric Sproul espr...@omniti.com wrote: On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling richard.ell...@richardelling.com wrote: sftp is there +1. FTP is more and more a legacy/niche service. The world has moved on and there are better ways of distributing files, like sftp or even http/https. Then let me rephrase my question, given my possibly faulty assumptions: DO WE NEED TO SCRAMBLE TO REPLACE in.ftpd IF IT'S YANKED OUT? Given Eric's arguments, the answer is no. I can be convinced of yes, but it'll take more convincing now. (No is less work for me, so I'm biased. :) ) Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] SuperMicro Board Reboot Hang
On Aug 13, 2014, at 4:43 PM, Matthew Mabis mma...@vmware.com wrote: Hey all, I looked at some of the past notes on this but it looked like the discussion tiered off and stopped. I was wondering if there was ever a resolution to the Reboot hang issues with OMNI. Running a SuperMicro Board 16GB Ram soon to be updated... my first thought is it has something to do with SMB but i have also seen this happen when its Core Dumped b/c SMB crapped itself. Basically the server will just sit at the Rebooting words and do nothing it requires physical intervention to reboot the box. Haven't Tried shutdown honestly cause i keep it up all the time! Was there any incite to what is causing this like fast boot or something? To eliminate fast reboot, utter reboot -p. That's how you force reboot into the BIOS again. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Install issues
First off, I'm a little surprised the r151010 stick or ISO didn't boot for you. I've been off in bloody development, so I know THAT ISO works. Any suggestions on how to get to r151010 which is where I want to be? Try this: 1.) Create a new boot environment: beadm create 010 2.) Mount it: beadm mount 010 /mnt (Assuming /mnt is empty, of course.) 3.) Change the publisher on the new be: pkg -R /mnt set-publisher -G http://pkg.omnti.com/omnios/release/ -g http://pkg.omniti.com/omnios/r151010 omnios 4.) Upgrade the new BE: pkg -R /mnt update 5.) Unmount the new BE: beadm umount 010 6.) Reboot, but when GRUB shows up, select the 010 BE to test it. If it works, you can use beadm activate 010 to make it permanent. Cheesy, but effective, Dan p.s. Technically I'm on vacation, so pardon any high latency in the followup. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Install issues
On Aug 24, 2014, at 11:25 AM, Scott LeFevre slefe...@indy.rr.com wrote: Dan, That did the trick. I'm up on r151010. Thanks! That's how I bootstrap new bloody releases (e.g. 151011 from 151010). Never done it officially moving 006/008 up to 010. BTW, can this approach (with some modification) be used to move to OmniOS from a running install of OpenIndiana for example? I don't think so, because: 1.) OI uses a different package name, numbering, and possibly even contents in some corner cases. 2.) I've never tried anything even close to it. I moved my home server from OI to OmniOS when I started work here (see http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html), and I just exported the data pool, reinstalled the system, took config files by hand from the OI rpool, and moved forward. I'm VERY glad the alt-BE approach worked out okay. I also use that approach to upgrade my zones. The downside to that is if you have operational data in the rpool/BE, it won't all move over when you upgrade. The OmniOS wiki recommendation for upgrading zones mitigates operational amnesia, at the cost of downtime. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] r151012 is coming...
Hello folks! I'm now starting to wind up the r151012 build process. You'll see me dump updates here occasionally. What I'd like to know now is: Any updates you need/want in r151012? If you've been keeping up with my bloody announcements, everything you see there will be landing in r151012. This includes HW goodies like LSI 3008-based 12G SAS (albeit not at optimal performance yet), for example. Once this week's bloody update goes out, there will be a lot of updates to both userspace and in the kernel. I'd like to hear if anyone here has suggestions. I cannot guarantee I will take 'em, but I can at least explain why-not if I don't. Thanks, Dan McD. - OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151012 is coming...
On Sep 2, 2014, at 2:41 PM, Lauri Tirkkonen loth...@iki.fi wrote: On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: What I'd like to know now is: Any updates you need/want in r151012? Since you asked - how about this? :) https://github.com/postwait/pkg5/pull/4 Yes. I'd have pulled it for THIS WEEK's bloody, but given the shitstorm that happened two weeks ago, I did not. Thanks for the reminder, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151012 is coming...
Something to consider, but not in the timeframe for 012. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) On Sep 2, 2014, at 3:13 PM, Valrhona valrh...@gmail.com wrote: It would be convenient if pkgsrc were installed (not that it's a huge deal to install it, just one more thing to do on a new install). Obviously not all of the packages in that repository will work perfectly, but certain things are very convenient and quick to install. On Tue, Sep 2, 2014 at 2:45 PM, Dan McDonald dan...@omniti.com wrote: On Sep 2, 2014, at 2:41 PM, Lauri Tirkkonen loth...@iki.fi wrote: On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: What I'd like to know now is: Any updates you need/want in r151012? Since you asked - how about this? :) https://github.com/postwait/pkg5/pull/4 Yes. I'd have pulled it for THIS WEEK's bloody, but given the shitstorm that happened two weeks ago, I did not. Thanks for the reminder, 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 bloody now updated
Pardon the skip of last time's update. A lot has changed here in preparation for the next stable release (r151012). Because of the amount of change, I've pushed out a complete set of updated packages to the bloody repo. This means you'll have to update pkg(5) prior to a full-blown update. If all goes well, there will be no bloody update in two weeks, and in 4-6 weeks, r151012 will show up. If there is a bloody update in two weeks, it will be very close to what becomes r151012, otherwise THIS will be very close to what becomes r151012. I may also choose to update packages very selectively and sproadically between now and r151012 (e.g. updates to timezones or PCI IDs). What's new in this update is: * In userspace: Update unixodbc to 2.3.2 Update swig to 2.0.12 Update sqlite-3 to 3.8.5.0 Update sigcpp to 2.3.2 Update screen to 4.2.1 Update rsync to 3.1.1 Update readline to 6.3 Update simplejson to 3.6.2 Update pycurl to 7.19.5 Update numpy to 1.8.1 Update Mako to 1.0.0 Update M2Crypto to 0.22.3 Update lxml-26 to 3.3.5 Update CherryPy to 3.5.0 Update pv (pipe-viewer) to 1.5.3 Update pcre to 8.35 Update gnu-patch to 2.7.1 Update OpenSSH to 6.6p1 Update NTP to 4.2.7p460 Upgrade libpcap to 1.6.1 Update libidn to 1.29 Update libffi to 3.1 Update less to 458 Update iso-codes to 3.55 Update ISC DHCP to 4.3.1 Update ipmitool to 1.8.14 Upgrade gnu-tar to 1.28 Upgrade gnu-grep to 2.20 Update gmp/gnump to 5.1.3 Update git to 2.0.4 Upgrade gettext to 0.19.2 Update Amazon EC2 API to 1.7.1.0 Update gawk to 4.1.1 Update flex to 2.5.39 Update expat to 2.1.0 Update curl to 7.37.1 Update coreutils to 8.23 Update NSS (3.16.4), NSPR (4.10.6), and ca-bundle. Update bison to 3.0.2 Update gnu-binutils to 2.24 Update bind to 9.10.0-P2 Update bash to 4.3. * And in the illumos part of things: - Removal of ntfsprogs and partd. (If this is something people want, speak now, so we can get it landed somewhere in userland) - Serious header cleanup. No more KR prototypes (you should've been already, but use ANSI C now, please). - Small mpt_sas bugfixes. (Anyone using 12G yet?) - More man page improvements. Thank you! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Aggregation Link fails with flow-control enabled
On Sep 3, 2014, at 7:05 AM, David Seira dse...@stackscale.com wrote: - Add a flow-control for the aggregation interface: flowadm add-flow -l aggr0 -a local_ip=1.2.3.4 flow_aggr0 After this, if I shutdown one of the interfaces in the switch I loose the connectivity with the server. It seems that the aggregation doesn't forward the traffic to the other interface. Having one of the ports in the switch down, and without connectivity with the server because of the above issue; If I remove the flow (through the console, of course), the server goes online immediately. If I add the flow again, the server is innacessible again. Silly question -- are you adding properties to the flow (priority or maxbw)? I don't doubt you've a bug, but I'm curious if it's limited to what is in effect a NOP flow, or if it affects a proper flow (where it's enforcing something)? Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Install ISO issues (was Install issues)
On Aug 25, 2014, at 8:38 PM, Keith Paskett ke...@paskett.org wrote: Just a note, that I have had the same issue with r151010 hanging after the copyright notice. I have the issue when booting from CD on several different SunFIre servers. They are X4150s and X4250s. I have not yet tried on other systems. Multiple people have reported issues with the most recent r151010 install ISO. I'm seeing it, AND I'm seeing it on a newly-spun ISO as well. I've re-respun 151010u for ISO and USB-DD. I believe user danmcd's default umask of 077 was causing problems with distro_const. The new 'u' ISOs for 151010 are up on the servers now. Sorry for the inconvenience, back to 151012 for me! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151012 is coming...
On Sep 4, 2014, at 4:04 PM, Jorge Schrauwen sjorge...@blackdot.be wrote: lotheac said on IRC virtio is just pulls in vioblk as there is no virtio-net driver. But the vioblk is the important one for installs. But getting it in entire would be nice, that would mean kayak images will have it too :) osdev3(~/ws/omnios-build)[0]% git diff diff --git a/build/entire/entire.p5m b/build/entire/entire.p5m index e9ccf1f..2ff6be2 100644 --- a/build/entire/entire.p5m +++ b/build/entire/entire.p5m @@ -32,6 +32,7 @@ depend fmri=driver/graphics/drm@0.5.11,5.11-@PVER@ type=requir depend fmri=driver/i86pc/fipe@0.5.11,5.11-@PVER@ type=require depend fmri=driver/i86pc/ioat@0.5.11,5.11-@PVER@ type=require depend fmri=driver/i86pc/platform@0.5.11,5.11-@PVER@ type=require +depend fmri=driver/misc/virtio@0.5.11,5.11-@PVER@ type=require depend fmri=driver/network/afe@0.5.11,5.11-@PVER@ type=require depend fmri=driver/network/amd8111s@0.5.11,5.11-@PVER@ type=require depend fmri=driver/network/atge@0.5.11,5.11-@PVER@ type=require @@ -113,6 +114,7 @@ depend fmri=driver/storage/sdcard@0.5.11,5.11-@PVER@ type=re depend fmri=driver/storage/ses@0.5.11,5.11-@PVER@ type=require depend fmri=driver/storage/si3124@0.5.11,5.11-@PVER@ type=require depend fmri=driver/storage/smp@0.5.11,5.11-@PVER@ type=require +depend fmri=driver/storage/virtio@0.5.11,5.11-@PVER@ type=require depend fmri=driver/usb/ugen@0.5.11,5.11-@PVER@ type=require depend fmri=driver/usb@0.5.11,5.11-@PVER@ type=require depend fmri=driver/virtualization/kvm@1.0.3-@PVER@ type=require osdev3(~/ws/omnios-build)[0]% Something like that? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] E5-2600 v3 Haswell
On Sep 10, 2014, at 8:50 AM, Schweiss, Chip c...@innovates.com wrote: I see systems based on Xeon Haswells are shipping now. Has anyone tried OmniOS on any of these yet? Not to my knowledge. What are my chances everything working as expected with OmniOS on these systems if I would order one today? 1.) I'd stick with a GigE mobo instead of a 40GigE one. The i40e driver isn't ported to illumos yet, and I'm not sure if this time we'll get Intel's help. Having said that, there is community interest, but no known driver bits are available. 2.) USB3 isn't supported on illumos yet as well. I don't know if these mobos can have their USB set to USB2 only or not, or whether or not even USB3 is a problem. 3.) Eric covered the SATA ports and the NVMe things. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] E5-2600 v3 Haswell
On Sep 11, 2014, at 2:40 PM, Jon Hull jh...@jncs.com wrote:
Hi,
On a Supermicro X10DRI with dual E5-2650V3 and 64GB DDR4 2133 RDIMM ram, I
was able to install OmniOS r151010u with no noticeable problems.
Oh this is great news. Both that the r151010u disk is working for someone else
(older version of it had... brokenness), and that it installs on the Haswell-E
platform.
The board has 1g nics and those worked fine (igb). I was supposed to get a
10g version of the board but my boss sold it before I had a chance to test it
out.
The 10g may actually be a 40g with 4x 10G ports. If it's the part I'm
thinking about, it's the i40e, which illumos does not yet support. Do you
know what 1GigE igb part it is? Is it I350, or something newer?
The sata ports worked in ahci mode.
As they should. Excellent. (How many do you get?)
I was not able to try the USB3 but there was options in the bios to disable
USB3. Not sure if this disables the ports altogether or just makes them USB2.
It *should* just make them USB2, and I'm glad the BIOS lets you disable that.
We don't have USB3 in illumos yet either.
For a pretty basic server board, everything seemed to work right on boot.
This is a dual-socket board, you said? I'd be interested to know if you see
any odd latencies - I've seen {Sandy,Ivy} Bridge-E boards occasionally exhibit
odd latencies with 10GigE, but it was very difficult to characterize and
reproduce.
Nonetheless, this is good news!
Thanks,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
On Sep 12, 2014, at 9:19 AM, Dan Vatca d...@syneto.net wrote: I'm compiling omnios bloody and I get this crash during cdrtools compilation: make: Warning: Ignoring DistributedMake -j option --== MAKING SYMLINKS in ./RULES/ sh: line 1: 14171: Memory fault(coredump) mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()%abcdefghijklmnopqrstuvwxyz,--%'' returned status `0' This creates a core with this stack trace: root@bloody:/var/cores# mdb core.sed.6628 Loading modules: [ libc.so.1 ld.so.1 ] ::walk thread | ::findstack -v stack pointer for thread 1: 80462a8 [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) Did anyone else run into this? No, but I'm off bloody for now... (trying to bringup 012 and 013), and trying to beat back serious IPS problems I accidentally introduced. Can you reproduce this crash with just the command listed above all by itself? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
On Sep 12, 2014, at 11:03 AM, Dan Vatca d...@syneto.net wrote: Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. Hmmm. I want to try this out on on OI with a very latest illumos-gate. I suspect it was introduced with some recent changes in that space. I'll get back to you with those OI results. If they fail the same way on OI, I will file an illumos bug and see if someone up there can fix it. Be right back, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
Dan V. -- As a workaround, set your LANG to 'C' instead of en_US.UTF-8. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Quick question -- FTP server usage in OmniOS?
Recently, but after the freeze for r151012, the FTP server was removed from illumos-gate. This means that it will be removed from the illumos-omnios gate for the new bloody (r151013) and the next stable+LTS (r151014). I'm curious if this is a big loss or not for our users. If it IS, then clearly part of the 013 bloody cycle is to replace the removed FTP server with something else, OR continue to maintain it. I'm inclined not to replace it, unless I get a large mob of torch-and-pitchfork-wielding folks. Curious, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
Pardon the top post, at a soccer game. I compile bloody, and gcc48 *appears* to work for me. The buildctl script should halt if something doesn't compile. I'll check the logs for 012 and 013 when I get home today. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) On Sep 13, 2014, at 10:29 AM, Dan Vatca d...@syneto.net wrote: Just as a quick note to whoever compiles bloody: a broken sed will also trip the gcc48 compilation with a not so obvious error. I worked around it for now by using tr instead. If you get this: 'use of enum ‘reg_class’ without previous declaration' and are currently running on bloody, the you'll have to change gcc/mkconfig.sh to use tr instead of sed for the hg_sed_expr / header_guard definitions. On Fri, Sep 12, 2014 at 7:50 PM, Dan Vatca d...@syneto.net wrote: Looks related to the POSIX 2008 locale object support (https://www.illumos.org/issues/2964) Maybe Garett can take a look at this. On Fri, Sep 12, 2014 at 6:58 PM, Dan Vatca d...@syneto.net wrote: It crashes with LANG=C too. Just tested that. As a workaround I will use tr instead of sed. On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald dan...@omniti.com wrote: Dan V. -- As a workaround, set your LANG to 'C' instead of en_US.UTF-8. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Building developer/make fails for unresolved dependencies
On Sep 13, 2014, at 2:49 PM, Dan Vatca d...@syneto.net wrote: There is the local.mog transform that must work to drop those dependencies, but for some reason, it keeps failing when it runs through build all. Any idea on what I'm missing? I honestly am not sure. If you cd make ; ./build.sh -bpil what does it do? I'm also curious what buildctl list-build says? It sorts based solely on bash's associative array sorting. Maybe the default bash sorts one way, and your bash (did you compile it oddly?) another way? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] problems with kayak r151010
On Sep 15, 2014, at 3:26 PM, Doug Hughes d...@will.to wrote:
I had some problems with 006 also, but these appear to be different so far. I
took an omniOS 008 machine and upgraded to 010 using the standard upgrade
mechanism. Totally successul. My /etc/release is updated and everything is
fine. Then I made sure that the kayak and kayak-server packages were
installed. So far so good.
1) the url listed is =http://pkg.omniti.com/omnios/release
This doesn't work with OmniOS 010. It complains about the 'entire' not being
a valid package to install. if I substitute r151010 on this line and the
following as such, I get past this issue:
OMNIOS_URL=http://pkg.omniti.com/omnios/r151010
: ${PKGURL:=http://pkg.omniti.com/omnios/r151010}
: ${BZIP2:=bzip2}
Yeah. That may be a bug in kayak itself.
2) this line appears to be wrong:
pkg -R $MP install entire@11-0.$entire_version || fail install entire
substituting that with:
pkg -R $MP install entire@11,5.11-0.$entire_version || fail install entire
works much better. (that's the right thing for the upgrade as well)
3) if the build fails for any reason, it leaves unclean state behind. There
should be a troubleshooting step that recommends doing zfs destroy -r
rpool/kayak_image
H...
4) the r151010 kayak-server doesn't seem to include miniroot. Where do I find
that now?
... I'm not sure, and my Kayak knowledge has always been shaky.
I'm trying to get r151012 ready, so I'll make DAMNED sure Kayak works on there,
but I'm not sure how to fix the 010 version. Eric or Dale, may, however.
Sorry I can't help more fully,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] problems with kayak r151010
On Sep 15, 2014, at 8:24 PM, Dan McDonald dan...@omniti.com wrote: Actually... I'd fixed these in the bloody branch, and have fixed them as well in the r151012 branch. If you checkout either of those branches, you should see the mods (and a comment reminding future folks to keep 'em up to date). To be fair, I fixed them VERY RECENTLY, bloody in August, and r151012 just last week when I created that branch in the kayak repo. Sorry for not putting 2 + 2 together sooner, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Intel C600 driver issue
I believe the difficult one, as you put it, is the SCU (ahh, you even call it out in your PCI scans). Illumos has no driver for the C600 SCU, so you're out of luck. There was a prototype rumored to be floating around, but given most people ponied up for an LSI SAS HBA, which performed better, there was not a strong community push to get it up and running. Sorry I don't have better news, Dan Sent from my iPhone (typos, autocorrect, and all) On Sep 17, 2014, at 3:12 AM, Marion Hakanson hakan...@ohsu.edu wrote: Greetings, I'm trying to install OmniOS 151010u onto an Intel S2600WP motherboard, and the OmniOS live image is not finding the boot/root drive. This system is in a 4-motherboard chassis with a disk backplane on the front, and each of the 4 motherboards gets some drive slots on that backplane. In this particular case, there's a single SSD for boot/root, and while the motherboard includes two SATA controllers, the SSD is plumbed to the difficult one, which has two modes in the BIOS: (1) RSTe mode (default); Functions in SATA pass-through mode, according to the BIOS blurb. Windows would use the iastor driver. In this mode, the device describes itself (in prtconf -Dv or scanpci) as: C602 chipset 4-Port SATA Storage Control Unit (2) ERST2 mode; Functions like an LSI-something SAS/SATA RAID controller. Windows/Linux would supposedly use the megasr driver. In this mode, the device describes itself (in prtconf -Dv or scanpci) as: C600/X79 series chipset 4-Port SATA Storage Control Unit Unfortunately, OmniOS drivers do not attach to this device. I've tried some manual driver suggestions, all of which fail to attach, in either of the above two modes: update_drv -a -i 'pci8086,358f' mpt update_drv -a -i 'pci8086,358f' mega_sas update_drv -a -i 'pci8086,358f' mr_sas update_drv -a -i 'pci8086,358f' mpt_sas update_drv -a -i 'pci8086,358f' ahci I've also tried pci8085,106b, which is a device-id alias listed in the prtconf -Dv output. Has anyone in OmniOS- or illumo-land gotten the OS to talk to this storage controller? Suggestions? Linux appears to use the isci driver for this device. Thanks and regards, Marion ___ 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] Intel C600 driver issue
On Sep 17, 2014, at 1:58 PM, Marion Hakanson hakan...@ohsu.edu wrote: The SCU can be upgraded with optional RAID Upgrade Key thingies that you plug into a socket in the motherboard. Some of them enable SAS-mode, among other things, but I suspect we'd still be stuck with something that doesn't speak to the mpt_sas, etc. drivers in illumos. That's correct. No SCU support for any of those, with or without a RAID Upgrade Key. (Unless there's some bizarro way for them to look/smell/feel like AHCI, which I doubt is the case.) There is actually an AHCI SATA controller onboard too, but the disk backplane in this 4-node chassis seems to be directly wired (via a bridge-board) to the SCU. That's disappointing. I suppose this is a limitation of the form factor? The one exception is Port 0 on the system's AHCI SATA controller, which allegedly goes to a special DOM socket. The system came with an Intel DC S3700 SSD for its boot drive, regular SATA unit, and there doesn't seem to be space in this jam-packed motherboard + chassis to connect it to one of the other onboard AHCI SATA ports. Eeesh. Hmm, Plan B? Those DOM's aren't cheap. Would 16GB be sufficient? http://www.directron.com/d150qvlintel16.html Can dump/swap zvols be on a non-mirrored (raidz3) external pool? 16GB can keep an rpool and some amount of subsequent BEs. You can definitely put *dump* zvols on a raidz3 pool as of r151010, thanks to this illumos fix: https://illumos.org/issues/2932 I wasn't sure about swap, but a quick query of #illumos on IRC suggests that YES, you can. So 16GB rpool + everything else on your big pool == win. Hope this helps, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August
I've been getting r151012 ready to ship, but while doing so, I discovered some bad news that, thankfully, will not affect r151012 from a user's point of view.. unless you wished to upgrade from bloody (r151011) to r151012 or the new r151013 bloody. As of the update of CherryPy to 3.5.0 (which was subsequently ripped out of omnios-build, but lingers in the bloody repo), the http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your BE is toxic as well. If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you last updated on the August 9th bump), you can actually upgrade safely to r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall your bloody box with r151012 or the r151013 version of bloody off a CD, USB, etc. I haven't yet gone and ripped things out of the bloody repo, but I'm planning on just replacing it with a brand new set of r151013 packages once r151012 is out the door and the r151013 ISO USB get burned. Sorry if this causes you any inconvenience, but since it is the bloody repo, sometimes things will get messy. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August
On Sep 18, 2014, at 8:58 PM, Josef 'Jeff' Sipek jef...@josefsipek.net wrote: On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: I've been getting r151012 ready to ship, but while doing so, I discovered some bad news that, thankfully, will not affect r151012 from a user's point of view.. unless you wished to upgrade from bloody (r151011) to r151012 or the new r151013 bloody. As of the update of CherryPy to 3.5.0 (which was subsequently ripped out of omnios-build, but lingers in the bloody repo), the http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your BE is toxic as well. If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you last updated on the August 9th bump), you can actually upgrade safely to r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall your bloody box with r151012 or the r151013 version of bloody off a CD, USB, etc. Uninstalling it isn't an option? It's a rat's nest of dependencies, since pkg.depotd depends on CherryPy directly (and its requirement of a specific version or earlier is how I discovered the mess in the first place). Godawful, trust me. Old BEs before the CherryPy update are your best bet. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August
Yeah, you'll have to start from your previous BE to get to 012 or 013. You can use beadm(1M) to clone a new BE from the old one, then use pkg -R. Eg. beadm create -e oldbe newbe beadm mount newbe /mnt pkg -R /mnt set-publisher pkg -R /mnt update The only gotcha is any data from your current BE SHOULD be migrated to newbe. Dan Sent from my iPhone (typos, autocorrect, and all) On Sep 19, 2014, at 4:34 PM, Richard PALO rich...@netbsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/09/14 04:44, Dan McDonald a écrit : On Sep 18, 2014, at 8:58 PM, Josef 'Jeff' Sipek jeffpc-pm1ls4bqfqufeyicpp4...@public.gmane.org wrote: On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: I've been getting r151012 ready to ship, but while doing so, I discovered some bad news that, thankfully, will not affect r151012 from a user's point of view.. unless you wished to upgrade from bloody (r151011) to r151012 or the new r151013 bloody. As of the update of CherryPy to 3.5.0 (which was subsequently ripped out of omnios-build, but lingers in the bloody repo), the http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your BE is toxic as well. If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you last updated on the August 9th bump), you can actually upgrade safely to r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall your bloody box with r151012 or the r151013 version of bloody off a CD, USB, etc. Uninstalling it isn't an option? It's a rat's nest of dependencies, since pkg.depotd depends on CherryPy directly (and its requirement of a specific version or earlier is how I discovered the mess in the first place). Godawful, trust me. Old BEs before the CherryPy update are your best bet. Dan Dan, if I understand correctly... if my current BE has: pkg://omnios/library/python-2/cherrypy@3.5.0,5.11-0.151011:20140902T192935Z but a previous BE pkg://omnios/library/python-2/cherrypy@3.2.2,5.11-0.151011:20140723T191919Z the only recourse is to boot the previous BE and upgrade to lastest. No other way? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUHJNtAAoJECAB22fHtp27wckH/ikDZ1ioqNC9AToEf3Ex2fhS 1I9JNRUcWtYyraw7hKxIDBqPxFnDa64GiiMESAWOd23lV7/UbtNc6miX9Q+5Ob7R pLo5QBx2oU+kijCq6bshktgbvbTUpaHT2R3budnwZDFZ6retuiH4GCR3qR1gxl9q wuMQ8+5X5OQ+zNdf5+dYAzpcZzsK000ji686btS02nwjRJTFRwgRNRWNR4ZPVgS8 aKw1rdAEh/7M7wvR5jnfSuxvng0GxfxqHGhDbvb2C/jDdDZKft7Cxwf6dsiYuE6k OnuSWP3pJOnsmOlq4h8IYKlUBwfpaJDR4/pHni8MvDkDbplvb6AQhGOhQkG3Qks= =sG4A -END PGP SIGNATURE- ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Panic when starting installer as KVM guest
On Sep 19, 2014, at 10:25 PM, David Khacherian dmkhacher...@csupomona.edu wrote: I've been trying to get the OmniOS installer working under kvm with qemu, and I'm always presented with the same kernel panic at the same place after the Oracle copyright notice, after which the installer restarts itself: SunOS Release 5.11 Version omnios-b281e50 64-bit Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. panic[cpu0]/thread=fbc2fac0 I've tried both the LTS and current stable installers, and they give the same results. I've tried disabling ACPI and HPET, varying the amount of RAM and VCPUs, etc..., to no avail. Here's the exact line I'm using to invoke qemu: qemu-system-x86_64 -enable-kvm -vga std -m 2048 -cdrom OmniOS_Text_r151010u.iso -boot order=d omnios.img Output of 'qemu -version': QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard And if it helps, the KVM host is Gentoo, with a hardened 3.15.8 kernel. The use-flags I used when building qemu can be found here: http://pastebin.com/hDTUgU4r Omitting -enable-kvm lets the virtual machine run as expected, albeit at a crawl. I suspect that there may be a bug at work here, and I'd greatly appreciate any suggestions on how to proceed. Thanks for your time. You're seeing this with the boot iso, right? Next time, when presented the opportunity, press ESC and get to the grub menu. When you get there, press 'e' for edit, then edit the line with unix toward the end. After /unix and before any other flags, insert -k. You will boot with kmdb, and when it panics, you will enter the kernel debugger, where you can show this list the panic stack with mdb's $c command. Please share that stack with the list. THanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] further problem with r010 install with kayak
On Sep 22, 2014, at 9:27 PM, Doug Hughes d...@will.to wrote: I got the miniroot (earlier emails) worked out by getting the bloody build and building a new miniroot, but I suspect that this is making the final boot non-functional because it's not backwards compatible because it includes new com.delphix:embedded_data. That's likely the problem. The kayak install works fine, but I get a bunch of missing feature messages very quickly (had to catch them in video from my camera-phone), and then it just goes to grub, so it won't boot successfully. I do have a working 012 kayak build, but I know that's not ready yet, and the r011 should be considered toxic. You can always, post-install, edit the unix line in grub and add -k to the flags. This will force a boot with the kernel debugger loaded. Instead of panicking and rebooting, it'll drop into the debugger, where you can utter $c and other commands to see where it broke. Looking for advice on the best course of action here (since the r010 included miniroot is totally broken) I wish I had a good answer for you. We have two things left before 012 can officially release, and one of them is this very miniroot kayak problem you were seeing. I won't release 012 until we have kayak miniroot working satisfactorily. (Right now, the miniroot panics, and even using -k doesn't help!) The other problem is more pressing, though, so I can't get you progress on kayak until I solve this other problem. Thank you for your patience, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files)
Hmmm, perhaps trying the installgrub, AND the stageX files from the r151010 BE... /mnt//installgrub /mnt/boot/grub/stage[12] /dev/rdsk... That would keep things more recent. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] SolarFlare SFXGE with OmniOS
On Sep 25, 2014, at 3:35 PM, Doug Hughes d...@will.to wrote: (I'd be happy to volunteer a sfxge.conf for this, also we should use the Solaris postinstall or a variant of it to do the correct add-drv and driver_aliases stuff.) That's all packaging - make sure the delievered .mf file is good and you're golden. Looking forward! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO
On Sep 29, 2014, at 2:35 PM, Jorge Schrauwen sjorge...@blackdot.be wrote: Just an update, switching to IDE sort of makes it install but it takes about an hour or so and it only boots once after that. It also only enables 1 cpu using either core2due, Nehalem or qemu64 cpu type. Does anybody have a working 012 running inside KVM on 012? I have to ask -- what problem are you solving by running a full KVMed 012 inside 012? What does that buy you that a simple native zone can't? I understand there's virtio issues, but I figured you'd be having them on some other KVM. Don't forget that ZFS-inside-ZFS is akin to running TCP-inside-TCP w.r.t. unusual feedback loops and patterns. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO
On Sep 29, 2014, at 3:48 PM, Jorge Schrauwen sjorge...@blackdot.be wrote: Build environment, that's the only reason. AFAIK that still does not work in a zone yet. You can build illumos-omnios in a zone, but not *some* of the omnios-build packages (kayak primarily). Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO
On Sep 29, 2014, at 4:14 PM, Jorge Schrauwen sjorge...@blackdot.be wrote: Excellent news, I would greatly prefer a zone over a kvm! I'll be mostly interested in building illumos-gate and illumos-omnios. You can't build illumos-gate just yet on omnios. But unless you're dinking in specific subsystems, you can develop with illumos-omnios, then shuffle it over to illumos-gate for a last-minute OI build pre-integration. Some more info: Omnios 012 works fine on and is 'usable' on SmartOS using ide mode. Fails the same way with vioblk :( So it seems to be am OmniOS 012 on OmniOS KVM issue. But hey if zones work, i'm not going to waste more time. I build illumos-omnios occasionally on my HDC's omniti zone. make-clobber-to-full in 100 minutes (CPU bound with my low-power Xeon E3). Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO
On Sep 29, 2014, at 4:19 PM, Jorge Schrauwen sjorge...@blackdot.be wrote: Alright! I'm stuck home (crushed nerv in foot) the entire week so if you got a bit of time to point me in the right way to setup a zone like that. That would be sweet. Finishing some last bits of testing to with OmniOS vs SmartOS KVM running 012 because I just want to be complete for my self :) Lots of output appended as attachments. These include: - My illumos-omnios.env file for /opt/onbld/bin/nightly. - My list of packages on my omniti zone. I think I'll spin up a nightly now, just to be sure. Dan illumos-omnios.env Description: Binary data pkgs Description: Binary data ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Coming soon: r151013 version of bloody
On Sep 30, 2014, at 2:12 PM, Dan McDonald dan...@omniti.com wrote: So heads up, r151013 will be coming very soon. I will have release media for it at the same time. If anyone out there uses Kayak, I'd be especially interested in bloody testing for Kayak. If I hear no objections, I plan on cutting all of this over before COB today, US/Eastern (which is between 2100-2200 GMT if I did my timezone calculations correctly). Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
