Switch to DuckDuckGo Search
   September 11, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >

Toggle Join/Part | bottom
[00:02:19] *** andy_js <andy_js!~andy@94.12.192.123> has quit IRC (Quit: andy_js)
[00:07:04] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[00:08:51] *** mecrobio <mecrobio!~mecrobio@6.red-88-4-17.dynamicip.rima-tde.net> has quit IRC (Remote host closed the connection)
[00:09:57] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[00:12:34] <gitomat> [illumos-gate] 11661 provide C.UTF-8 locale -- Yuri Pankov <yuri.pankov at nexenta dot com>
[00:26:06] *** gwr <gwr!~gwr@151.203.114.175> has quit IRC (Quit: This computer has gone to sleep)
[00:28:36] <LeftWing> Ooh, I am excited for this new locale
[00:35:26] <jbk> things you don't hear every day? :P
[00:36:12] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has joined #illumos
[00:40:16] *** jrick <jrick!~jrick@unaffiliated/jrick> has quit IRC (Ping timeout: 246 seconds)
[00:53:02] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[00:58:01] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[01:00:34] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[01:06:16] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[01:17:41] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 276 seconds)
[01:18:03] *** Teknix <Teknix!~pds@172.58.43.122> has joined #illumos
[01:56:36] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[02:03:14] *** wiedi_ <wiedi_!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has joined #illumos
[02:05:30] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 246 seconds)
[02:09:28] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 244 seconds)
[02:11:04] *** gwr <gwr!~gwr@151.203.114.175> has joined #illumos
[02:11:20] <yuripv> richlowe: https://www.illumos.org/rb/r/2293/
[02:11:37] <yuripv> (while my mail is stuck)
[02:17:26] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has joined #illumos
[02:17:30] <yuripv> (also, looks hacky, but seems to be the easiest way compared to symlink madness)
[02:36:43] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 245 seconds)
[03:13:37] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[03:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[03:20:08] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[03:25:31] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
[03:53:45] *** gwr <gwr!~gwr@151.203.114.175> has quit IRC (Quit: Leaving)
[03:56:29] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Read error: Connection reset by peer)
[04:00:25] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:15:00] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[04:22:17] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 276 seconds)
[05:11:00] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[05:41:00] *** Tsesarevich <Tsesarevich!Tsesarevic@fluxbuntu/founder/joejaxx> has quit IRC (Ping timeout: 252 seconds)
[05:42:50] *** Guest9420 <Guest9420!sid250374@gateway/web/irccloud.com/x-xqudbqlrrpuwpwfk> has quit IRC (Ping timeout: 252 seconds)
[05:45:33] *** Guest9420 <Guest9420!sid250374@gateway/web/irccloud.com/x-mvoootursjzraurp> has joined #illumos
[05:45:56] *** Tsesarevich <Tsesarevich!Tsesarevic@fluxbuntu/founder/joejaxx> has joined #illumos
[07:04:32] <gitomat> [illumos-gate] 11606 process erroneously shows up as from 1970 -- Jason King <jason.king at joyent dot com>
[07:06:18] <Reinhilde> time travelling!
[07:06:44] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 276 seconds)
[07:09:28] <jbk> we're just that good :P
[07:09:44] <jbk> but really just reporting zombies correctly
[07:11:59] <Reinhilde> jperkin: ?
[07:12:03] <Reinhilde> jbk: *
[07:12:08] <Reinhilde> jperkin: apologies :)
[07:12:35] <jbk> svcs -p service wouldn't identify zombies processes as <defunct>
[07:12:53] <jbk> it'd how the pid, 1970 as the start time (aka 0) and nothing for the process name
[07:12:59] <jbk> if it encountered one
[07:41:33] *** mnowak_ <mnowak_!~mnowak_@94.142.238.232> has quit IRC (Quit: Leaving)
[07:44:13] *** mnowak_ <mnowak_!~mnowak_@94.142.238.232> has joined #illumos
[07:56:36] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome)
[08:00:12] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[08:01:17] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has joined #illumos
[08:14:45] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-64.net.upcbroadband.cz> has quit IRC (Ping timeout: 244 seconds)
[08:36:07] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has joined #illumos
[08:39:58] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has quit IRC (Remote host closed the connection)
[08:40:19] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has joined #illumos
[08:42:29] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has left #illumos
[08:51:09] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Ping timeout: 246 seconds)
[08:53:15] *** alanc <alanc!~alanc@129.157.69.38> has quit IRC (Remote host closed the connection)
[08:53:44] *** alanc <alanc!~alanc@129.157.69.38> has joined #illumos
[09:12:13] *** p7mo <p7mo!~pmo@ricasa01.informatik.uni-bremen.de> has joined #illumos
[09:24:59] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[09:36:29] <p7mo> Hi, I updated a machine today from OI hipster illumos-01d6bbace7 July 2019 to newest version and now I'm facing a screen after BIOS telling "BIOS drive C: is disk0" to "BIOS drive Z: is disk23" and nothing happens, does anyone know how to fix that? It's no EFI install. Its a system with multiple LSI SAS9300-8i and one 8e.
[09:39:47] *** andy_js <andy_js!~andy@94.12.192.123> has joined #illumos
[09:40:15] *** merzo <merzo!~merzo@218-62-133-95.pool.ukrtel.net> has joined #illumos
[09:46:45] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[09:52:57] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[09:58:21] *** merzo <merzo!~merzo@218-62-133-95.pool.ukrtel.net> has quit IRC (Ping timeout: 246 seconds)
[10:07:33] *** yuripv <yuripv!~yuripv@217.146.82.144> has quit IRC (Ping timeout: 245 seconds)
[10:10:13] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[10:15:23] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[10:15:47] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[10:27:44] *** man_u <man_u!~manu@manu2.gandi.net> has joined #illumos
[10:34:00] *** tsoome <tsoome!~tsoome@229-110-157-37.dyn.estpak.ee> has joined #illumos
[10:42:45] *** yuripv <yuripv!~yuripv@217.146.82.144> has joined #illumos
[10:47:37] *** tsoome <tsoome!~tsoome@229-110-157-37.dyn.estpak.ee> has quit IRC (Quit: tsoome)
[11:14:02] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has quit IRC (Quit: aszeszo)
[11:18:51] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 246 seconds)
[11:19:07] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[11:38:14] *** _Joes_ <_Joes_!~BH23@2a00:23c4:22ae:3801:d4b6:bc6f:59b5:15e2> has joined #illumos
[11:41:02] *** yuripv <yuripv!~yuripv@217.146.82.144> has quit IRC (Ping timeout: 276 seconds)
[12:05:28] *** merzo <merzo!~merzo@185.39.197.205> has joined #illumos
[12:14:47] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[12:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[12:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[12:26:10] *** _Joes_ <_Joes_!~BH23@2a00:23c4:22ae:3801:d4b6:bc6f:59b5:15e2> has quit IRC (Ping timeout: 252 seconds)
[12:38:18] *** vila <vila!~vila@2a01:e35:2e63:5f40:7016:4209:2762:de32> has quit IRC (Remote host closed the connection)
[12:54:51] *** vila <vila!~vila@2a01:e35:2e63:5f40:ec51:d4c:8983:3af2> has joined #illumos
[13:14:55] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[13:23:27] *** amrmesh <amrmesh!~Thunderbi@190.2.145.106> has joined #illumos
[13:25:27] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Ping timeout: 245 seconds)
[13:25:27] *** amrmesh is now known as amrfrsh
[13:25:45] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:26:08] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:31:20] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:31:37] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:36:40] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:37:08] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:47:24] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:48:53] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:54:06] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:55:07] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:55:40] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:56:22] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:57:17] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:57:20] <andy_js> I think we broke support for building with GCC 4.4.4
[13:58:10] <jlevon> ugh, where?
[13:58:12] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:59:55] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:00:28] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:01:03] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:01:43] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:02:04] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[14:02:28] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[14:11:55] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has joined #illumos
[14:13:25] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[14:22:58] *** wiedi_ <wiedi_!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 245 seconds)
[14:26:23] *** wiedi <wiedi!~wiedi@p4FF49391.dip0.t-ipconnect.de> has joined #illumos
[14:27:36] * andyf is interested too
[14:32:32] *** yuripv <yuripv!~yuripv@217.146.82.144> has joined #illumos
[14:34:17] <andy_js> It’s blowing up in usr/src/cmd/mdb
[14:34:19] <andy_js> ../pcplusmp.c:1: error: code model kernel does not support PIC mode
[14:34:20] <andy_js> ../pcplusmp.c:1: error: code model 'kernel' not supported in the 64 bit mode
[14:34:36] <andy_js> I have a “fix” but it might be totally bogus.
[14:35:15] <andy_js> I swear - every time I try to build on Omni I run into something.
[14:36:35] <andyf> I build on omni every day, although I haven't built stock gate for about a week
[14:37:16] <andyf> I just kicked one off though..
[14:41:41] <andy_js> I’ll submit my “fix” to reviewboard shortly.
[14:42:26] <andy_js> andyf: Do you ever install stock illumos-gate on Omni - or just build it?
[14:42:58] <andyf> I onu to it if I need to test a change
[14:50:08] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has quit IRC (Quit: jellydonut)
[14:50:17] <andyf> Does anyone have any idea how, in the kernel, I can get from a TLI socket stream back to the vnode that owns it?
[14:50:23] <andyf> e.g. https://paste.ec/paste/JvFxamMD#20PCcsZJBavkALvKnTInY85IFynKMz5Ld402gR1-l5Z
[14:51:33] <andyf> (or even any pointers on why vnode->v_stream->sd_vnode != vnode
[14:54:58] *** jellydonut <jellydonut!~quassel@s91904421.blix.com> has joined #illumos
[14:56:50] <andyf> andy_js, the non-DEBUG build just finished ok..
[14:57:47] <andy_js> The long-running issue I was having was losing the ability to do builds after installing stock illumos-gate.
[14:58:13] <andyf> I don't think I've ever tried that
[14:58:41] <andyf> some userland bits will probably fail due to missing kernel things
[15:00:02] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Ping timeout: 245 seconds)
[15:11:40] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[15:13:11] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has quit IRC (Quit: leaving)
[15:14:06] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[15:14:29] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[15:14:29] <KungFuJesus> p7mo: I had the same issue, the resolution I had was to go to the BIOS for the LSI card and tell the "Boot Support" feature to be OS only on all controllers
[15:15:07] <KungFuJesus> I suspect it was an issue where the controller(s) possibly reordered drives or something, though you'd think the boot loader would use the GPT label rather than anything else to identify the disk
[15:16:10] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has joined #illumos
[15:17:17] <KungFuJesus> p7mo: do you also see an issue where ocassionally at boot you get a "PHY update failed" message over and over and need to reboot? My 9305 controllers do that with SAS disks behind an expander
[15:24:46] <KungFuJesus> arekinath: So do you think you'll be writing a pamd anytime soon?
[15:26:02] <andyf> andy_js, my build of gate with a 4.4.4 shadow worked fine
[15:26:43] <KungFuJesus> even so, if your data stash with pam_set_data is per pid, it's the same problem, isn't it? Unless you made it some global keystore
[15:30:12] <KungFuJesus> arekinath: haha, this is the solution the portable pam_krb5 uses for the _same_ exact problem: https://github.com/rra/pam-krb5/blob/master/setcred.c#L264
[15:33:40] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[15:34:45] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[15:35:23] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[15:36:13] *** lgtaube <lgtaube!~lgt@91.109.28.129> has quit IRC (Ping timeout: 258 seconds)
[15:42:45] <p7mo> KungFuJesus: I have an old installation ~2016 using MBR partition/slice, not full disks for the rpool; rpool is only on ssds directly connected to the motherboard, so I think the controllers are not the real problem or am I wrong? I can try that out. Booted now with a live dvd selecting the BE and booting it from the live DVD loader. I did never see anything like the mentioned issue with "PHY
[15:42:46] <p7mo> update failed" on my machines.
[15:44:08] <KungFuJesus> I definitely saw that same exact issue after an update (the bootloader). I'm not sure what the direct cause is, but I definitely mitigated it by only presented motherboard controller volumes (in particular, this was an NVMe drive)
[15:44:20] <KungFuJesus> presenting*
[15:45:24] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[15:46:20] <KungFuJesus> I do have an installation on the full disk, with GPT for my rpool, so it's probably not an issue with that
[15:48:30] <KungFuJesus> In particular my boot loader issue occurred from BE from the second to last week in august to the last week in August. It was a very narrow range of commits, and none of which seemed to be bootloader related, so it's likely a bug that's actually been there for a while
[15:49:37] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Ping timeout: 245 seconds)
[15:51:30] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[15:55:44] <arekinath> KungFuJesus: my original thought was have a door open per pam handle, and allow multiple pids to talk to it
[15:56:18] <KungFuJesus> would that work, though? Doesn't forking a process and then access the pam library again basically reininitialize libpam?
[15:56:20] <arekinath> all the pam plugins would run on the daemon side in one child process for that handle, basically
[15:57:18] <KungFuJesus> accessing*
[15:57:51] <KungFuJesus> you'd have to somehow access that pam handle in between pam_sm_authenticate and pam_sm_setcred calls, right?
[15:59:27] <KungFuJesus> the problem is, OpenSSH does fork(); pam_sm_authenticate(); exit(); pam_sm_setcred()
[15:59:49] <KungFuJesus> pamh is only valid in that child pid, it doesn't survive into the parent
[15:59:51] <arekinath> yes, and that would be fine if the pam_start() was before the fork
[16:00:43] <arekinath> the pam_start() is before the fork, right?
[16:00:45] <KungFuJesus> the onload library behavior is occurring twice, though
[16:00:49] <p7mo> Okay, wow thanks! That really worked, I removed bootable flag from all exept one controller in the LSI BIOS (one has to be set bootable it says) and voila booted up succesfully. So I suspect the number and/or a possible reordering of disks as the problem in this case somehow like you said.
[16:01:07] <KungFuJesus> you can see where it's actually parsing the config file again in the parent
[16:01:08] <arekinath> KungFuJesus: in the pamd world the library wouldn't have an onload or any global state
[16:01:18] <arekinath> it'd be a thin shim that makes door calls
[16:01:26] <arekinath> and the same door would be in the parent and the child
[16:01:33] <arekinath> all real state would be in the daemon
[16:02:03] <arekinath> the PAM plugins would never be loaded into the process that calls pam_sm_authenticate() etc
[16:02:11] <KungFuJesus> I would think the onload behavior was happening in pam_start(), but I could be wrong. If that's the case, then OpenSSH is accessing PAM only in children
[16:02:33] <KungFuJesus> or at least, only in children until the setcred call, anyway
[16:03:57] <KungFuJesus> p7mo: We're probably mitigating an actual bug in the bootloader, I just don't know a good way to report it that's actually useful. I wouldn't think the controller would obnoxiously reorder disks after presenting them to the BIOS
[16:05:41] <KungFuJesus> arekinath: if you load a library from the parent, and then fork, does any of the shared library's context leak into the child, or is it reloaded entirely with the new address space?
[16:05:53] <KungFuJesus> I thought it was the latter
[16:06:40] <arekinath> KungFuJesus: in general, or in the specific case of libpam?
[16:06:48] <KungFuJesus> in general
[16:06:49] <arekinath> in general all state is copied to the child, it's just COW like any other process memory
[16:07:00] <arekinath> more specifically, libraries can register atfork handlers and stuff like that to vary that behaviour
[16:07:43] <KungFuJesus> ah I see - I usually deal with shared libraries anymore with the pthread API, so I forget some of the fork semantics
[16:07:51] <arekinath> because sometimes what libraries do with their global state is not really safe against multiple children doing things with their own versions of it
[16:08:07] <arekinath> when it involves external resources and open files and so on
[16:08:10] <KungFuJesus> so some pam handle can be duplicated and used as a key to access the same context
[16:08:19] <arekinath> yes
[16:38:47] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 245 seconds)
[16:41:02] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[16:43:01] <arekinath> KungFuJesus: so, in my reading of the openssh code the pam_start() only happens in the monitor per pam_setcred... doing a bit of experimentation with dtrace seems to support my theory, too
[16:43:17] <arekinath> *once per pam_setcred
[16:43:38] <KungFuJesus> ah, so we're back to the same problem, hah
[16:43:54] <arekinath> no, that's the exact flow that a pamd would help with
[16:44:12] <arekinath> it's creating one pam handle and using it for pam_authenticate() then for pam_setcred()
[16:44:15] <arekinath> but those two steps happen in different pids
[16:44:47] <KungFuJesus> oh I see, I thought you were saying that it only happened in a forked pid, but setcred does seem to be happening in the parent
[16:45:04] <arekinath> yeah. the pam_start() happens in the parent too from what I can see
[16:45:23] <arekinath> and then is shared with the child
[16:45:23] <arekinath> which makes sense
[16:45:51] <KungFuJesus> I wasn't sure exactly what the "monitor" mechanism was. That's usually something handled by a service rather than once off library invocation
[16:46:38] <KungFuJesus> ahhh but wait, pam_sm_authenticate is invoked in the child pid before the parent does pam_sm_setcred
[16:47:01] <arekinath> yes
[16:47:33] <KungFuJesus> so is sshpam_init_ctx invoked befor pam_sm_authenticate?
[16:47:36] <KungFuJesus> before*
[16:48:38] <arekinath> yeah
[16:48:42] <arekinath> well, it has to be, otherwise there's no pam handle :P
[16:49:05] <arekinath> but it is called in the parent, by input_userauth_request doing PRIVSEP(start_pam(ssh))
[16:49:15] <arekinath> once for each input method as it starts processing it
[16:49:20] <arekinath> *auth method
[16:51:11] <arekinath> anyway I need sleep, sorry
[16:51:22] <arekinath> I still think pamd's got legs as an idea
[16:51:32] <arekinath> there's a bunch of shitty details to work out, but...
[16:52:13] <arekinath> just getting independence from the bitness of the binary using libpam and getting PRIV_PAM would be worth it imho
[16:52:36] <arekinath> (so e.g. 64-bit PAM plugins can be used by 32-bit libpam because the daemon is there to run them for you)
[16:53:08] <KungFuJesus> ok, I'll hold off on hobbling together a patch that will reinitialize all that PAM context again, then. For now our users can get by with GSSAPI based authentication
[16:54:52] <gitomat> [illumos-gate] 11649 loader.efi: some systems do not translate scan code 0x8 to backspace -- Toomas Soome <tsoome at me dot com>
[16:54:54] <rmustacc> Now I really wish I was already in a pamd world.
[16:56:23] <andyf> finally :) https://paste.ec/paste/mdqgbnXc#QWyXbHWP2lOC4Q0OKlUu-yNvGD1y6QtqnvQ/VMN9l/P
[16:56:31] <andyf> It's a bit of a lash up, but it appears to work
[16:57:51] <rmustacc> andyf: Cool!
[16:58:08] <rmustacc> You figured out the TLI bits?
[16:58:42] <andyf> Mostly.. I still need to check through more code and look at reference counting etc.
[16:59:04] <rmustacc> Gotcha.
[16:59:16] <andyf> TLI sockets are just... let's say interesting
[16:59:53] <rmustacc> You're being rather kind.
[17:00:33] <andyf> It might have been easier to rework rpcbind/syslogd/inetd to use BSD sockets tbh.
[17:00:36] <rmustacc> Being able to push modules is useful (we even redid it with socket filters for BSD sockets0, but...
[17:00:50] <rmustacc> Haha
[17:01:04] <rmustacc> Well, still, good to be complete, even if we should still maybe do that.
[17:01:35] <KungFuJesus> What a weird relic to inherit from AT&T
[17:02:00] <rmustacc> I'm not sure if it's the weirdest or not.
[17:02:21] <andyf> Well, we all know that TCP/IP is going to be deprecated by something OSI...
[17:02:21] <KungFuJesus> I'm guessing this is one of the things requiring the ON build to carry around those handful of closed source binaries?
[17:02:24] <rmustacc> On the other hand, libdlpi is one of the nicer libraries and interfaces for doing arbitrary ethertype work.
[17:02:32] <rmustacc> KungFuJesus: Nope
[17:02:54] <KungFuJesus> oh, that big of XPG4 is open?
[17:02:56] <KungFuJesus> bit*
[17:02:59] <rmustacc> Generally that's device support that no one's gotten around to a new binary.
[17:03:04] <rmustacc> Erm, to rewriting.
[17:03:14] <rmustacc> Almost nothing in closed bins is usually related to that stuff.
[17:03:17] <andyf> rmustacc, yes, I used it with the CDP implementation that was imported into OmniOS - nice interface
[17:03:21] <rmustacc> It's mostly drivers and a few random commands.
[17:03:37] <rmustacc> andyf: Yeah, I used it for a proto lldpd.
[17:03:50] <rmustacc> Maybe I should get back to that some day.
[17:03:52] *** jrick <jrick!~jrick@unaffiliated/jrick> has joined #illumos
[17:04:07] <igork> rmustacc: does lldp works for you with links in aggr?
[17:04:09] <andyf> It's just priorities.. openlldp is not to bad
[17:04:14] <andyf> *too
[17:04:31] <rmustacc> igork: Nope
[17:04:51] <rmustacc> andyf: Yeah, big thing I wanted was better system integration. So I could more easily call it from topo, etc.
[17:05:05] <rmustacc> I had an idea for how to fix the aggr issue, but again, not something I really ever got around to.
[17:05:12] <rmustacc> I'd rather just not use aggrs in the future if I could!
[17:05:34] <KungFuJesus> Just curious, is Illumos' IPOIB stack any less buggy than Linux or FreeBSD's? In my experience, apart from running iperf over them, they were buggy as sin, and seemed to be mainly maintained by mellanox
[17:08:53] <rmustacc> I haven't seen anyone touch IB related stuff in illumos-gate for a while.
[17:09:18] <rmustacc> Though maybe some o the NAS appliance vendor based on illumos have changes so you can actually support a recent IB card, etc.
[17:11:06] <KungFuJesus> my experience with the ConnectX-2 based cards was pretty miserable. I could push ~20gbps in IPoIB, but as soon as NFS traffic was routed over it with a TCP transport, weird latency bugs would crop up (FreeBSD to Linux traffic, that is)
[17:11:25] <KungFuJesus> requests would take seconds to finish, probably waiting for a buffer to be filled or something
[17:11:27] <tsoome> I did touch IB stuff, but only for small bugs:)
[17:11:37] <tsoome> and those wont count:D
[17:12:24] <KungFuJesus> it'd probaby help if FreeBSD's NFS service actually supported RDMA, I suppose (the primary transport people actually test IB against when not directly using the verbs API)
[17:13:45] *** merzo <merzo!~merzo@185.39.197.205> has quit IRC (Ping timeout: 246 seconds)
[17:19:26] <andy_js> Here’s my fix for GCC 4: https://www.illumos.org/rb/r/2294/
[17:20:27] *** wiedi <wiedi!~wiedi@p4FF49391.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)
[17:20:37] <andy_js> I don’t know if this is right, but I do think there’s something highly fishy about using STAND_FLAGS here.
[17:20:47] <andy_js> It says it’s a kernel module but I don’t think that’s so.
[17:25:50] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has joined #illumos
[17:33:16] <andyf> andy_js, do you know which gate commit broke this?
[17:33:37] <andy_js> I don’t. I’ve had a look but can’t figure it out.
[17:33:55] *** dopplergange <dopplergange!~dop@213.183.57.27> has quit IRC (Ping timeout: 258 seconds)
[17:34:03] <andyf> My gate build was 3 commits behind HEAD and worked ok... but those three don't look related
[17:34:18] <rmustacc> Also, shouldn't we not be passing C_BIGPICFLAGS to a kernel thing?
[17:34:25] <rmustacc> Rather than redefining the stand flags manually?
[17:34:34] <andy_js> Right. That’s the other thing.
[17:34:44] <andy_js> And what lead me to believe this wasn’t really a kernel module.
[17:34:54] <rmustacc> Well, there are two different things that are built.
[17:34:58] <andy_js> That and the fact it resides in usr/src/cmd
[17:35:05] <rmustacc> No, that's not the case.
[17:35:16] <rmustacc> All, the kmdb versions need to be built with the stand flags.
[17:35:39] <rmustacc> There's what kmdb calls the dmod and the kmod.
[17:35:45] <rmustacc> The former is used by mdb -k.
[17:35:53] <rmustacc> The latter is used by kmdb.
[17:36:07] <rmustacc> The former needs to be built PIC as its a userland shared object.
[17:36:16] <rmustacc> The latter needs to be built like a kernel module.
[17:41:02] <andy_js> There’s the problem then.
[17:41:22] <andy_js> You can’t built the userspace component with the stand flags and with PIC.
[17:42:02] <rmustacc> We shouldn't be. They generally are supposed to be two differen targets.
[17:42:33] <rmustacc> *different
[17:42:47] <andy_js> And that means my fix is wrong.
[17:43:45] <rmustacc> Let me kick off a rebuild in cmd/mdb to see if I can see the same thing.
[17:43:49] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Remote host closed the connection)
[17:44:08] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[17:45:25] <andy_js> This is sort of looking like a make bug.
[17:45:57] <rmustacc> Certainly possible. Though if we're both using the stock-gate seems a bit surprising.
[17:46:04] <rmustacc> Though I'm sure it'll be obvious when understood.
[17:46:39] <KungFuJesus> hah, it's almost never the build toolchain that has the bug
[17:46:56] <KungFuJesus> though - I did once independently discover a gdb bug that would corrupt the stack
[17:47:01] <KungFuJesus> that was a fun debugging nightmare
[17:47:32] <andy_js> dmake has a history of weird bugs and illumos-gate has a history of depending on them.
[17:47:54] <rmustacc> KungFuJesus: Certainly wouldn't rule out the build toolchain. It has a number of issues.
[17:48:42] <KungFuJesus> https://sourceware.org/bugzilla/show_bug.cgi?id=21222 <-- ahhh, there's my old nemesis
[17:49:08] <KungFuJesus> GNU of course did nothing about it until they independently and inadvertitently fixed it and found my bug report to tell me about it
[17:53:31] <rmustacc> When you've got a lot of folks all volunteering, it doesn't always mean that someone will be able to step in and fix your issue, unfortunately.
[17:54:07] <KungFuJesus> oh I'm aware, it's just your debugger should be able to not corrupt stack context when using VEX encoded instructions
[17:54:14] <andy_js> They also like to pull a Trump and deny that there ever was a problem.
[17:54:19] <rmustacc> I agree, it's a bad bug!
[17:54:20] <KungFuJesus> and it kind of irritates me that the RedHat employees didn't seem to care about the issue
[17:54:42] <KungFuJesus> the whole "I don't have a machine that has AVX yet" excuse was just bullshit
[17:55:13] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[17:55:25] <KungFuJesus> Meanwhile, this bug was present for at least 4-5 years
[18:06:05] <KungFuJesus> I suppose it'd be righteous indignation if I were paying for RedHat support. And to be fair, Keith Seitz did apology for the lack of activity
[18:06:57] <KungFuJesus> apologize*
[18:08:31] <jbk> my experience with paid RedHat support was less than impressive
[18:09:13] <jbk> system w/ fc attached disks would constantly flip the filesystems to read only mode, require a reboot + 2+hour fsck
[18:10:08] <jbk> systems would randomly freeze (HP servers, turns out the version of their custom drivers required to get any sort of sensor info had a deadlock in an interrupt handler)
[18:10:25] <jbk> basically shrugged their shoulders at the whole thing
[18:11:00] <KungFuJesus> Sort of weird considering HP validates their servers against RedHat and sell them as a supported solution
[18:16:45] *** yuripv <yuripv!~yuripv@217.146.82.144> has quit IRC (Read error: Connection reset by peer)
[18:22:43] *** yuripv <yuripv!~yuripv@217.146.82.144> has joined #illumos
[18:26:27] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 240 seconds)
[18:26:50] *** yuripv <yuripv!~yuripv@217.146.82.144> has quit IRC (Ping timeout: 240 seconds)
[18:32:38] *** Teknix <Teknix!~pds@172.58.43.122> has quit IRC (Ping timeout: 268 seconds)
[18:33:40] *** lgtaube <lgtaube!~lgt@91.109.28.129> has joined #illumos
[18:35:54] <KungFuJesus> As much as I hate Redhat/Gnome, I gotta say the builtin "enterprise login" feature post Fedora install is pretty slick. Though I'm about 8 minutes in with using it, I'm sure I'm going to find reasons to hate it soon enough
[18:46:46] <KungFuJesus> yep, already found something I'm not liking: https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/80
[18:49:22] <rmustacc> No matter what software you use, you're probably going to find something you don't like.
[18:50:02] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Ping timeout: 276 seconds)
[18:50:41] *** Teknix <Teknix!~pds@172.58.43.122> has joined #illumos
[18:52:47] <Smithx10> c
[18:54:54] *** Teknix <Teknix!~pds@172.58.43.122> has quit IRC (Ping timeout: 246 seconds)
[19:30:59] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[19:31:42] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[19:43:28] *** leah2 <leah2!~leah@vuxu.org> has quit IRC (Remote host closed the connection)
[19:47:03] *** leah2 <leah2!~leah@vuxu.org> has joined #illumos
[19:49:08] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[19:57:12] *** Teknix <Teknix!~pds@172.58.43.122> has joined #illumos
[19:57:33] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[19:57:58] *** leah2 <leah2!~leah@vuxu.org> has quit IRC (Remote host closed the connection)
[19:58:15] *** yuripv <yuripv!~yuripv@217.146.82.144> has joined #illumos
[19:58:48] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[20:01:30] *** leah2 <leah2!~leah@vuxu.org> has joined #illumos
[20:09:04] *** wl_ <wl_!~wl_@2605:6000:1b0c:4124::87c> has quit IRC (Ping timeout: 264 seconds)
[20:11:25] *** wl_ <wl_!~wl_@cpe-108-167-3-102.neb.res.rr.com> has joined #illumos
[20:14:43] *** wl- <wl-!~wl_@2605:6000:1b0c:4124::87c> has joined #illumos
[20:14:46] *** wl_ <wl_!~wl_@cpe-108-167-3-102.neb.res.rr.com> has quit IRC (Read error: Connection reset by peer)
[20:24:06] *** wl_ <wl_!~wl_@2605:6000:1b0c:4124::87c> has joined #illumos
[20:24:38] *** wl- <wl-!~wl_@2605:6000:1b0c:4124::87c> has quit IRC (Read error: Connection reset by peer)
[20:27:43] *** wl- <wl-!~wl_@cpe-108-167-3-102.neb.res.rr.com> has joined #illumos
[20:27:56] *** wl_ <wl_!~wl_@2605:6000:1b0c:4124::87c> has quit IRC (Read error: Connection reset by peer)
[21:12:58] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 246 seconds)
[21:35:52] *** jrick <jrick!~jrick@unaffiliated/jrick> has quit IRC (Ping timeout: 245 seconds)
[21:50:36] <richlowe> yuripv: I don't really see using symlinks as a problem, but I also don't mind. Are there other aliases we may want?
[21:50:47] <richlowe> andy_js: do you want help debugging your build?
[21:51:13] *** despair86 <despair86!~despair@185.10.68.109> has joined #illumos
[21:51:18] <despair86> hi
[21:53:06] <yuripv> richlowe: symlinks are too much hassle
[21:53:36] <yuripv> as for the other aliases, no idea, not using linux here (except for one debian instance to compare locale stuff against)
[21:55:59] <richlowe> trying to remember how to linux, and then I'll look
[21:56:59] <richlowe> yuripv: armscii8, cp1251, eucjp, euckr, euctw, gb18030, gbk, iso885915, koi8r, utf8, UTF-8, utf8@valencia
[21:58:03] *** jrick <jrick!~jrick@unaffiliated/jrick> has joined #illumos
[21:58:42] <richlowe> so probably should handle the full range based on that?
[21:59:34] <richlowe> iso8859-foo -> iso8859foo, UTF-8 -> utf8, gb18030 if it's case sensitive,
[21:59:39] <richlowe> don't know if we have koi or euc
[21:59:46] <richlowe> or cp
[22:01:14] <richlowe> that's from apt-file search for /usr/lib/locale on fairly old debian
[22:06:27] <andy_js> richlowe: I might do. Let me first see if the failure is still reproducible.
[22:08:41] <andy_js> All of a sudden it’s not reproducible.
[22:15:07] <andy_js> The only thing I did was install a builc that was produced with that patch.
[22:15:24] <andy_js> Nothing else about my environment has changed.
[22:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[22:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[22:21:44] <yuripv> we only have UTF-8, ISO8859-*, KOI8-R, and GB18030; it *might* be easier done without a table lookup then
[22:23:21] *** bahamas10 <bahamas10!~dave@cpe-72-231-187-25.nycap.res.rr.com> has joined #illumos
[22:23:56] <yuripv> however we have support in libc for a lot more of weird encodings
[22:24:23] <richlowe> I'm not 100% clear on what we can iconv, and what we have for locales
[22:24:40] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 244 seconds)
[22:24:46] <richlowe> I'm just advocating covering the full range with the aliases, if we're going to
[22:24:50] <richlowe> rather than just the two that annoy me
[22:24:54] <richlowe> though obviously they're the most important! :)
[22:25:09] <yuripv> the only important one is UTF-8 :)
[22:43:08] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Quit: leaving)
[22:45:03] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[22:50:57] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Remote host closed the connection)
[22:52:09] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[22:52:22] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Client Quit)
[22:54:04] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[22:54:57] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Client Quit)
[22:56:38] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[22:58:30] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Client Quit)
[22:58:38] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has joined #illumos
[22:59:17] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[22:59:54] *** Teknix <Teknix!~pds@172.58.43.122> has quit IRC (Ping timeout: 246 seconds)
[22:59:54] *** despair86 <despair86!~despair@185.10.68.109> has quit IRC (Read error: Connection reset by peer)
[23:00:01] *** despair86 <despair86!~despair@185.10.68.109> has joined #illumos
[23:01:52] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 244 seconds)
[23:02:12] *** Teknix <Teknix!~pds@172.58.47.43> has joined #illumos
[23:03:32] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has quit IRC (Ping timeout: 276 seconds)
[23:11:14] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-64.net.upcbroadband.cz> has joined #illumos
[23:24:48] *** despair86 <despair86!~despair@185.10.68.109> has quit IRC (Quit: Leaving)
[23:26:02] <richlowe> updated the ancient debian, and the only change is rk1048
[23:26:04] <richlowe> whatever that is.
[23:27:02] <yuripv> BTW, I only see iso885915 there, no iso88591
[23:27:13] <yuripv> did they drop it completely?
[23:27:16] <richlowe> I don't know
[23:27:18] <wilbury> kazakhstanian encoding is rk1048
[23:27:31] <richlowe> I just know what I was having issues with assumed the iso88591 name
[23:27:50] <wilbury> rk1048 a.k.a. kz1048
[23:34:02] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[23:39:29] <yuripv> ugh, /usr/bin/svcprop -p config_params/global_pattern coreadm -> \"\"
[23:39:43] <yuripv> and now coreadm service doesn't start, after running os-tests :)
[23:40:02] <yuripv> jlevon: ^^^
[23:42:46] <yuripv> I guess global_pattern was empty before that, i.e. ""
[23:43:05] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
[23:46:35] <copec> Has anyone ever had a problem with vnic's mac's not being passed through a virtualbox nic set to promiscuous mode on a windows host?
[23:46:54] <jbk> hmm
[23:47:08] <jbk> i never upstreamed OS-6362 (don't know how much that'd help)
[23:47:46] <copec> Would that be in regards to my question jbk?
[23:48:04] <jbk> no related to yuripv's issue
[23:48:09] <jbk> somewhat
[23:48:09] *** andy_js <andy_js!~andy@94.12.192.123> has quit IRC (Quit: andy_js)
[23:48:18] <jbk> you can specify a bad value to coreadm -g
[23:48:26] <copec> ah, ty
[23:48:29] <jbk> which hoses the service (and requires using svccfg to manually fix teh value)
[23:49:16] <jbk> it just toggled my memory of that
[23:49:31] <yuripv> yeah, you can't use coreadm to fix the value as service isn't online
[23:50:06] <yuripv> but I think that's just a small fallout from 11530
[23:51:28] <jbk> yeah, i just remember spending a surprising amount of time on the issue
[23:51:38] <jbk> and settling on the least worst fix
[23:51:54] <jbk> but had to look at hte commit ti remember the details
[23:55:58] <jbk> i should go ahead and fix that
top

   September 11, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >