[00:03:46] *** jim80net has joined #smartos
[00:07:41] *** BugeyeD has quit IRC
[00:11:11] *** pettson has quit IRC
[00:11:20] *** neophenix has quit IRC
[00:20:40] *** julianduque has quit IRC
[00:33:50] *** echelog-1 has joined #smartos
[00:36:33] *** theCzar has joined #smartos
[00:39:49] <theCzar> So I just tried to change the timezone within a smartos zone on my machine. It worked, and date now returns the correct value. But it said I need to reboot now that I've made the change. Is this actually necessary or just recommended? Are what are the possible consequences of not rebooting after making this change/
[00:40:18] <theCzar> s/Are what/And what/
[00:40:28] <wesolows> changing the timezone "globally" affects only new processes.
[00:40:48] <wesolows> so I would expect existing ones to continue using the previous timezone that was in effect at the time they were started.
[00:41:02] <wesolows> that might mean logging things with unexpected timestamps, for example.
[00:41:02] <theCzar> wesolows: OK that makes sense. Is there a way I can specify what timezone to use in the payload?
[00:41:11] <wesolows> payload?
[00:41:30] <rmustacc> You mean via vmadm?
[00:41:31] <theCzar> the json payload used to create the zone (sorry possibly the wrong term)
[00:41:39] <rmustacc> No, there isn't.
[00:41:41] <wesolows> I don't think so.
[00:41:57] <wesolows> it works exactly the way the man page describes, and the way it would work on bare metal.
[00:42:19] <theCzar> wesolows: yes of course, that makes sense
[00:42:21] <wesolows> You could, however, create your own image with a nonstandard timezone.
[00:42:58] <theCzar> yeah, I'm trying to have it dynamically set for users all around the world
[00:42:59] <konobi> or add it to your bash profile
[00:43:19] <wesolows> konobi: except that only works for things run interactively and/or by root. It won't change init.
[00:43:49] <wesolows> if you have users all over the world, I strongly strongly recommend that you just use UTC.
[00:43:56] <wesolows> Let each user set his own timezone.
[00:44:04] <theCzar> looks like I may just need to put in into init default or something and just make that change before my scripts bring any thing else on line
[00:44:27] <wesolows> That's probably easiest. There are also user scripts, but I think that's SDC-only.
[00:44:58] <theCzar> wesolows: yeah we have access to user scripts. I may just do that.
[00:47:42] <konobi> wesolows: yeah, though UTC ftw... too much headache otherwise
[00:48:33] <theCzar> konobi: I wholeheartly agree. UTC everywhere. Forget Timezones, not just on servers.
[00:48:36] <theCzar> :P
[00:48:39] <theCzar> but seriously...
[00:49:20] <theCzar> I don't care if the sun comes up at 10pm.
[00:49:39] <theCzar> but as for this, my users/boss do
[00:49:50] <theCzar> so I'll probably just leverage user-scripts
[00:50:14] <konobi> normally i just stick TZ= in /etc/profile
[00:51:31] <wesolows> The question here is really whether the TZ is per-human or per-zone
[00:51:48] *** wolstena has joined #smartos
[00:52:12] <wesolows> The only reason to use a non-UTC timezone across an entire zone is if all the users of that zone expect to see everything in the same non-UTC TZ.
[00:52:18] <wesolows> Otherwise you just move the problem around.
[00:52:58] <wesolows> If it's per-human, you want to take konobi's approach and put the TZ value in each user's profile so they can all be different according to their own physical location.
[00:53:28] <wesolows> Then the only problem comes in interpreting things that were laid down in UTC and are not interpreted by the viewer; e.g., text-file log entries examined with cat.
[00:54:06] <wesolows> Of course, there *is* no solution to that problem short of feeding things like that into something that can reconstruct the UTC times and reinterpret them according to $TZ.
[00:58:06] <theCzar> I think I just talked the boss into just forcing UTC
[00:58:29] <theCzar> unless they feel like changing it
[00:58:36] <theCzar> :D
[01:00:23] <oddsignals> heh
[01:01:00] <oddsignals> I had allocated 1024MB memory for a VM and the compile I ran in it needed 1029MB to complete :-P
[01:01:33] <wesolows> congrats :)
[01:01:49] *** jelmd has joined #smartos
[01:01:50] <oddsignals> if only all compile errors could be solved with a vmadm update :-)
[01:03:24] <theCzar> vmadm update '{ "allow_segfault": false }'
[01:03:41] <oddsignals> hah :)
[01:04:47] <rmustacc> You can catch the segv, but it won't go well after that.
[01:05:27] <konobi> let it be known... i hates softwares
[01:06:47] <rmustacc> If you don't, you haven't been using it long enough.
[01:07:44] <konobi> cross-compiling operating systems and packages... PITA
[01:10:22] <oddsignals> so far so good with GHC at least, bootstrapped from the package in 2012Q2 and I'm up to 7.4.2
[01:10:45] <oddsignals> now off to get some sleep while 7.6.3 is compiling
[01:16:44] *** lloydde has quit IRC
[01:17:19] *** lloydde has joined #smartos
[01:18:45] *** julianduque has joined #smartos
[01:19:27] <rmustacc> oddsignals: you may want to let the folks on the mailing list know as I know some others are trying to look at that as well.
[01:22:04] *** lloydde has quit IRC
[01:26:31] <richlowe> on that note, if that (as all this seems to) shows up ld being broken, I'd like to know.
[01:27:28] *** ryancnelson has left #smartos
[01:30:17] *** lloydde has joined #smartos
[01:32:00] *** andoriyu has quit IRC
[01:32:20] *** andoriyu has joined #smartos
[01:37:21] *** andoriyu has quit IRC
[01:37:41] *** andoriyu has joined #smartos
[01:38:56] *** andoriyu has quit IRC
[01:39:17] *** andoriyu has joined #smartos
[01:50:26] *** theCzar has quit IRC
[02:00:27] *** lloydde has quit IRC
[02:01:09] *** FatDarrel has quit IRC
[02:21:34] *** potatosalad has quit IRC
[02:23:24] *** jaimef has quit IRC
[02:30:44] *** jaimef has joined #smartos
[02:31:58] *** jim80net has quit IRC
[02:37:28] *** andoriyu has quit IRC
[02:38:25] *** andoriyu has joined #smartos
[02:59:28] *** volci has quit IRC
[02:59:54] *** volci has joined #smartos
[03:02:51] *** utlemming has quit IRC
[03:03:15] *** jim80net has joined #smartos
[03:03:17] *** utlemming has joined #smartos
[03:04:26] *** andoriyu has quit IRC
[03:04:46] *** andoriyu has joined #smartos
[03:05:56] *** andoriyu has quit IRC
[03:06:18] *** andoriyu has joined #smartos
[03:09:55] *** dap has quit IRC
[03:10:11] *** xenol has quit IRC
[03:11:19] *** mary5030 has quit IRC
[03:20:57] *** andoriyu has quit IRC
[03:22:37] *** AlainODea has joined #smartos
[03:55:04] *** wolstena has quit IRC
[04:06:21] *** mary5030 has joined #smartos
[04:16:57] *** julianduque has quit IRC
[04:17:59] *** nefilim has joined #smartos
[04:58:39] *** ira has joined #smartos
[05:02:25] *** julianduque has joined #smartos
[05:10:35] *** szaydel has quit IRC
[05:22:31] *** potatosalad has joined #smartos
[05:22:43] *** ira has quit IRC
[05:23:50] *** potatosalad has quit IRC
[05:38:04] *** mary5030 has quit IRC
[05:48:25] *** szaydel has joined #smartos
[05:55:04] *** lloydde has joined #smartos
[06:21:07] *** jsm has quit IRC
[06:24:18] *** potatosalad has joined #smartos
[06:25:15] *** AlainODea has quit IRC
[06:25:37] *** jim80net has quit IRC
[07:00:05] *** szaydel has quit IRC
[07:04:25] *** nefilim has quit IRC
[07:11:10] *** griffin_ has quit IRC
[07:13:03] *** ipalreadytaken has joined #smartos
[07:30:10] *** jim80net has joined #smartos
[07:55:33] *** marsell has quit IRC
[07:59:26] *** jaimef has quit IRC
[08:03:47] *** jaimef has joined #smartos
[08:07:07] *** hadret has joined #smartos
[08:15:25] *** lloydde has quit IRC
[08:15:51] *** lloydde has joined #smartos
[08:15:55] *** julianduque has quit IRC
[08:16:07] *** lloydde has quit IRC
[08:19:29] *** wolstena has joined #smartos
[08:55:36] *** swaagie has quit IRC
[08:56:20] *** CaTtleyA has joined #smartos
[08:58:52] *** swaagie[brb] has joined #smartos
[08:59:55] *** swaagie[brb] is now known as swaagie
[09:05:03] *** wramthun has quit IRC
[09:05:18] *** tonist has joined #smartos
[09:07:13] *** wramthun has joined #smartos
[09:07:53] *** tonist has quit IRC
[09:16:34] *** lloydde has joined #smartos
[09:20:01] *** texarcana has quit IRC
[09:21:29] *** alcir has joined #smartos
[09:22:02] *** texarcana has joined #smartos
[09:23:17] *** Red_Devil has joined #smartos
[09:25:16] *** lloydde has quit IRC
[09:27:45] *** tonist has joined #smartos
[09:27:45] *** andy_js has joined #smartos
[09:40:01] *** wramthun has quit IRC
[09:55:00] *** xmerlin has joined #smartos
[10:01:01] *** d[^_^]b has quit IRC
[10:03:29] *** d[^_^]b has joined #smartos
[10:04:16] <oddsignals> rmustacc: I've signed up for the list, I'll send an email later
[10:09:34] <oddsignals> richlowe: no ld problems as far as I can tell - there were some warnings (symbol referencing errors) building 7.4.2 but they disappeared on 7.6.x
[10:09:51] <oddsignals> I think - let me check the build log :-)
[10:10:13] <jperkin> if you can get me an updated ghc bootstrap it'd really help
[10:10:51] <oddsignals> jperkin: sure - 32-bit only so far, should I just tarball up the build dir so you can make install from there?
[10:12:51] <jperkin> I'll check what the other bootstraps use
[10:12:54] <oddsignals> jperkin, actually, I've installed it into /opt/7.6.3 so I'll just zip up that, should take up a lot less space :-)
[10:13:51] <xmerlin> hi guys
[10:14:18] *** leecallen35 has joined #smartos
[10:15:17] <jperkin> sure, sounds good
[10:15:23] *** ivan\ has quit IRC
[10:16:41] *** leecallen has quit IRC
[10:17:12] <xmerlin> I'm comparing two samba fileserver ...the first one based on smartos and the second one based on centos 6.4 both samba 3.x and both on smartos ...as I can see the first one is 2x/3x times faster copying files from workstations ...but the second one is 2x/3x faster copying files from other vms on the same server ...does it make sense in some way?
[10:17:24] <jperkin> it'd be great to get this in for Q3, hopefully update the package to 7.6.3 too (it's currently 7.6.2)
[10:18:07] <oddsignals> I'd love to see it among the packages - was considering packaging it up myself but I have no experience with pgksrc
[10:18:46] <jperkin> yeh, and it's not one of the easiest to get started with
[10:19:18] <jperkin> but that's ok, just send me the working bootstrap and I'll do the rest ;)
[10:40:57]
<oddsignals> jperkin: there were a few failing tests http://lpaste.net/93412 - leroux is submitting tickets
[10:41:26] <oddsignals> jperkin: but nothing that seems to affect bootstrapping
[10:41:39] <leroux> All filesystem related..so I'm thinking that it's just that smartos deals with file permissions differently.
[10:41:58] <leroux> Hopefully it doesn't require another set of #ifdef...
[10:45:06] *** ipalreadytaken has quit IRC
[11:00:12] <jperkin> oddsignals: actually, it looks like the existing bootstraps are bundles of the build area
[11:00:42] <jperkin> if you could get me an archive of that..
[11:01:05] <oddsignals> jperkin: all of it?
[11:01:14] <oddsignals> du -hs ghc-7.6.3
[11:01:14] <oddsignals> 1.2G ghc-7.6.3
[11:01:58] <jperkin> which doesn't look like everything, I'm not sure how they created it
[11:02:15] <oddsignals> jperkin: hm, I think there might be a build target for that - let me check
[11:02:53] <jperkin> if you could follow that layout (including it being in a 'ghc-7.6.3-boot' directory), that'd be awesome
[11:06:01] <jperkin> 'binary-dist' looks like the ghc target
[11:06:45] <oddsignals> jperkin: yes, found it - just finished building, I'll upload the tarball
[11:09:23] *** ilovezfs has quit IRC
[11:10:55] *** ilovezfs has joined #smartos
[11:11:39] <oddsignals> jperkin: let me know if you need anything else or different compile flags
[11:14:28] <oddsignals> going to see if I can get the platform built as well - original plan was 64-bit first, but I was planning on using HEAD for that, and HEAD needs happy to compile, and I need darcs to get the sources for happy, and the platform to compile darcs... so... :-)
[11:18:59] *** mamash has joined #smartos
[11:41:59] *** wramthun has joined #smartos
[11:46:40] *** CaTtleyA has quit IRC
[11:48:16] *** CaTtleyA has joined #smartos
[12:06:40] <jperkin> ghc-cabal: Bad interface file: dist-install/build/GHC/Classes.hi
[12:06:45] <jperkin> magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742)
[12:07:30] *** marsell has joined #smartos
[12:07:32] <oddsignals> strange
[12:09:57] <oddsignals> jperkin: I also just noticed that the profiling libraries are missing from my 7.6.3 install, but they're there for 7.4.2
[12:11:18] <oddsignals> jperkin: are you on a 32-bit base image? haven't tested if it runs on 64-bit yet
[12:11:46] <jperkin> this is 32-bit yeh, the ghc-pwd binary is linked against some pkgsrc libraries so we can't use it as a multiarch bootstrap, at least not yet
[12:16:37] <oddsignals> jperkin: is there another ghc-cabal in your path than the one in my tarball? quick search make it seem like the error indicates a versioning mismatch
[12:18:07] <jperkin> nope
[12:19:33] <oddsignals> jperkin: I'll get back to you once the new build finishes, there might very well be something missing - I see that it's now building the profiling libraries wheras it wasn't before
[12:21:00] <jperkin> I'll try using what I have to create a bootstrap via the pkgsrc method in the meantime
[12:21:20] <oddsignals> jperkin: only thing that's different from last time around is that there's no mk/build.mk, whereas last time I had a copy of build.mk.sample there, thinking the settings were the same as the defaults
[12:21:29] <oddsignals> jperkin: ok, cross fingers :-)
[12:22:03] <jperkin> hm nope, same error
[12:23:22] <oddsignals> which base image? I'm on 13.2.0
[12:24:46] <jperkin> it's an independent base system, using libraries from trunk (what will be 13.3.* soon)
[12:25:46] <jperkin> this is just doing a './configure --prefix=/blah --with-gcc=/path/to/gcc' inside your bootstrap archive then doing a 'gmake install'
[12:25:56] <jperkin> if that works for you it'd be interesting.
[12:25:58] <oddsignals> richlowe: seems like I spoke too soon - the shared libraries weren't being built earlier, now that they're building I am getting the warnings about symbol referencing errors again
[12:26:18] <oddsignals> jperkin: I'll have a look
[12:29:24] <oddsignals> jperkin: "./configure --prefix=/blah; make install" works fine here after extracting the second tarball I sent you
[12:30:31] <jperkin> ok, interesting, thanks.
[12:43:02] <oddsignals> jperkin: do you have any info on how the netbsd bootstrap was built? especially interested in contents of build.mk
[12:43:09] *** ivan\ has joined #smartos
[12:43:38] <jperkin> with the bootstrap target in bootstrap.mk, I assume
[12:43:47] <jperkin> I'm trying that now with the previous installed tar you gave me
[12:54:06] *** ivan\ has quit IRC
[12:58:36] *** ivan\ has joined #smartos
[13:11:59] <oddsignals> I've got a cabal \o/
[13:28:57] *** tonist has quit IRC
[13:31:23] *** szaydel has joined #smartos
[13:50:15] *** ira has joined #smartos
[14:06:35] *** tonist has joined #smartos
[14:13:36] *** tonist_ has joined #smartos
[14:13:43] *** tonist has quit IRC
[14:13:44] *** tonist_ is now known as tonist
[14:18:05] *** jsm has joined #smartos
[14:28:56] *** jim80net has quit IRC
[14:29:14] *** jim80net has joined #smartos
[14:29:53] *** CaTtleyA has quit IRC
[14:45:51] *** jim80net has quit IRC
[14:47:39] <LnxTx> how to boot smartos without importing zones, standalone=true,noimport=true didn't work
[14:48:49] *** mamash has left #smartos
[14:50:59] <jesse_> that should work
[14:51:26] <LnxTx> forcer solution, fdisk -B /dev/rdsk/c0t0d0
[14:51:36] <LnxTx> *force
[14:52:55] <jesse_> you wanted to reinstall?
[14:52:59] <LnxTx> yep
[14:53:08] <jesse_> rm /zones/.system_pool
[14:53:31] <jesse_> zpool destroy zones
[14:54:39] <jesse_> might actually not work without booting into noimport=true =)
[14:55:15] <jesse_> if you have a pool named 'zones' importable, the installer will use that
[14:55:19] <jesse_> instead of creating a new one
[14:57:58] <LnxTx> ok, i will try if i want reinstall again
[15:03:37] *** jim80net has joined #smartos
[15:03:55] <oddsignals> never occured to me to run zfs on a ramdisk before :-)
[15:05:45] *** mbraig has joined #smartos
[15:24:40] *** mbraig has quit IRC
[15:24:58] *** mbraig has joined #smartos
[15:25:27] *** mbraig has left #smartos
[15:25:46] *** gemelen has left #smartos
[15:28:11] *** jim80net has quit IRC
[15:28:23] *** kevinykc_ has joined #smartos
[15:28:29] *** jim80net has joined #smartos
[15:30:53] *** kevinykchan has quit IRC
[15:32:33] *** lloydde has joined #smartos
[15:50:06] *** ipalreadytaken has joined #smartos
[15:57:08] *** hadret has quit IRC
[15:59:01] *** xmerlin has quit IRC
[16:03:07] *** ipalreadytaken has quit IRC
[16:05:04] *** neophenix has joined #smartos
[16:05:49] *** ira has quit IRC
[16:08:40] *** mamash has joined #smartos
[16:14:16] *** chorrell has joined #smartos
[16:20:34] *** lloydde has quit IRC
[16:20:58] *** lloydde has joined #smartos
[16:22:42] *** [psy] has joined #smartos
[16:22:50]
<[psy]> https://gist.github.com/psy0rz/6714836 why are all error counters 0? the pool as a whole has checksum errors, and some disks have 'too many errors'. however there are no iostat-errors and checksum errors for indiviual disks?
[16:23:05] <[psy]> dunno if its a smartos/illumos or zfs problem so i'm crossposting :)
[16:25:26] *** lloydde has quit IRC
[16:26:13] *** sebasp is now known as sebasp_
[16:27:00] *** nefilim has joined #smartos
[16:30:35] *** mary5030 has joined #smartos
[16:39:47] <[psy]> thx jesse_
[16:39:53] <jesse_> [psy], or you hit the bug with the dump device flag day
[16:39:57] <[psy]> but thats more a illumos/zfs issue than a smartos issue?
[16:40:11] <[psy]> what?
[16:43:39] <jesse_> trying to find it...
[16:44:16] *** xmerlin has joined #smartos
[16:46:12] <xmerlin> is it possibile to use an already created and empty raidz during a fresh install_
[16:46:14] <xmerlin> ?
[16:46:20] <jesse_> yes
[16:46:38] <jesse_> import it with a name 'zones' before running the install
[16:46:59] <jesse_> when it asks for a disk, give it any one disk (it won't write on it)
[16:47:20] <jesse_> (later on it detects that the zones pool exists already and doesn't create a new pool)
[16:47:39] <jesse_> just make sure you don't have suspectible zfs names on it
[16:48:07] <xmerlin> ah ok ...that's the missing point ...
[16:48:24] <xmerlin> it works ...
[16:48:24] <jesse_> like zones/config zones/cores zones/dump zones/opt zones/swap zones/usbkey zones/var
[16:48:59] <xmerlin> yes ...it's empty
[16:49:37] <jesse_> [psy], if it's the dump flag day problem, you'll need to disable dump, destroy the dump zvol and recreate it
[16:49:59] <[psy]> ah k thx
[16:50:01] <xmerlin> jesse_, thank you
[16:50:17] <jesse_> xmerlin, I've imported old pools as zones
[16:50:30] <[psy]> well i had a recent kernelcrash+dump, so can it be that corrupted it?
[16:50:38] <jesse_> just remember, if the pool is old, you'll need to zpool upgrade it after install if you want imgadm to work=)
[16:51:13] <jesse_> (it gives a totally non-descriptive error if the zones pool is too old for the imported images)
[16:51:19] <xmerlin> ok
[16:52:06] <jesse_> [psy], I think the bug triggers if you had a crash (stuff written to dump) on older smartos
[16:52:13] <jesse_> and then upgraded to newer one
[16:52:38] <Alasdairrr> ah hah
[16:52:52] <jesse_> apparently I've lost my notes on the dump re-create
[16:53:12] <jesse_> apparently it needs volblocksize=128K and checksum=off when you recreate it
[16:53:54] <[psy]> ah k jesse_ thx
[16:53:59] <Alasdairrr> something like "dumpadm -d none ; zfs destroy zones/dump ; zfs create -o volblocksize=128k,checksum=off -V xxG zones/dump ; dumpadm -d /dev/zvol/dsk/zones/dump"
[16:54:04] <[psy]> should the resilver complete though? (it appears the disk was broken)
[16:54:15] <jesse_> 12G was enough for me
[16:54:38] <jesse_> at 4G dumpadm -d said I need 8G, and at 8G it said I need 12G=)
[16:55:01] <jesse_> [psy], stop resilver
[16:55:31] <jesse_> if it hits the affected parts, the pool will break(?)
[16:55:51] <jesse_> I did resilver when I ran across it, but someone said I'll need to stop it
[16:56:04] <jesse_> re-create the dump, reboot and then resilver until it works
[16:56:05] <jesse_> I think
[16:56:39] <[psy]> ah k
[16:56:56] <jesse_> google "ok, dumpadm set the zvol to volblocksize=128K and checksum=off"
[16:57:08] <[psy]> hehe k
[16:57:10] <jesse_> (that's from my backbuffer, it'll probably hit the irc logs)
[16:57:47] <Alasdairrr> sure its not checksum=noparity ?
[16:58:14] <[psy]> but the dump device is only neccesary in case of a crash?
[16:58:16] <Alasdairrr> These are the local properties of our dump device on a fairly fresh smartos install
[16:58:30] <[psy]> ah
[16:59:21] <jesse_> hmmm, noparity is probably correct
[16:59:35] <[psy]> but does it matter for now, if i have no dump device at all?
[16:59:53] <[psy]> ill figure out how to recreate it later
[17:00:11] <jesse_> Alasdairrr, yeah, I think I got that off from older smartos version
[17:00:26] *** potatosalad has quit IRC
[17:00:55] *** paul_lamb has joined #smartos
[17:01:09] <Alasdairrr> I think dumpadm actually sets the zfs properties when it activates it
[17:01:47] *** mamash has left #smartos
[17:02:16] <[psy]> this looks like the dumpflag issue?
[17:02:18] <wesolows> zvol_dumpify sets it. My mail on this to the list would be a useful starting point.
[17:02:28] <wesolows> that's probably a dup of OS-2417
[17:02:37] *** lloydde has joined #smartos
[17:02:49] <jesse_> ok
[17:02:51] <wesolows> that contains a pointer to the relevant code path
[17:03:08] <jesse_> I did a dumpadm -d none on a box, just to see if readding it will set the settings
[17:03:10] <[psy]> you have a url to OS-2417?
[17:03:13] <jesse_> dumpadm: dump device /dev/zvol/dsk/zones/dump is too small to hold a system dump
[17:03:17] <jesse_> dump size 81467297792 bytes, device size 12582912000 bytes
[17:03:23] <jesse_> how does dumpadm decide what's big enough?
[17:03:24] <[psy]> google didnt find it
[17:03:24] <wesolows> so that hopefully someone will go fully characterise the problem. The original people who'd hit this said it no longer happens with current bits, but I couldn't understand why.
[17:03:33] <wesolows> There are also some strange things in that code.
[17:03:41] <[psy]> jesse_ probably has to do with memory size?
[17:03:49] <[psy]> since it has to dump the whole memory
[17:03:52] <wesolows> This really needs someone who is hitting it to sit down and spend a day getting to the bottom of it.
[17:04:12] <jesse_> [psy], same zvol, same box, it was "ok" two seconds before I tried to readd it as a dump device...
[17:04:14] <wesolows> dumpadm doesn't, the thing that does zvol creation does
[17:06:22] <[psy]> jesse_ but you stopped resilvering, destoryed the dump device, rebooted, recreated and resilverd?
[17:06:28] <[psy]> in that order :)
[17:07:08] <jesse_> stop, remove dump, destroy, recreate, add dump, reboot, resilver
[17:07:13] <jesse_> I think
[17:07:59] <jesse_> Alasdairrr, dumpadm -d will set checksum=off
[17:08:20] <Alasdairrr> jesse_: you can see from my paste what happened
[17:08:31] <Alasdairrr> I created a fresh dump zvol, told dumpadm to use it and it autoset those properties
[17:09:00] <Alasdairrr> It set checksum=noparity, compression=off, refreservation=none, dedup=off
[17:09:27] <jesse_> Alasdairrr, sama for me, except checksum=off
[17:09:34] <jesse_> joyent_20130905T185914Z
[17:09:50] <[psy]> we might have had 2 issues, the dumpflag, and an actual broken disc (since there where sata-bus errors in de dmesg)
[17:09:53] <jesse_> actually, that's the test image wesolows gave me
[17:10:02] <jesse_> it might be newer than yours ;)
[17:10:07] <[psy]> and we didnt do a weekly scrub so we probaly didnt trigger the dumpflag issue yet :(
[17:10:23] <Alasdairrr> everycity_20130925T095034Z
[17:10:30] <[psy]> joyent_20130919T215407Z
[17:10:40] <jesse_> ...or you have newer
[17:11:03] *** mbraig has joined #smartos
[17:11:14] <Alasdairrr> ours was built yesterday
[17:11:14] <mbraig> Hi.
[17:11:36] <jperkin> mbraig: I think I used filesystem.raw previously to pass-through /dev/cua entries, I am just trying to find my notes..
[17:11:50] <mbraig> great!
[17:11:53] <mbraig> appreciate it!
[17:12:38] <jperkin> actually, it was via zonecfg, but filesystem.raw might do the same - check the zonecfg manual page, as there are already examples for /dev/cua
[17:12:39] <jesse_> wesolows, It's been in light use, but so far no problems with the new smartarray driver
[17:12:50] <jperkin> (question comes via #joyent, pass-through for OS VMs..)
[17:14:08] <mbraig> jperkin: will do. thanks again!
[17:17:29] <while1eq1> anyone here build erlang on smartos?
[17:17:48] <while1eq1> the latest release
[17:18:58] <opeth__> jperkin: shouldn't that simply be a matter of adding a device and setting a match in zonecfg?
[17:19:27] <jperkin> opeth__: yes
[17:19:31] <jesse_> alcir, I think that smartos-live #159 is different from #259
[17:19:51] <opeth__> jperkin: OK, then my Solaris memories haven't failed me
[17:19:58] <jesse_> alcir, #259 has checksum errors on the dump zfs as the format/checksumming changed between versions
[17:20:01] <jperkin> while1eq1: we build 16.1, you want newer than that?
[17:20:42] <jesse_> alcir, but #159 has real broken disk with read errors, and the read errors are not assigned to any disk (only total number of bytes is shown)
[17:20:48] <while1eq1> jperkin: that should be sufficient
[17:21:38] <while1eq1> I need to see the source for erts/emulator/drivers/common/inet_drv.c
[17:26:06] *** alcir has quit IRC
[17:26:15] *** tonist has quit IRC
[17:26:33] *** jamiealquiza has joined #smartos
[17:27:31] <wesolows> jesse_: glad to hear it, thanks.
[17:27:48] *** potatosalad has joined #smartos
[17:38:01] *** lloydde_ has joined #smartos
[17:39:54] *** mbraig has left #smartos
[17:40:41] *** lloydde has quit IRC
[17:47:12] *** lloydde_ has quit IRC
[17:48:05] *** potatosalad has quit IRC
[17:48:40] *** njm has quit IRC
[17:48:46] *** njm has joined #smartos
[17:52:17] *** nefilim has quit IRC
[18:02:51] *** jim80net has quit IRC
[18:03:37] *** lloydde has joined #smartos
[18:05:21] *** lloydde has quit IRC
[18:05:31] *** jim80net has joined #smartos
[18:05:58] *** lloydde has joined #smartos
[18:05:59] *** lloydde has quit IRC
[18:06:12] *** lloydde has joined #smartos
[18:07:51] *** Guest88642 has joined #smartos
[18:08:25] <Guest88642> hey, can someone tell me how /usbkey/config works when we do PXE netbooting?
[18:10:57] <opeth__> despite its unfortunate name, it's not on the usb key, it's stored on-disk in the zpool 'zones' and mounted atop of whatever you boot off
[18:12:10] *** xinkeT has quit IRC
[18:12:35] *** xinkeT has joined #smartos
[18:12:36] <szaydel> Guest88642: It will work just fine, as long as the machine actually has your zones pool on it.
[18:13:52] <Guest88642> the problem is that /usbkey never gets mounted after reboot but /zones does
[18:14:00] <Guest88642> do you have any ideas how to troubleshoot this?
[18:14:43] <rmustacc> What are the zfs properties related to mounting on the zones/usbkey dataset.
[18:18:02] <szaydel> Guest88642: I had something like this once, and it was because somehow I had mount point set to other than legacy.
[18:19:47] <Guest88642> there is no "usbkey" in zfs at all
[18:20:39] <opeth__> zfs get canmount,mountpoint zones/usbkey
[18:21:34] <rmustacc> Jared_M: So to understand you're using the old dsmanifest to create the image from?
[18:21:44] <Guest88642> @opeth__: zones/usbkey: dataset doesn't exist
[18:21:54] <Jared_M> rmustacc: "old"?
[18:22:15] <opeth__> Guest88642: that's a phenomenon I haven't as of yet encountered
[18:22:35] <opeth__> but it sounds just sane not to mount something that doesn't exist
[18:22:36] <Jared_M> rmustacc: I'm using the manifest at the top of the gist, I added the stuff Merlin said to add
[18:22:45] <Jared_M> and re-installed the image with imgadm
[18:23:04] <Guest88642> at the end of installation (before the reboot) it already complained about missing zones/usbkey
[18:23:40] <opeth__> I'd try another image and check my disks
[18:24:30] <Guest88642> we already tried ISO before and it had the same problem, we have only one disk that was fully wiped before installation and one NIC that is set to dhcp on setup
[18:24:56] <opeth__> not the media per se but the image version was what I meant
[18:25:11] <szaydel> Guest88642: can you do zfs list against the zones pool?
[18:25:17] *** dap has joined #smartos
[18:25:22] <szaydel> Do you see the usbkey dataset?
[18:25:37] <Guest88642> yes, I can list zfs zones pool but usbkey is not there
[18:25:38] <opeth__> szaydel: zfs get claimed it missing
[18:25:58] <szaydel> What did you actually run?
[18:26:11] <rmustacc> Jared_M: What happens if you leave out the image_size from the provision request?
[18:26:36] <Guest88642> where can I get older SmartOS images? I only see newest release on the Download page
[18:26:54] <Jared_M> rmustacc: I left it out before, but I can try again
[18:27:26] <opeth__> szaydel: I advised to do 'zfs get canmount,mountpoint zones/usbkey' and I got the answer it said 'zones/usbkey: dataset doesn't exist'
[18:27:32] <Jared_M> rmustacc: same thing
[18:27:45] <rmustacc> Jared_M: And do you have an @final snapshot for that uuid?
[18:27:57] <szaydel> opeth__: sorry missed that.
[18:28:07] <szaydel> Yeah, that's interesting.
[18:28:14] <Jared_M> rmustacc: no
[18:28:38] <szaydel> Guest88642: Next step, maybe 'zpool list' and 'zfs list' ?
[18:29:10] <Jared_M> rmustacc: the only one I have is zones/29d60ba8-fb31-4055-be06-6428a727f68a@riak-test-centos-clone-prep 0 - 43.6G -
[18:29:19] <rmustacc> Hmm. It seems somethin may have been lost in the process here. I personally have never created my own images but I don't think we're using the dsmanifest format anymore with the switch to imgapi.
[18:29:20] <Jared_M> which is the snapshot name I based the image off of
[18:29:41] <rmustacc> I'd suggest filing a bug and mailing the list so that way the folks who actively work on this part of the system can reach you since they don't lurk in IRC.
[18:30:13] <Guest88642> szaydel: zpool list shows one healthy, online pool and zfs list shows probably everything under /zones except for usbkey, it just doens't exist
[18:30:31] <Jared_M> rmustacc: okay
[18:30:34] <Guest88642> szaydel: should I check older SmartOS release?
[18:30:52] <rmustacc> Jared_M: Sorry. It's just not an area I'm personally familiar with.
[18:30:56] <Jared_M> np
[18:31:00] <szaydel> Guest88642: This is rather interesting. I would say, instead create it manually.
[18:31:11] <rmustacc> Guest88642: If it's not in zfs list, the image you're on won't change things.
[18:31:11] <szaydel> It is a matter of zfs create zones/usbkey
[18:31:18] <rmustacc> Did you have an extent zpool before you set up?
[18:31:54] <Guest88642> No, we started from blank disk
[18:32:59] *** ryancnelson has joined #smartos
[18:33:32] <szaydel> Guest88642: Create it manually and just add a config file there.
[18:33:43] <szaydel> Need to set mount point to `legacy`.
[18:34:06] <rmustacc> This is all the more reason I need to get my replacement setup stuff finished up.
[18:34:13] <Jared_M> rmustacc: is there a debug flag to vmadm that isn't listed?
[18:34:30] <opeth__> as much as that seems possible, I've never had to do it manually
[18:34:46] <szaydel> opeth__: No argument.
[18:34:48] <opeth__> but yeah that'd resemble what the setup script did in here
[18:35:00] <Guest88642> szaydel: I created the zones/subkey and then ran the smartos_.... instalation script, but it recreated the zones again and complained that zones/usbkey doesn't exist
[18:35:10] <Guest88642> szaydel: do you know where I can get older SmartOS release?
[18:35:19] <szaydel> Guest88642: This is not a release issue.
[18:35:42] <szaydel> Guest88642: Once you created zones/usbkey, no further actions are necessary.
[18:35:42] <rmustacc> They're both in manta and the ones before that are on download.joyent.com.
[18:35:51] <rmustacc> We should probably just go move the old ones over.
[18:35:56] <szaydel> Guest88642: Rerunning setup will blow things away again.
[18:36:33] <Guest88642> szaydel: why isn't it created on setup? this is where the config goes in, and the error message is something like "cannot move /tmp)config to zones/usbkey"
[18:36:55] <opeth__> I've never invoked the setup script by any means other than rebooting over a manually wiped disk
[18:37:12] *** bens1 has joined #smartos
[18:37:39] <Guest88642> opeth__: the setup doesn't invoke when we netboot it over a clean disk
[18:37:40] <rmustacc> Jared_M: I think you could somehow use the bunyan probes or look in vmadm's logs.
[18:38:02] <rmustacc> Guest88642: What does your grub menu look like for pxe booting?
[18:38:04] <opeth__> Guest88642: that said I've never tried netbooting, I use USB devices
[18:38:14] *** mamash has joined #smartos
[18:38:49] <rmustacc> Guest88642: If you're pxe booting you can easily screw up the grub configuration.
[18:38:56] <rmustacc> Since you're supplying it and not us.
[18:39:11] <szaydel> Guest88642: Make sure smartos=true is in the grub line.
[18:39:19] <rmustacc> And if you don't specify a few things on it for smartos, it defaults to a different mode where the installer will never run.
[18:39:45] <Guest88642> szaydel: smartos=true was not set there, we copied ipxe configuration from the documentation and it didn't have it
[18:39:46] <opeth__> fair point made
[18:39:56] <rmustacc> Guest88642: What documentation?
[18:40:01] <rmustacc> That's clearly a bug and I'd like to fix it.
[18:41:20] <rmustacc> Guest88642: Ugh, I'm sorry. That's shitty.
[18:41:33] <Guest88642> I am booting with just "-B smartos=true" now
[18:42:18] <Guest88642> btw, is there any way to load boot_archive over HTTP? It takes a lot of time to load it through TFTP, it goes at 4 mbps although we have 1 gbit/s connection
[18:44:08] <rmustacc> I'm sure you can with ipxe.
[18:44:12] <szaydel> Guest88642: with iPXE you should be able to.
[18:46:50] <Jared_M> rmustacc: I found the problem. wesolows sent me a VM.js file to fix the memory bug, that newer vm.js is incompatible with the imgadm I have
[18:47:09] <rmustacc> Jared_M: Ah, yes, that could easily be the case. :/
[18:48:24] <Jared_M> ffffuuuuuu
[18:48:24] *** lloydde has quit IRC
[18:48:29] *** lloydde has joined #smartos
[18:48:35] <Jared_M> I guess I can unmount the newer vm.js, but I bet the memory issue will come back
[18:49:03] <rmustacc> You can always run something to manually evict some data from the arc.
[18:50:04] <szaydel> Guest88642: So are things working as expected now, or still issues?
[18:50:41] *** mamash has left #smartos
[18:50:49] <Jared_M> rmustacc: welp, now it worked haha
[18:50:57] <Jared_M> Successfully created e941bad4-bc8a-4f37-a3e3-8757661d77d0
[18:51:11] <Jared_M> laughing to prevent the tears
[18:52:38] *** lloydde has quit IRC
[18:54:21] *** socketwiz has joined #smartos
[18:58:42] *** jamiealquiza has quit IRC
[19:00:50] <rmustacc> Jared_M: Well, glad it's working now. Sorry for the trouble.
[19:01:45] <Jared_M> np, one to step 3 now, "does it boot?"
[19:01:50] <Jared_M> s/one/on/
[19:05:58] *** socketwiz has quit IRC
[19:09:00] *** kevinykc_ has quit IRC
[19:09:05] *** noahmehl has joined #smartos
[19:09:16] *** lloydde has joined #smartos
[19:09:32] *** tonist has joined #smartos
[19:10:20] <Guest88642> szaydel: I'm booting it right now
[19:11:06] <Guest88642> szaydel: about the HTTP - I think I can boot kernel through HTTP but initrd is grabbed by the kernel, so the kernel would need to handle http path
[19:11:17] <wesolows> that's not correct.
[19:11:26] *** noahmehl_ has quit IRC
[19:11:42] <wesolows> the boot archive and kernel are both loaded into memory by the bootloader
[19:11:55] <wesolows> the kernel is given a piece of metadata that includes the location of the boot archive
[19:12:03] <Guest88642> okay, in that case I will give i a try
[19:12:45] <wesolows> I've used HTTP for both of them; it works fine but is not that much faster than TFTP from what I've seen. Then again, we get MUCH more than 4 Mbps.
[19:13:17] <Guest88642> can you tell me what is your iPXE configuration for HTTP?
[19:13:22] <wesolows> A typical time for us to load a kernel and archive is maybe 15-20s using TFTP.
[19:13:45] <wesolows> I'm not sure what that means. We have an iPXE gate on GH that contains our vendor-specific definitions.
[19:13:49] <wesolows> github.com/joyent/ipxe.
[19:14:04] <wesolows> The GRUB->iPXE loading stuff is in sdcboot.
[19:14:13] <wesolows> it's really trivial.
[19:14:14] *** ryancnelson has quit IRC
[19:17:02] <Guest88642> wesolows: how do you tell iPXE to load the kernel and initrd from HTTP instead of TFTP?
[19:17:37] <Guest88642> I've only used HTTP for initrd for Ubuntu kernels that support HTTP themselves
[19:18:07] <wesolows> it depends how you're creating and propagating the ipxe script.
[19:18:41] <Guest88642> we're chainloading into iPXE script that's on HTTP
[19:18:42] <wesolows> SDC creates it on the DHCP server and then bootstraps it, so if you take that approach you have to change the server code that generates the file.
[19:19:03] <wesolows> If you create a fixed file that's on client boot media, just change the script.
[19:19:48] <wesolows> You're basically asking me how to set up a DHCP+PXE environment, which is not SmartOS specific. Surely this sort of thing is documented; I know that ipxe.org has plenty of documentation.
[19:20:01] <Guest88642> szaydel: after booting SmartOS with "-B smartos=true" we went through installation and rebooted and it booted into installation again
[19:20:23] <szaydel> Guest88642: Did you boot again with "-B smartos=true" ?
[19:20:35] <Guest88642> wesolows: ok, thank you, I'll figure it out
[19:20:36] <szaydel> If not, I am pretty sure that's the problem.
[19:20:40] <Guest88642> szaydel: yes, all the time
[19:20:46] <szaydel> Interesting.
[19:21:20] <wesolows> FWIW, the only reason we don't use HTTP ourselves is that I never got around to implementing the HTTP server part of the DHCP service zone.
[19:21:38] <wesolows> I've tested it in the past though, and I know that our ipxe works with it.
[19:22:20] <szaydel> Guest88642: Can you consistently boot with a USB stick?
[19:22:26]
<wesolows> so you would just change the kernel and module lines to start with http://...
[19:22:30] <szaydel> i.e. can you boot normally, no pie?
[19:22:30] <wesolows> They're just URLs.
[19:22:41] <szaydel> *ipxe.
[19:22:44] <wesolows> You can stick ${server} and so on into the URLs and ipxe will interpret them for you.
[19:23:24] <Guest88642> szaydel: we only tried CD before, don't have any usb key to wipe right now
[19:23:58] <szaydel> Guest88642: Validate that you can in fact boot properly with a USB. That is the most common way that OS is booted by users.
[19:24:15] <szaydel> Look at the grub string when you boot normally.
[19:24:33] <szaydel> Compare the grub string to one when you pxe boot and make sure they are same.
[19:24:41] <szaydel> I suspect something may be different.
[19:36:04] *** jamiealquiza has joined #smartos
[19:36:29] *** bens1 has quit IRC
[19:37:31] *** jaimef has quit IRC
[19:40:52] *** jaimef has joined #smartos
[19:42:44] *** jamiealquiza has quit IRC
[19:59:33] *** jim80net has quit IRC
[20:14:12] *** szaydel has quit IRC
[20:14:50] *** szaydel has joined #smartos
[20:32:34] *** elijah-mbp has quit IRC
[20:38:48] *** ryancnelson has joined #smartos
[20:44:36] *** jim80net has joined #smartos
[20:44:53] *** sebasp_ is now known as sebasp
[20:51:14] *** jim80net has quit IRC
[20:54:14] *** andoriyu has joined #smartos
[21:01:02] *** Teknix has quit IRC
[21:01:26] *** Teknix has joined #smartos
[21:04:13] *** patrickmslattery has joined #smartos
[21:05:40] *** elijah-mbp has joined #smartos
[21:05:42] *** jim80net has joined #smartos
[21:17:28] *** andy_js has quit IRC
[21:19:25] *** andy_js has joined #smartos
[21:23:03] <Guest88642> szaydel: is there any way to run SmartOS without touching the local drives? Ideally to mount the global zones from GlusterFS or Ceph?
[21:23:20] <ryancnelson> no
[21:23:24] <szaydel> Guest88642: I am sure others will say same, No.
[21:23:48] <szaydel> Guest88642: let's rephrase, it is possible, like many things are possible.
[21:23:55] <wesolows> in theory you might be able to use external drives that are direct- or fabric-attached
[21:23:58] <szaydel> It was not the original design.
[21:24:09] <wesolows> but you'll still have to create the pool locally and exclusively.
[21:24:26] <wesolows> and that's not enabled by the OS as shipped; it's contradictory to a deliberate design choice.
[21:24:54] <wesolows> As for using a foreign filesystem as the backing store, that's definitely not possible at all.
[21:24:57] <wesolows> We rely on it being ZFS.
[21:25:12] <szaydel> wesolows: Technically with iSCSI one could just have a lun from somewhere that one basically makes appear as local disk, assuming bios supports ascii on boot, etc.
[21:25:21] <wesolows> You would have to do major surgery to get around that (not to mention adding support to illumos to mount those foreign filesystems)
[21:25:34] <wesolows> szaydel: yes, that's the same as fabric-attached.
[21:25:43] <ryancnelson> ... and "mount the global zones" is gibberish, but i imagine that was just mis-typing
[21:25:47] <szaydel> wesolows: Yeah, I guess close enough.
[21:26:01] <wesolows> None of this is enabled by SmartOS, but it's all open source.
[21:26:12] <wesolows> You can go make DumbOS however you like. :)
[21:26:17] <ryancnelson> it'd stop being smartos if you did that
[21:26:18] <ryancnelson> exactly
[21:26:36] <szaydel> Guest88642: If you are going to get clever, your mileage will truly vary!
[21:27:00] <ryancnelson> other illumos variants have zones, have kvm, and let you go crazy, by-hand
[21:27:30] <Guest88642> okay, thanks
[21:29:48] <leecallen35> Guys (no Guest88642), this is another pretty frequently asked question. Wouldn't you like to copy/paste the above comments into a wiki page, pretty it up a little, and then post the URL when people ask this question?
[21:30:29] <leecallen35> along with, SmartOS clustering/failover?
[21:34:41] <wesolows> We do, I think.
[21:35:30] <wesolows> if not, please feel free to add it to the wiki on smartos.org!
[21:35:53] <wesolows> anyone should be able to edit it.
[21:36:11] <leecallen35> yes but this one should have some subject area expertise
[21:36:45] <patrickmslattery> Hi, I have a vmadm send/receive question.
[21:36:54] <patrickmslattery> For a Joyent branded zone can I do a vmadm send/receive of a running zone without doing a ZFS snapshot first?
[21:37:02] <patrickmslattery> I understand that this wouldn't get application level consistency for a DB type app but it might work OK for a file level app (Samba zone)
[21:37:23] <ryancnelson> no. the snapshot is the thing you're actually sending
[21:37:31] <patrickmslattery> Ah, OK
[21:37:31] *** andy_js has quit IRC
[21:38:20] <ryancnelson> you need a point-in-time "thing" to send, it's not (quite) like dd-ing the disk, which sends the bytes when it gets to them
[21:38:49] <ryancnelson> why wouldn't you want to take a snapshot? they're instantaneous, and basically free
[21:39:02] <ryancnelson> you don't need to shut down the zone
[21:39:30] <patrickmslattery> No reason, I was just curious as to how it worked more than anything else
[21:39:54] <patrickmslattery> The docs are minimal shall we say ;-)
[21:39:57] <ryancnelson> so, yeah, it's a zfs send, which needs a snapshot
[21:40:18] <ryancnelson> there are no docs for vmadm send, because it's not a supported feature yet, as far as i know
[21:40:27] <patrickmslattery> So is there any analog to WMware's vMotion where I can migrate the live VM with its RAM intact?
[21:40:31] <ryancnelson> no
[21:41:44] <ryancnelson> for zones, that's basically impossible (it's not "your" ram, it's shared process space with the entire box, you're just in a container so you can't see other peoples processes)
[21:41:54] *** hij1nx_onaboat is now known as hij1nx_inberlin
[21:42:05] <Guest88642> szaydel: I just booted a SmartOS from flash drive, it still keeps getting into configuration over and over again (despite configuring it of course); there are no error displayed anytime
[21:42:37] <patrickmslattery> OK, I'm curious if there is a vMotion like feature in SDC? How does Joyent keep so many zones in Joyent Cloud running without having to sometimes take an underlying system out for manintenance?
[21:42:40] <ryancnelson> the features you get by being able to see everything from the global zone are essentially incompatible with the "fully encapsulated vm" you need to do vmotion
[21:42:53] <ryancnelson> hardware fails.
[21:43:05] <ryancnelson> we can migrate zones (so can you), but they need to shut down
[21:43:31] <ryancnelson> there's no vmotion thing.
[21:43:50] <patrickmslattery> OK, so just shut them down for a few secs, snapshot, migrate and start back up again in a few secs. Fair enough
[21:43:56] <ryancnelson> ... and:
[21:44:03] <ryancnelson> you can do incremental sends.
[21:44:27] <ryancnelson> so, snapshot, send, snapshot, send-what-changed, do that again, shutdown, snap and send once more, boot.
[21:44:36] <ryancnelson> couple minutes of downtime
[21:44:39] <ryancnelson> maybe
[21:45:05] <patrickmslattery> OK, sounds good
[21:46:02] <leecallen35> ryancnelson: See, that was a better-than-usual answer to an often asked question.
[21:46:17] <ryancnelson> irc is logged. i'm on record :)
[21:46:35] <ryancnelson> i used to tag these conversasions with
[21:46:39] <leecallen35> yes but very hard to search
[21:46:43] <ryancnelson> ### comment: put this in the wiki
[21:46:49] <leecallen35> !
[21:46:59] <ryancnelson> maybe over christmas break, i'll write that stuff up
[21:47:16] <ryancnelson> all my "i should blog this" flashes of inspiration are manta-related anymore
[21:47:24] <leecallen35> I actually am sitting on a couple of questions that I know have been asked before. I am waiting for them to come around again.
[21:47:58] <patrickmslattery> Yes, that would be good to have in the wiki. Speaking of which is the SmartOS wiki public write? Could I create an account on there and add that? (Never tried)
[21:49:41] <ryancnelson> you can create an account.
[21:50:04] <ryancnelson> not "public", you need to be approved, but we do that if you're not a spam-bot
[21:51:09] <patrickmslattery> OK, I'll do that, It would be useful to update some of the pages on there with some of the things I discover as I go along
[21:51:14] *** lloydde has quit IRC
[21:51:29] *** andy_js has joined #smartos
[21:51:49] *** lloydde has joined #smartos
[21:53:00] <patrickmslattery> What I'm looking to do is a system where there is one big physical server hosting a bunch of zones with stuff like SVN, JIRA, MySQL, Git, OpenGrok, maybe Perforce on it and snapshotting those zones on a regular basis to either a smaller physical server or to a VMware VM for DR purposes. If running in a VM then it could be normally run with a minimal RAM allocation and the VMs RAM be increased
[21:53:01] <patrickmslattery> only in a DR scenario.
[21:53:04] <opeth__> and some you hear in here which the sources deem trivial or simply lack the time to record
[21:53:12] <patrickmslattery> Anyone see any issues with that idea?
[21:54:48] <opeth__> I'm snapshotting and replicating my snapshots nightly to an iscsi zpool but if I had another host as a hot-standby I'd do that every fifth minute the same way
[21:55:47] <opeth__> now I just back shit up case it plunges against the fan
[21:55:51] *** lloydde has quit IRC
[21:56:22] <opeth__> every now and then I need to revert
[21:56:44] <leecallen35> patrickslattery: are those all OS zones or are they KVM VMs?
[21:57:08] <leecallen35> oops patrickmslattery
[21:57:36] <ryancnelson> patrickmslattery: that's an interesting use-case.
[21:57:36] <patrickmslattery> All Joyent branded zones so far
[21:58:03] <ryancnelson> i've subbed-in a SDC "headnode" running on my laptop in vmware, in a pinch
[21:58:04] <patrickmslattery> If I need to run anything in Linux or Windows I'd prefer to do that in ESX
[21:58:08] <ryancnelson> an extreme pinch
[21:58:29] *** andy_js has quit IRC
[21:59:23] <leecallen35> I have done what you are describing, in a lab. And I have played on & off with a variation of it...
[22:00:08] <leecallen35> where the backup target is a full fledged SmartOS, and some of the VMs are on system A and they are synced to system B, and vice versa
[22:00:22] *** julianduque has joined #smartos
[22:00:26] <leecallen35> that is, some of the VMs run on system B and are backed up to system A
[22:00:43] <patrickmslattery> Ultimatly I don't have have much control over the ESX side of things but am the admin for SVN, JIRA etc and need to make sure they work well. I do have good storage and ESX experience but am not allowed to do that here. This design gets me control over the hardware too and gets the apps running on ZFS. ext and NTFS are just Mickey Mouse filesystems.
[22:00:57] <opeth__> should work if you ask me, I've migrated my systems the same way earlier to the host they are running on now
[22:01:03] <leecallen35> so normally the workload is split, but if either system fails, the relevant VMs can be started on the other system
[22:01:07] <opeth__> I just no longer have the original one
[22:01:46] <jperkin> patrickmslattery: no, that sounds ideal for SmartOS
[22:01:55] <patrickmslattery> You can see the basic idea here
[22:02:10] <leecallen35> last I heard vmadm send/receive was not yet supported, and had some problems. are those problems just for KVM VMs?
[22:02:43] <patrickmslattery> Actually that link is bad, let me put it in github
[22:03:10] *** andy_js has joined #smartos
[22:04:39] *** Alek has quit IRC
[22:08:05] *** Alek has joined #smartos
[22:09:36] <patrickmslattery> I do understand that vmadm send/receive are not yet supported and are as yet undocumented.
[22:10:16] <jperkin> ===> Install binary package of ghc-7.6.3
[22:10:17] <jperkin> sweet
[22:10:39] <Guest88642> opeth__: I tried booting with USB drive and it still goes over and over again into setup, any ideas?
[22:11:15] <patrickmslattery> jperkin: Yes, SmartOS does seem to be the ideal OS for this setup. I was originally looking at OpenIndiana but the more I played with SmartOS the better suited it seemed to this idea
[22:11:39] <opeth__> Guest88642: are you sure the disk is OK? if it's healthy, are you sure it was properly wiped/
[22:11:42] <opeth__> ?
[22:12:59] <Meths> jperkin: Nice.
[22:13:15] <opeth__> so at last the haskell effort bears fruit
[22:13:22] <opeth__> not like I spoke haskell but still
[22:14:44] <patrickmslattery> First page is current, second and third are the future plan.
[22:14:51] *** andy_js has quit IRC
[22:14:51] <Meths> So have people got bootstrap tarballs that work on multiple illumos distributions now?
[22:14:57] *** leecallen has joined #smartos
[22:15:09] <jperkin> am working on that now
[22:16:18] *** leecallen35 has quit IRC
[22:16:30] <opeth__> jperkin: you gave me major momentum with pkgsrc for which I'm really thankful, now I'm migrating to properly packaged stack
[22:17:15] <opeth__> next I'll dissect an SMF-enabled package to find out how that could be added to ones that lack it
[22:17:24] <Guest88642> opeth__: I will wipe it again with DBAN and check again just to make sure
[22:17:25] <opeth__> likely not black magic either
[22:17:30] <Guest88642> opeth__: thanks for all the help
[22:17:40] <opeth__> Guest88642: give it the DoD type of love
[22:17:49] <Guest88642> opeth__: okay ;P)
[22:18:07] *** Guest88642 has quit IRC
[22:18:17] <jperkin> opeth__: in trunk (and soon-to-be 2013Q3) it's pretty easy, just create pkgdir/files/smf/manifest.xml, and if you have any method scripts, create pkgdir/files/smf/script.sh and add 'SMF_METHODS=script' in Makefile
[22:18:36] <opeth__> wow, that really sounds great
[22:18:54] <opeth__> ...and easy indeed
[22:18:59] <jperkin> security/clamav has the best example, as it has a couple of scripts
[22:19:09] <opeth__> I'll take a look, thanks
[22:19:13] <opeth__> but I guess I could do it even now
[22:19:14] *** andy_js has joined #smartos
[22:19:18] <opeth__> based on what you just said
[22:19:31] <jperkin> or www/apache24 if you just want a simple manifest example
[22:19:36] <opeth__> I've written manifests and scripts already but installing them manually is tedious and pointless when it can be packaged
[22:19:48] <opeth__> perfect
[22:22:21] <opeth__> jperkin: thanks again, I know why I keep coming back to ask you about stuff ;]
[22:25:02] *** nikolam has joined #smartos
[22:26:45] *** andy_js has quit IRC
[22:29:50] *** lloydde has joined #smartos
[22:33:12] *** lloydde has quit IRC
[22:33:36] *** lloydde has joined #smartos
[22:35:23] *** socketwiz has joined #smartos
[22:38:14] <emsii> got a new Z87 chipset gigabyte motherboard with LGA1150 Core i5 Haswell processor. seems that SmartOS 20130919T215407Z does not recognize the nic(s)? Intel I217-V (driver not attached), Qualcomm Atheros AR8161 (driver not attached), Centrino Wireless-N2230 (driver not attached)
[22:38:35] <emsii> says prtconf -d
[22:39:58] <rmustacc> emsii: The I217-V support is going back shortly.
[22:40:04] <rmustacc> I can't say much about the AR8161
[22:40:12] <rmustacc> And the wireless I don't know of much looking at.
[22:41:31] <emsii> rmustacc: ok. I can make do with I217-V only. AR8161 would be great so I could use the other port on the motherboard as well. Any ETA/guesstimate for the I217-V?
[22:41:52] <rmustacc> emsii: I have a sample build that's a little bit older that you can use in the interim for it.
[22:42:02] <rmustacc> I'm getting that back to illumos in the next day or so.
[22:42:09] <rmustacc> So it should be in the next smartos release next Thursday.
[22:43:08] <emsii> excellent. I can get started with the sample build. From where could I download it?
[22:43:29] <rmustacc> Let me get you a url.
[22:43:45] <emsii> tx
[22:43:49] <rmustacc> Do you want an iso, tgz, or usb image?
[22:43:58] <emsii> usb would be best
[22:45:29] <emsii> thanks!
[22:55:12] *** tonist has quit IRC
[23:06:22] *** paul_lamb has quit IRC
[23:06:33] <oddsignals> jperkin: nice!
[23:07:06] <oddsignals> jperkin: now to work on 64-bit :-)
[23:07:28] <jperkin> well, need to get the bootstrap working first, and fixing up the rpaths
[23:08:17] *** chorrell has quit IRC
[23:08:50] *** nikolam has quit IRC
[23:10:50] *** paul_lamb has joined #smartos
[23:13:29] *** paul_lamb has quit IRC
[23:16:35] <oddsignals> jperkin: let me know if there's anything I can help with
[23:19:20] *** nikolam has joined #smartos
[23:25:14] *** andy_js has joined #smartos
[23:41:25] *** andy_js has quit IRC
[23:50:55] *** andy_js has joined #smartos
[23:51:08] *** socketwiz has quit IRC
[23:55:54] *** andy_js has quit IRC