00:08:12 <qtc`> I got it working, `gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 da0` and /boot in a `freebsd-ufs` filesystem
00:12:24 <moon-child> I am having difficulty setting up an nfs server.  I have started rpcbind, mountd, and nfsd; and my /etc/exports contains one line: '/d 192.168.1.0/24'
00:12:56 <moon-child> on the server, if I run rpcinfo -p, I get 'rpcinfo: can't contact portmapper: RPC: Success'.  But if I run rpcinfo -p server from another host, I get https://0x0.st/HN9D.txt
00:14:19 <moon-child> showmount -e localhost from the server gives https://0x0.st/HN9d.txt.  showmount -e server from another host gives 'showmount: Cannot retrieve info from host: rowan: RPC: Program not registered'
00:14:57 <moon-child> what am I doing wrong?
00:24:14 <moon-child> hmmm.  Now I am getting 'nfsd: rpcb_set tcp failed: Cannot allocate memory'
00:35:43 <rtprio> not sure that's the right line for exports boss
00:36:42 <rtprio> the man page says you need -network:  "/d -network 192.168.1/24"
00:38:31 <rtprio> my showmount -e localhost looks way different
00:38:47 <rtprio> moon-child: is /d it's own filesystem or a subdirectory?
00:41:16 <moon-child> lmao it's a 32-bit overflow
00:42:09 <moon-child> https://cgit.freebsd.org/src/tree/lib/libc/rpc/clnt_vc.c#n198
00:42:10 <VimDiesel> Title: clnt_vc.c « rpc « libc « lib - src - FreeBSD source tree
00:43:37 <moon-child> admittedly it is somewhat unreasonable of me to have 500m fds.  But.
00:44:01 <moon-child> rtprio: man page has an example that looks like that (without explicit -network)
00:45:56 <rtprio> which one is that?
00:49:52 <moon-child> oh, nevermind, you are right
00:50:03 <rtprio> did you put these entries in rc.conf so they'll start on boot?
00:50:17 <moon-child> yes
00:50:20 <moon-child> the overflow problem still seems to be the main one, though
00:50:48 <rtprio> do you have 500m files on /d ?
00:51:13 <moon-child> no; I have an fd cap of 500m
00:52:09 <rtprio> can you nfs mount your it locally?
01:02:43 <moon-child> curiouser and curiouser.  I dropped the fd limit and rebooted, and now I can mount the directory without errors, except that it's empty
01:02:47 <moon-child> on both the server and client
01:06:15 <rtprio> 00:38 < rtprio> moon-child: is /d it's own filesystem or a subdirectory?
01:06:26 <moon-child> its own fs
03:35:00 <_xor> Hahah
03:35:40 * _xor didn't realize that the "abomination before God" quote regards fetchmail was originally from a FreeBSD mailing list reply in 2001
03:55:38 <qtc`> question regarding fstab, on linux I would use partition UUIDs to ensure that fstab points to the correct destination since a device address (da0) can never be guaranteed to be the same.
03:56:46 <qtc`> I dont see a mention of UUIDs in the fstab(5) man or the handbook (Chapter 19. Storage)
03:57:31 <qtc`> Does freebsd use UUIDs, or am i supposed to use device addresses such as /dev/da0 ?
04:05:20 <sphex> qtc`: You can use /dev/gpt GPT labels or /dev/gptid GPT UUIDs. The installer disables GTP UUID device files if you use ZFS. Not sure why exactly. Seems like it's better to use only one or the other so that vdevs only have one possible name. Also there's /dev/ufsid for UFS filesystem IDs. Probably best to use this for UFS filesystems. `dumpfs -l` to get the UFSID path of a FS.
04:11:00 <qtc`> I have a ZFS on root install with a UFS /boot
04:11:22 <qtc`> I guess I could convert that /boot to zfs as well and bypass this issue
04:12:49 <sphex> I just use GPT labels personally.
04:16:08 <qtc`> GPT labels, I only have efiboot0 and gptboot0 in /dev/gpt/
04:22:32 <parv> I use GPT labels. Never tried usinf UUID
04:23:09 <parv> I use GPT labels. Never tried using UUID (is this duplicate? Did not see earlier)
04:25:06 <parv> is this on?
04:48:48 <qtc`> ah `glabel` is a thing, thanks parv
05:16:12 <RhodiumToad> qtc`: yo, was asleep
05:17:26 <RhodiumToad> sphex: zfs isn't quite down with the fact that the same data may show up on many different /dev paths, it assumes it can just taste everything as it shows up
05:18:01 <RhodiumToad> sphex: so the more paths you have for a device, the more confused things can get
05:30:55 <qtc`> I think I'm "happy" with my setup for now; USB with EFI/Legacy Support, a labeled UFS for /boot.
05:31:33 <RhodiumToad> you ended up using gpt for the boot usb?
05:31:38 <qtc`> The only thing i dont like is my fstab, it feels a bit hacky since i mount the ufs to /boot-efi, then mount /boot to /boot-efi/boot via nullfs
05:32:23 <RhodiumToad> you can probably do better by putting the /boot stuff in the root dir of the ufs boot volume and having a boot -> . symlink
05:32:35 <qtc`> yes, `gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 da0` and a ufs partition for /boot
05:32:43 <qtc`> so I can boot now
05:34:13 <elgrande> is there a parameter for 'mv' to allow 'mv . .', 'mv .. .' and 'mv . ..'?
05:34:26 <RhodiumToad> why would you want to?
05:35:37 <qtc`> . /boot/boot is taken, so i wont be able to move everything a level up and symlink /boot to .
05:35:38 <elgrande> in order to verify inodes (first case) re-sort directories (latter cases)
05:35:55 <RhodiumToad> oh yeah
05:36:26 <elgrande> you want me to take a look at it?
05:36:31 <RhodiumToad> no
05:36:38 <elgrande> pfff
05:36:39 <RhodiumToad> the "oh yeah" was for qtc`
05:36:45 <elgrande> oic
05:37:12 <elgrande> but he has the same problem
05:38:11 <RhodiumToad> qtc`: another option would be to mount the boot volume on / with -o union but that might get messy
05:41:22 <RhodiumToad> qtc`: third option would be to move the /boot/boot file somewhere else, it's not needed for booting (and in any event it's just boot1+boot2 concatenated)
05:42:13 <RhodiumToad> elgrande: how would "mv . ." "verify inodes" as you put it?
05:44:17 <qtc`> I was going to go with -o union, but renaming /boot/boot would probably be a better solution. feels the least messy of my options
05:44:42 <RhodiumToad> the problem with -o union is that having more than one / entry in fstab may well confuse things
05:45:24 <qtc`> oh I dont have a / in fstab, I have zfs on root
05:45:39 <qtc`> but i dont think that will help union
05:46:33 <RhodiumToad> if it were down to me, I'd move all of /boot/{boot,boot0,boot0sio,boot1,boot2,cdboot,gptboot,isoboot,gptzfsboot,mbr,pmbr} to somewhere like /boot/bootcode
05:47:13 <RhodiumToad> all of those are files that get copied to special places rather than things actually loaded from files in /boot
05:48:13 <qtc`> Thanks, I really like that suggestion
05:48:30 <RhodiumToad> however, you'll obviously have to be careful about doing make installworld if you ever build from source
05:48:38 <RhodiumToad> since that'll try and put /boot/boot back
05:49:49 <qtc`> good to know, at lest is a good option for OPNsense and TrueNAS since I dont think they installworld
05:50:35 <qtc`> is installworld only for upgrades? I don't remember what its used for.
05:53:12 <RhodiumToad> installworld is only if you're compiling from source code
05:54:00 <qtc`> yeh, but practically speaking i only remember using it for upgrading to newer versions of freebsd
05:54:20 <qtc`> I don't remember it being possible to do so via pkg
05:54:55 <RhodiumToad> freebsd-update can in theory upgrade to new versions, though I don't use it myself
05:55:16 <qtc`> I'll make a note
07:01:24 <RhodiumToad> hmm. gpart always seems to use v1 uuids when creating gpt partitions
07:01:40 <RhodiumToad> would be nice to have a way to use v1mc or v4 instead.
07:22:04 <elgrande> any idea where to look at when receiving 'ping: UDP connect: No route to host'? lookup with adns port ('adnshost') works fine.
07:22:44 <RhodiumToad> what ping command are you using?
07:29:47 <meena> RhodiumToad: im pretty, and sure, we've got code to generate v4 uuids
07:31:27 <RhodiumToad> elgrande: perhaps you meant to use ping6 ?
07:32:07 <meena> (that's deprecated in favour of ping -6)
07:32:46 <elgrande> RhodiumToad: same error with ping6
07:38:28 <RhodiumToad> it looks like ping6 does a hostname lookup even for numeric addresses
07:39:11 <RhodiumToad> what is in your /etc/resolv.conf and /etc/nsswitch.conf
07:42:05 <RhodiumToad> meena: having code to generate them is one thing, but gpart doesn't use it
07:43:53 <elgrande> RhodiumToad: https://bsd.to/awGo
07:43:54 <VimDiesel> Title: dpaste/awGo (Plain Text)
07:44:31 <RhodiumToad> is 168.63.129.16 reachable?
07:45:53 <RhodiumToad> is 168.63.129.16 reachable?
07:47:00 <RhodiumToad> elgrande: please stop disconnecting every 10 seconds
07:48:14 <elgrande> I am on iOS in a psychiatry, sorry. iPhone 14 Pro Max cannot handle 2 apps.
07:49:03 <elgrande> ping still is waiting or whatever. can i conf wait time?
07:49:34 <RhodiumToad> waiting for what?
07:49:42 <RhodiumToad> use control-C to abort it
07:50:30 <elgrande> 203 packets transmitted, 100% loss
07:51:58 <elgrande> resolvconf seems to regen resolv.conf as you probably have seen.
07:55:41 <elgrande> freebsd.org A INET 96.47.72.84 freebsd.org A INET6 2610:1c1:1:606c::50:15
07:55:52 <elgrande> so resolving still works
07:56:35 <RhodiumToad> resolving how?
07:56:51 <elgrande> adnshost freebsd.org
07:57:06 <RhodiumToad> that's not what I asked though
07:57:12 <RhodiumToad> is 168.63.129.16 reachable?
07:57:18 <elgrande> no
07:57:30 <RhodiumToad> well then
07:58:21 <RhodiumToad> whatever IP is in /etc/resolv.conf is where basically every program will send DNS queries to.
07:58:46 <RhodiumToad> if it doesn't work as a resolver, then basically no network commands will be able to look up hostnames
07:59:13 <elgrande> there is no ipv6 in /etc/resolv.conf anymore has been overwritten
07:59:45 <RhodiumToad> that doesn't matter, a resolver reached via ipv4 can be used to look up ipv6 addresses
08:00:11 <RhodiumToad> resolv.conf is usually overwritten as a result of, for example, DHCP lookups
08:00:45 <RhodiumToad> (you can control this via resolvconf.conf)
08:01:08 <RhodiumToad> (yes, the configuration file has its own meta-configuration file)
08:03:37 <RhodiumToad> meena: fwiw, I don't see any code to generate v4 or v1mc uuids (there's provision for using a random multicast address in the kernel, but that's not what v1mc is)
08:04:14 <meena> oh right, gpart operates at kernel level
08:04:36 <RhodiumToad> I don't see any code to do those in userland either :-)
08:05:05 <RhodiumToad> v4 is pretty trivial since it's just a matter of 122 random bits and 6 fixed ones
08:05:28 <meena> don't we have libuuid in base
08:05:43 <RhodiumToad> v1mc can be done by generating a v1 uuid and then stomping over the node address, with 2 fixed bits and 46 random ones
08:06:22 <RhodiumToad> there's some uuid functions in libc/uuid but they only generate v1, via the kernel uuidgen() call
08:53:39 <vkarlsen> Hehe, this is interesting, when I set zsh's PROMPT to "%n@%m %~%# " my terminal spews a large amount of whitespace and then the whole thing freezes. I have to "power cycle" the vm, it's completely frozen
08:54:08 <vkarlsen> I should mention that this is zsh 3.0.6 running on 3.3-RELEASE
08:54:18 <RhodiumToad> 3.3!
08:54:38 <RhodiumToad> 3.x was a notoriously bad time
08:55:02 <vkarlsen> It may lack some capabilities we have come to take for granted
08:58:38 <RhodiumToad> actually, back then I recall that odd numbers were more like "current" in that stuff broke a lot, and even numbers were supposed to be more stable
08:59:04 <RhodiumToad> up until 6.x, that is
08:59:35 <RhodiumToad> (2.1.x and 2.2.x were good, 3.x bad, 4.x very good, 5.x pretty bad, 6.x and onwards very good)
09:00:22 <RhodiumToad> I don't think I ever ran 3.x
09:01:06 <vkarlsen> I couldn't get 2.x to work in a vbox vm, it panicked near the end of the installer with a disk slice operation
09:25:05 * elgrande is at creating ipv6 azure console setup script
10:00:31 <elgrande> Servus debdrup?
10:48:18 <V_PauAmma_V> Hic non sunt servi.
12:33:31 <meena> is it possible to crashdump onto/from encrypted swap?
12:34:48 <RhodiumToad> not AFAIK.
12:35:24 <RhodiumToad> you could maybe dump onto the unencrypted device, but that would kind of defeat the point
12:45:50 <meena> heheh yeah
12:47:47 <RhodiumToad> the basic problem with dumping is that the system is mostly frozen; threading and geom infrastructure don't work
12:48:29 <RhodiumToad> dumping onto, say, gpart is done by having gpart compute the raw disk offset/length of the dumpdev in advance
12:49:13 <RhodiumToad> that said, it looks like it is possible to do encrypted dumps
12:49:57 <RhodiumToad> I don't think they can go onto geli devices though
12:50:01 <Demosthenex> ok, so puppet with augeas maintaining sysrc, sysctl, and loader.conf is slick
12:54:11 <RhodiumToad> meena: looks like you can tell what geom classes support dumping by looking in the source to see if they answer the GEOM:kerneldump control message
12:54:29 <RhodiumToad> (geli does not)
13:42:10 <_xor> Is there an easy way to determine the first PID launched in a jail?
13:42:49 <_xor> I mean I guess I could use ps, filter by JID, sort by time, & parse the output...but is there a less hacky way?
13:44:19 <RhodiumToad> it might not be still running
13:44:44 <_xor> Assume it's a nopersist jail.
13:46:35 <RhodiumToad> I don't know of a way with the standard tools.
13:46:45 <_xor> In this case it will always be nopersist. I need a PID to watch, and I'm checking now, but jail only returns the JID (for obvious reasons, since it can exist without a PID).
13:47:25 <_xor> Even with libc, I'm implementing a rust utiilty right now and can functions from there.
13:47:33 <_xor> er, libjail.
13:47:33 <skered> You just want to know if something is running under a give jail?
13:47:46 <_xor> No, I specifically need the first process launched in a jail.
13:47:46 <skered> given*
13:48:18 <_xor> I guess I could query the command param and then search the process list for that with a chroot constraint to filter it?
13:49:18 <_xor> ...or I guess I could just write a pid file from the process, which might be the better way to do it. Hmm.
13:50:23 <_xor> Not saying it's a good or bad idea, but how come there's nothing like /proc in base? (or is there?)
13:51:16 <RhodiumToad>  /proc exists but isn't mounted by default
13:51:18 <_xor> I've always thought /proc was a bit messy, but I can see the value in it. Curious what the arguments are against something like that.
13:51:32 <_xor> procfs you mean?
13:51:33 <RhodiumToad> anything you can do with proc can be done other ways, though
13:52:20 * _xor just man'ed procfs
13:52:28 <RhodiumToad> I vaguely recall many years ago the decision was made that nothing should depend on /proc, after a series of security issues
13:52:36 <_xor> Oh, wow. I don't know why, but for whatever reason I assumed procfs was imported from Linux.
13:52:47 <_xor> Ah
13:53:04 <RhodiumToad> both freebsd and linux got it from svr4, I believe
13:54:20 <_xor> I can see where security issues would be easy to slip through the cracks. Makes sense.
13:54:45 <RhodiumToad> obviously linprocfs has to exist for linux compatibility
13:55:10 <_xor> Screw it, pidfile it is.
13:55:39 <_xor> Now I just have to remember how to determine my own PID.
13:55:59 <_xor> oh, getpid()
13:57:37 <_xor> Oh wait, hmm...if launched via /usr/sbin/daemon, can a child executable use getppid() to determine the PID of the supervisor daemon?
13:59:19 <_xor> Lol, I just greped /usr/src/usr.sbin for getppid and saw that syslogd.c calls it. Then I opened it up and noticed that it's an almost 4000-line file heh.
14:13:28 <last1> have the user defaults moved from /etc/defaults/periodic to /usr/local/etc/defaults/periodic ?
14:13:33 <last1> and I should make all my changes there ?
14:20:48 <RhodiumToad> you shouldn't change either of those
14:21:22 <RhodiumToad> you override them in /etc/periodic.conf
14:31:58 <last1> thank you sir
14:32:06 <last1> do I need to restart something for changes to /etc/periodic.conf ?
14:32:21 <RhodiumToad> no
14:32:33 <RhodiumToad> they take effect the next time periodic is run from cron
15:03:31 <meena> has anyone seen issues with rc.d/growfs not growing a virtual disk?
15:03:58 <RhodiumToad> growfs is a bit fragile
15:04:19 <RhodiumToad> I haven't done much with it on VMs, but I've seen it not work in other contexts
15:05:44 <meena> well, i tested my own code too, which is probably equally fragile, and that wasn't working either
15:06:03 <meena> but: this is the first time I'm testing MBR
15:11:18 <RhodiumToad> on a standard MBR partition setup, it has to resize both the slice and the bsdlabel partitions
15:11:34 <RhodiumToad> and I don't know if it does it correctly
15:12:06 <meena> I am fairly certain i don't do that in the python code
15:14:24 <RhodiumToad> do you plan to?
15:14:56 <meena> RhodiumToad: how?
15:15:36 <RhodiumToad> well in theory it's just a matter of parsing the geom config and figuring out what to resize
15:16:40 <meena> we need libxo support in… everything
15:16:48 <RhodiumToad> uh, no?
15:17:10 <meena> I don't wanna write a parser every for every tool, tho
15:17:17 <RhodiumToad> geom config is already available as text or xml (or dot)
15:21:09 <meena> RhodiumToad: what's the right device… thingy to ask about geom config
15:21:23 <RhodiumToad> sysctl -b kern.geom.conftxt
15:21:30 <RhodiumToad> or .confxml or .confdot
15:23:37 <meena> oh
15:32:34 <last1> how can I test a hardware read speed ? is cat a good tool ? I'm doing something like cat file | pv > /dev/null
15:34:58 <RhodiumToad> dd
15:35:20 <RhodiumToad> dd if=file of=/dev/null bs=1m
15:47:52 <last1> thank you as usual
15:48:03 <last1> is there a way to test that won't involve zfs caches and whatnot ?
15:48:22 <last1> for example reading a file nets me about 180MB/sec but writing shows 2000MB/sec
15:50:58 <RhodiumToad> write a file much larger than available memory?
15:51:41 <last1> so 200Gb file or so
17:13:34 <meena> 0 DISK ada0 26843545600 512 hd 16 sc 63
17:13:34 <meena> 1 PART ada0s1 26843512832 512 i 1 o 32768 ty freebsd xs MBR xt 165
17:13:48 <meena> so resizefs didn't run(properly)
17:16:18 <meena> nope, the slize isn't resized
18:13:59 <meena> who designed gpart's (or geom's?) syntax? who thought that stuff made sense
18:28:40 <last1> I am trying to check interrupts on my lsi card, shown as mps0, I'm running vmstat -i -p IDE 1 10, but it still shows the network cards, cpus, etc
18:29:06 <last1> I also tried -p da to show the drives directly
18:34:54 <CrtxReavr> Why wouldn't you use pciconf(8)?
18:38:22 <last1> didn't know it could do that :|
18:40:27 <CrtxReavr> meena, gpart makes a lot more sense than the DOS provisioning scheme.
18:40:45 <CrtxReavr> s/provisioning/partitioning
18:43:21 <meena> CrtxReavr: that's not the measuring stick. dos hasn't been on my mind in decades
18:44:54 <CrtxReavr> And yet its partitioning scheme remains.
18:47:14 <meena> only on i386 really
18:50:46 <CrtxReavr> I think it's out there in a lot more places than you realize.
18:51:13 <CrtxReavr> sudo file -s /dev/ada0
18:51:30 <meena> I am afraid to find out, but i have to fix it
18:53:26 <meena> no bugs https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__closed__&bug_status=New&bug_status=Open&bug_status=In%20Progress&bug_status=Closed&bug_status=UNCONFIRMED&f0=OP&f1=OP&f10=OP&f11=product&f12=component&f13=alias&f14=short_desc&f16=CP&f17=CP&f2=product&f3=component&f4=alias&f5=short_desc&f7=CP&f8=CP&f9=OP&j1=OR&j10=OR&list_id=616364&
18:53:26 <meena> o11=substring&o12=substring&o13=substring&o14=substring&o15=substring&o2=substring&o3=substring&o4=substring&o5=substring&o6=substring&query_format=advanced&short_desc=growfs%20mbr&short_desc_type=allwordssubstr&v11=mbr&v12=mbr&v13=mbr&v14=mbr&v15=mbr&v2=growfs&v3=growfs&v4=growfs&v5=growfs&v6=growfs
18:55:21 <meena> that's the second worst URL I've seen today
18:55:40 <V_PauAmma_V> I'm afraid to ask.
18:56:06 <meena> I always leave opportunity for things to get worse
19:02:54 <thumbs> now I feel better for posting a long amazon link the other day
19:14:26 <meena> CrtxReavr: what i mean is this shit: gpart resize -i " idx[i] " " pdev vs gpart recover " pdev  — right there in /etc/rc.d/growfs
19:14:30 <meena> why is it different?
19:17:40 <V_PauAmma_V> resize vs recover?
19:18:16 <meena> V_PauAmma_V: i think i understand why it's different, but not entirely
19:19:44 <V_PauAmma_V> Out of easy guesses, then. And hard guesses are beyond me.
19:20:16 <meena> like, it would make way more sense if you look at the whole thing as a tree
19:20:36 <meena> but it's usually presented flat, or most of the information is
19:21:04 <meena> geom -t gives you a tree view, but not with the names / indices that gpart expects
19:30:02 <meena> so, uhm, can I even resize the root partition if it's not the last thing on the disk?
19:37:10 <Zew> Question: how is the list of "stuff" generated when you use the command "df"
19:38:53 <adilix> hi all
19:41:14 <meena> TIL: you can't extend a root partion on MBR, if there's swap after it.
19:41:19 <meena> let's see if that holds for GPT too
19:45:38 <V_PauAmma_V> Zew, are you asking about how df(1) gets the list of mounted filesystems, or how it retrieves relevant information for each filesystem to list?
19:47:12 <Zew> both?
19:47:49 <Zew> I don't think it'll end up being the right thing I need to know to acomplish my task, but still like a curious cat, now, I wanna know
19:55:34 <V_PauAmma_V> For the former, it uses getmntinfo(3), which I think calls statfs(2) internally. For the latter (but only when filesystems are specified explicitly on the command line, it uses statfs(2) directly.
19:55:49 <V_PauAmma_V> s/line/line)/
19:56:59 <V_PauAmma_V> (The above based on a quick scan of the source code - it may be wrong or not applicable to your target FreeBSD version.)
19:59:08 <V_PauAmma_V> adilix, if you have a question, it's best to ask it directly of the channel without waiting for someone to gr... oh well.
19:59:29 <meena> can a user have a password and be disabled for *password-based* authentication, like in linux? Where they put a ! into /etc/shadow before the password field?
20:07:00 <Zew> thanks V_PauAmma_V
20:09:41 <meena> hrm… can't resize a GPT root partition either without deleting the stuff that comes after
20:09:50 <meena> I guess I'm just too used to ZFS…
20:10:11 <meena> but, also, for some reason… growfs didn't add a swap partition…
20:10:59 <meena> never mind, ignore that bit
20:14:14 <V_PauAmma_V> meena, passwd(5) seems to say that's not an option. The *LOCKED* prefix disables all forms of authentication.
20:15:11 <meena> V_PauAmma_V: my reading of pw(8) is that you should still be able to login via ssh keys
20:16:43 <meena> (ZFS is so much easier…)
20:19:35 <meena> oaky, so, there's basically no way for me to fix /etc/rc.d/growfs or cloud-init's cc_growpart to delete and recreate swap without it becoming an issue
20:23:15 <CrtxReavr> meena, test it with vipw(1).
20:23:17 <V_PauAmma_V> meena, see the following excerpt from passwd(5): https://bsd.to/xU5y , and note the different wordings for '*' and the '*LOCKED*' prefix.
20:23:19 <VimDiesel> Title: dpaste/xU5y (Plain Text)
20:23:32 <meena> VimDiesel: right, before destroying this VM, i should test it
20:23:36 <meena> I added two users, after all
20:28:28 <meena> VimDiesel: works with SSH keys
20:28:38 <meena> V_PauAmma_V: works with SSH keys
20:31:18 <V_PauAmma_V> Uh. Then passwd(5) is at best very misleading on that point.
20:34:09 <meena> verified with other user without ssh keys and it's failing
20:34:27 <meena> https://gist.github.com/igalic/d6f54f331b54e6529308d7d9a103d94a
20:34:28 <VimDiesel> Title: gist:d6f54f331b54e6529308d7d9a103d94a · GitHub
20:37:34 <V_PauAmma_V> *nod*
21:51:36 <_xor> Dumb question, but if a project looks for and links against libjemalloc.a, should patching it to remove source references to it and the linker flags to let it use regular ol' libc on FreeBSD work?
21:52:36 <_xor> (That's worded strangely, but you get the gist)