02:27:32 who has recently worked in the smartos ipxe? https://github.com/TritonDataCenter/ipxe currently I'm trying to boot using netboot but I'm stuck at https://github.com/TritonDataCenter/ipxe/blob/936715b9a27487407428bd5b09af2c0bb3960408/src/arch/x86/image/multiboot2.c#L813 but I don't have a clue on how to continue 02:28:12 When you say you're stuck can you clarify what you mean? 02:31:00 rmustacc yes, I mean that the last thing I see on the debug build is that "MULTIBOOT2 exit_boot_services" is printed then the call to get_efi_mmap never returns and then after a while the process exists to the efi shell again 02:32:56 So, exiting boot services is a way of telling firmware it's done and the primary ownership of the system is the OS. 02:39:12 rmustacc oh, yes, but it never actually exits boot services it seems stuck, let me get the last debug messages I have 02:39:57 So is it stuck getting the memory map or in the call to exit boot services? 02:50:40 rmustacc https://ctrl.vi/i/u1epRh9Ip, yes I added debug messages once is stuck in the memory map call 02:52:02 rmustacc I'm sorry, yes I see that is stuck in the GetMemoryMap call, according to debug messages I added sometime ago when boot_services calls get_efi_mmap 07:12:56 neirac GetMemoryMap should either return memory map or tell the buffer is not large enough and returns the expected buffer size. Now the issue might be the expected size is not exact as memoty map can grow during the GetMemoryMap call itself... so, we should round the buffer size up. So, if the system is stuck in GetMemoryMap, it hints that we did call it with some buffer space, and the GetMemoryMap may be running 07:12:56 ast buffer end and thus corrupting whatever memory there is and somehow this will eventually trigger exit from ipxe and we end up in UEFI shell. 07:14:49 neirac to work around this issue, we call GetMemoryMap initially with NULL buffer to get suggested buffer size, and we allocate buffer with some number of pages larger than hinted. 11:35:35 OK so ran out of space again, but my zvol is 100G but illumos only sees 10G -_- thats unfortunately 11:35:41 Well, 3rd time is the charm, I hope 13:34:06 So this is the only fine I need to copy to the new be right, assuming everything is build from the same commit as what I'm currently running? ./proto/root_i386-nd/usr/kernel/drv/amd64/viona 13:39:00 tsoome thanks I'll try to check that but I could not find the GetMemoryMap implementation in the ipxe code 14:11:44 Here goes nothing, lets reboot 14:16:36 Ok, I'm booted into the BE and nothing exploded yet 14:17:06 Now to figure out how the properly format the tunable name 14:27:33 OK with a vq of 128 I hit the issue almost imediatly after booting the VM 14:27:34 Good good 14:38:46 OMG It works, well at least viona_tx_copy_needed now returns 1 instead of 0 after setting the tunable and rebooting 14:38:57 And somehow i am not left holding multiple pieces 14:39:05 OK, the change is super super tiny 14:39:06 But still 14:39:45 Also TIL fbt probes only show up in dtrace -l after the first viona instances is created 14:40:48 Now the big test, does pushing large amounts of data over it with forced copying prevent it from locking up or not 14:41:43 I may have squeeze the vqsize down to 8 *whistles* 14:44:54 Looks to be holding up, there is a performance impact, which is to be expected I guess 14:45:10 NFS now tops out around 437 MB/s 14:45:58 Which is still very very good IMHO, before I was seeing closer to 7xx MB/s range 14:46:15 At first glance nfsstat also has less random super high latancy spikes, which is unexpected but interesting 14:49:39 jclulow: do I file a sub-ticket for adding the force copy tunable to viona ? Seems mine tiny patch works, or do I use 13463 ? 14:50:11 I think adding notes on what I did and how I tested to 13463 would just clutter that one up, given this doesn't fix the actual problem and is just a bandaid. 14:58:47 any suggestions for debugging my other network problem? :) 15:00:39 also, is there a way to change the queue size via vmadm now? 15:00:43 or how to play with it? 15:07:59 Not sure you can via vmadm 15:13:42 Has anyone had much luck running the zfs testsuite recently? 15:14:45 I'm getting lots of errors that look like it's assuming bash (local: not found) and path problems - digest: not found / uuidgen: not found 15:16:12 I only got 91% success, which is a lot lower than I'm used to 15:25:55 there seems like there's a couple of new failures.. 15:27:06 for the zfs stats i ran the test suite against an unmodified illumos-gate (since it had been a while), then a build w/ the change applied.. 15:27:20 and most of the failures were ones that have been on my list (I've filed tickets for all of those) 15:27:37 but it did seem like there was 1-2 new ones (even after re-running) 15:41:56 @andyf --> I now run them under the umbrella of `smartos-test` every release week. 15:42:52 Last run: Out of 1292 lines stating PASS/FAIL/SKIP, I get 1070 PASS, 75 FAIL, and 147 SKIP. *which* ZFS test(s) fails does vary from release to release, suggestiong transient failures. 15:43:17 The %-ages do seem high, however. I've NOT taken deep-dives yet into why. 15:51:11 apparently you're supposed to be able to set ZFS_ABORT to force zpool commands to create a core when they exit, but I think that either is broken or the test isn't properly detecting things -- that seems to be at least a few of the failures 15:52:14 others seem like some test don't always properly clean up, and some later test (not always the immediate one afterwards) then fails because of that (but is fine when run on their own) 15:52:52 unfortunately, such things are not a priority at $JOB, so it's hard to find time to dig into them 16:05:54 jbk - I also had hanging tests, so it's likely I'm doing something daft, although I've run these frequently in the past 16:09:26 I think it's the first time I've used two NVMe and one vioblk disks for the test temporary ones though 16:09:35 I shall try going back to vioblk for all! 16:34:24 [illumos-gate] 15194 libdladm: tautological-pointer-compare -- Toomas Soome 16:35:21 tsoome is it bad when ipxe is loading the boot_archive saying that the image has no multiboot2 header? 16:37:04 neirac: You're using the Triton iPXE booter? 16:37:29 danmcd I'm using netboot.smartos.org/smartos.ipxe 16:38:05 That's a config file. 16:38:09 dancmd I mean I compiled the one that's on the triton repo to load it 16:38:27 Which ipxe *binary* are you using... ahh, you typed the answer I wanted. 16:38:37 So you compiled it yourself. 16:39:08 (which shouldn't be a problem FTR). 16:39:43 danmcd that's right I added debug to see where it's stuck, but my last test exit_bootservices returned EFI_SUCCESS so after that the vm get's back to the efi shell 16:40:33 danmcd on the ipxe shell I'm just typing dhcp then chain https://netboot.smartos.org/smartos.ipxe. then choose text instead of a tty 16:44:13 danmcd I was wrong get_efi_mmap returne ok, I'll activate more debug on boot_services 17:52:09 sjorge: Not a sub ticket but just a new ticket, and you can add the original bug as a related issue 18:26:54 OK then i did it correctly 19:50:01 So who is off to FOSDEM? 19:51:01 do we have a booth? 20:42:39 neirac boot_archive will not have MB header, kernel does. and MB bootloaders expect kernel first.. 20:56:34 so really dumb question.. shouldn't 'chmod 2750 dir' result in '-r-xr-s--' ? it's stripping the setgid bit when i try it so i feel like i've forgotten something i should know 20:57:20 https://pastebin.com/BXXCH9xD 20:57:31 chmod g+s does work however 21:10:51 Odd indeed. 21:11:43 Yeah. 2 in that first octal digit (even or-ed with other bits) seems to be a nop. 21:12:06 `chmod 6750 kebe` gives me: 21:12:07 drwsr-x--- 2 root root 512 Dec 20 21:11 kebe 21:14:20 Ahh. 21:15:17 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/chmod/common.c#L489-L510 21:15:21 @jbk ^^^ 21:16:29 Now WHY that's there is a mystery to me, and I'm sure would make a good history story. 21:17:47 The behavior IS documented in the chmod(1) man page too. 21:19:01 ok.. so i'm not crazy or forgetting something silly.. 21:20:31 You're not crazy. You HAVE piqued my curiousity as to WHY this behavior is there. I don't see it on MacOS, e.g. 21:20:48 My gut says SysV-ism, but :shrug: 21:21:38 yeah.. we have someone that has an app that for whatever reason wants 2750 on an NFS share, and chmod wasn't working 21:21:58 Linux (ubuntu16 in an LX zone) chmod also behaves like MacOS. 21:22:09 There's gotta be some OG SysV thing I'm missing. 21:22:34 oh... there is a note at the very bottom of chmod(1)... that contradicts the stuff earlier about it 21:23:41 well kinda... 21:24:12 it could maybe make the distinction of 'when present' vs 'when you try to set it' 21:24:25 Eeesh, example 5 is broken. 22:04:12 jbk/danmcd: if I recall correctly, this is a holdover from SysV using that bit for mandatory locking 22:04:22 Thank you! 22:10:19 though I may be remembering wrong, since the comment Don Cragun left when closing https://illumos.org/opensolaris/bugdb/bug.html#!4067561 says: 22:10:20 → OpenSolaris issue 4067561: chmod 2xxx fails on directories (Closed) 22:10:35 Doing what is being suggested here would not make the system more 22:10:35 user friendly. It would create chaos as regular users accidentally 22:10:35 change the way group IDs are set when subdirectories are created. 22:10:35 The current method of only changing the GID inheritance mode when 22:10:35 done by symbolic mode changes was done as a result of a user interface 22:10:35 design study. It may seem strange to users who are not used to 22:10:37 systems that allow the user to specify whether subdirectories are to be 22:10:39 created with the group ID of the creating process or the group ID of 22:10:41 the containing directory. Switching the behavior to allow absolute 22:10:43 mode changes (as well as symbolic mode changes) to set and clear the 22:10:45 set-GID bit on directories should only be done if using the set-GID 22:10:47 bit on a directory to determine which group-ID assignment to use on 22:10:49 subdirectories is removed from the system at the same time. Since 22:10:51 there has been no suggestion that this capability should be removed 22:10:53 from Solaris systems, I am closing this bug again as Not A Defect. 22:11:50 well, that certainly sounds like don 22:11:56 ...but since Linux & BSD allowed it, we ignored Don's advice and changed it anyway in 12.0^H^H^H^H^H11.4 22:12:40 as part of our adding GNU-compatible options to /usr/bin/chown 22:16:43 yeah, I don't follow any individual part of don's reasoning (fitting...), so I would do it too 22:16:59 "it's so confusing we don't let you do it when you use chmod in the greybeard octal way nobody does by accident, only the easy way" 22:22:31 I'll happily code-review or RTI-approve such a fix, richlowe 22:24:50 though I've also just noticed our man page still claims "Absolute changes do not work for the set-group-ID bit of a directory. 22:24:50 You must use g+s or g-s." 22:34:16 That was the text I saw in ours. 22:36:07 I always just thought I was missing something since I "grew up" on Linux 23:04:55 I don't understand that argument 23:05:04 but then I spend half my life on BSD 23:16:00 SysV was always odd. ALWAYS. 23:16:33 and that was even before it become LarryOS :)