I got it working, `gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 da0` and /boot in a `freebsd-ufs` filesystem

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'

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 0x0.st/HN9D.txt

showmount -e localhost from the server gives 0x0.st/HN9d.txt. showmount -e server from another host gives 'showmount: Cannot retrieve info from host: rowan: RPC: Program not registered'

what am I doing wrong?

hmmm. Now I am getting 'nfsd: rpcb_set tcp failed: Cannot allocate memory'

not sure that's the right line for exports boss

the man page says you need -network: "/d -network 192.168.1/24"

my showmount -e localhost looks way different

moon-child: is /d it's own filesystem or a subdirectory?

lmao it's a 32-bit overflow

Title: clnt_vc.c « rpc « libc « lib - src - FreeBSD source tree

admittedly it is somewhat unreasonable of me to have 500m fds. But.

rtprio: man page has an example that looks like that (without explicit -network)

which one is that?

oh, nevermind, you are right

did you put these entries in rc.conf so they'll start on boot?

yes

the overflow problem still seems to be the main one, though

do you have 500m files on /d ?

no; I have an fd cap of 500m

can you nfs mount your it locally?

curiouser and curiouser. I dropped the fd limit and rebooted, and now I can mount the directory without errors, except that it's empty

on both the server and client

00:38 < rtprio> moon-child: is /d it's own filesystem or a subdirectory?

its own fs

Hahah

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.

I dont see a mention of UUIDs in the fstab(5) man or the handbook (Chapter 19. Storage)

Does freebsd use UUIDs, or am i supposed to use device addresses such as /dev/da0 ?

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.

I have a ZFS on root install with a UFS /boot

I guess I could convert that /boot to zfs as well and bypass this issue

I just use GPT labels personally.

GPT labels, I only have efiboot0 and gptboot0 in /dev/gpt/

I use GPT labels. Never tried usinf UUID

I use GPT labels. Never tried using UUID (is this duplicate? Did not see earlier)

is this on?

ah `glabel` is a thing, thanks parv

qtc`: yo, was asleep

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

sphex: so the more paths you have for a device, the more confused things can get

I think I'm "happy" with my setup for now; USB with EFI/Legacy Support, a labeled UFS for /boot.

you ended up using gpt for the boot usb?

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

you can probably do better by putting the /boot stuff in the root dir of the ufs boot volume and having a boot -> . symlink

yes, `gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 da0` and a ufs partition for /boot

so I can boot now

is there a parameter for 'mv' to allow 'mv . .', 'mv .. .' and 'mv . ..'?

why would you want to?

. /boot/boot is taken, so i wont be able to move everything a level up and symlink /boot to .

in order to verify inodes (first case) re-sort directories (latter cases)

oh yeah

you want me to take a look at it?

no

pfff

the "oh yeah" was for qtc`

oic

but he has the same problem

qtc`: another option would be to mount the boot volume on / with -o union but that might get messy

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)

elgrande: how would "mv . ." "verify inodes" as you put it?

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

the problem with -o union is that having more than one / entry in fstab may well confuse things

oh I dont have a / in fstab, I have zfs on root

but i dont think that will help union

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

all of those are files that get copied to special places rather than things actually loaded from files in /boot

Thanks, I really like that suggestion

however, you'll obviously have to be careful about doing make installworld if you ever build from source

since that'll try and put /boot/boot back

good to know, at lest is a good option for OPNsense and TrueNAS since I dont think they installworld

is installworld only for upgrades? I don't remember what its used for.

installworld is only if you're compiling from source code

yeh, but practically speaking i only remember using it for upgrading to newer versions of freebsd

I don't remember it being possible to do so via pkg

freebsd-update can in theory upgrade to new versions, though I don't use it myself

I'll make a note

hmm. gpart always seems to use v1 uuids when creating gpt partitions

would be nice to have a way to use v1mc or v4 instead.

any idea where to look at when receiving 'ping: UDP connect: No route to host'? lookup with adns port ('adnshost') works fine.

what ping command are you using?

RhodiumToad: im pretty, and sure, we've got code to generate v4 uuids

elgrande: perhaps you meant to use ping6 ?

(that's deprecated in favour of ping -6)

RhodiumToad: same error with ping6

it looks like ping6 does a hostname lookup even for numeric addresses

what is in your /etc/resolv.conf and /etc/nsswitch.conf

meena: having code to generate them is one thing, but gpart doesn't use it

RhodiumToad: bsd.to/awGo

Title: dpaste/awGo (Plain Text)

is 168.63.129.16 reachable?

is 168.63.129.16 reachable?

elgrande: please stop disconnecting every 10 seconds

I am on iOS in a psychiatry, sorry. iPhone 14 Pro Max cannot handle 2 apps.

ping still is waiting or whatever. can i conf wait time?

waiting for what?

use control-C to abort it

203 packets transmitted, 100% loss

resolvconf seems to regen resolv.conf as you probably have seen.

freebsd.org A INET 96.47.72.84 freebsd.org A INET6 2610:1c1:1:606c::50:15

so resolving still works

resolving how?

adnshost freebsd.org

that's not what I asked though

is 168.63.129.16 reachable?

no

well then

whatever IP is in /etc/resolv.conf is where basically every program will send DNS queries to.

if it doesn't work as a resolver, then basically no network commands will be able to look up hostnames

there is no ipv6 in /etc/resolv.conf anymore has been overwritten

that doesn't matter, a resolver reached via ipv4 can be used to look up ipv6 addresses

resolv.conf is usually overwritten as a result of, for example, DHCP lookups

(you can control this via resolvconf.conf)

(yes, the configuration file has its own meta-configuration file)

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)

oh right, gpart operates at kernel level

I don't see any code to do those in userland either :-)

v4 is pretty trivial since it's just a matter of 122 random bits and 6 fixed ones

don't we have libuuid in base

v1mc can be done by generating a v1 uuid and then stomping over the node address, with 2 fixed bits and 46 random ones

there's some uuid functions in libc/uuid but they only generate v1, via the kernel uuidgen() call

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

I should mention that this is zsh 3.0.6 running on 3.3-RELEASE

3.3!

3.x was a notoriously bad time

It may lack some capabilities we have come to take for granted

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

up until 6.x, that is

(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)

I don't think I ever ran 3.x

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

Servus debdrup?

Hic non sunt servi.

is it possible to crashdump onto/from encrypted swap?

not AFAIK.

you could maybe dump onto the unencrypted device, but that would kind of defeat the point

heheh yeah

the basic problem with dumping is that the system is mostly frozen; threading and geom infrastructure don't work

dumping onto, say, gpart is done by having gpart compute the raw disk offset/length of the dumpdev in advance

that said, it looks like it is possible to do encrypted dumps

I don't think they can go onto geli devices though

ok, so puppet with augeas maintaining sysrc, sysctl, and loader.conf is slick

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

(geli does not)

Is there an easy way to determine the first PID launched in a jail?

I mean I guess I could use ps, filter by JID, sort by time, & parse the output...but is there a less hacky way?

it might not be still running

Assume it's a nopersist jail.

I don't know of a way with the standard tools.

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).

Even with libc, I'm implementing a rust utiilty right now and can functions from there.

er, libjail.

You just want to know if something is running under a give jail?

No, I specifically need the first process launched in a jail.

given*

I guess I could query the command param and then search the process list for that with a chroot constraint to filter it?

...or I guess I could just write a pid file from the process, which might be the better way to do it. Hmm.

Not saying it's a good or bad idea, but how come there's nothing like /proc in base? (or is there?)

/proc exists but isn't mounted by default

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.

procfs you mean?

anything you can do with proc can be done other ways, though

I vaguely recall many years ago the decision was made that nothing should depend on /proc, after a series of security issues

Oh, wow. I don't know why, but for whatever reason I assumed procfs was imported from Linux.

Ah

both freebsd and linux got it from svr4, I believe

I can see where security issues would be easy to slip through the cracks. Makes sense.

obviously linprocfs has to exist for linux compatibility

Screw it, pidfile it is.

Now I just have to remember how to determine my own PID.

oh, getpid()

Oh wait, hmm...if launched via /usr/sbin/daemon, can a child executable use getppid() to determine the PID of the supervisor daemon?

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.

have the user defaults moved from /etc/defaults/periodic to /usr/local/etc/defaults/periodic ?

and I should make all my changes there ?

you shouldn't change either of those

you override them in /etc/periodic.conf

thank you sir

do I need to restart something for changes to /etc/periodic.conf ?

no

they take effect the next time periodic is run from cron

has anyone seen issues with rc.d/growfs not growing a virtual disk?

growfs is a bit fragile

I haven't done much with it on VMs, but I've seen it not work in other contexts

well, i tested my own code too, which is probably equally fragile, and that wasn't working either

but: this is the first time I'm testing MBR

on a standard MBR partition setup, it has to resize both the slice and the bsdlabel partitions

and I don't know if it does it correctly

I am fairly certain i don't do that in the python code

do you plan to?

RhodiumToad: how?

well in theory it's just a matter of parsing the geom config and figuring out what to resize

we need libxo support in… everything

uh, no?

I don't wanna write a parser every for every tool, tho

geom config is already available as text or xml (or dot)

RhodiumToad: what's the right device… thingy to ask about geom config

sysctl -b kern.geom.conftxt

or .confxml or .confdot

oh

how can I test a hardware read speed ? is cat a good tool ? I'm doing something like cat file | pv > /dev/null

dd

dd if=file of=/dev/null bs=1m

thank you as usual

is there a way to test that won't involve zfs caches and whatnot ?

for example reading a file nets me about 180MB/sec but writing shows 2000MB/sec

write a file much larger than available memory?

so 200Gb file or so

0 DISK ada0 26843545600 512 hd 16 sc 63

1 PART ada0s1 26843512832 512 i 1 o 32768 ty freebsd xs MBR xt 165

so resizefs didn't run(properly)

nope, the slize isn't resized

who designed gpart's (or geom's?) syntax? who thought that stuff made sense

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

I also tried -p da to show the drives directly

Why wouldn't you use pciconf(8)?

didn't know it could do that :|

meena, gpart makes a lot more sense than the DOS provisioning scheme.

s/provisioning/partitioning

CrtxReavr: that's not the measuring stick. dos hasn't been on my mind in decades

And yet its partitioning scheme remains.

only on i386 really

I think it's out there in a lot more places than you realize.

sudo file -s /dev/ada0

I am afraid to find out, but i have to fix it

no bugs bugs.freebsd.org/bugzilla/buglist.c…&f9=OP&j1=OR&j10=OR&list_id=616364&

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

that's the second worst URL I've seen today

I'm afraid to ask.

I always leave opportunity for things to get worse

now I feel better for posting a long amazon link the other day

CrtxReavr: what i mean is this shit: gpart resize -i " idx[i] " " pdev vs gpart recover " pdev — right there in /etc/rc.d/growfs

why is it different?

resize vs recover?

V_PauAmma_V: i think i understand why it's different, but not entirely

Out of easy guesses, then. And hard guesses are beyond me.

like, it would make way more sense if you look at the whole thing as a tree

but it's usually presented flat, or most of the information is

geom -t gives you a tree view, but not with the names / indices that gpart expects

so, uhm, can I even resize the root partition if it's not the last thing on the disk?

Question: how is the list of "stuff" generated when you use the command "df"

hi all

TIL: you can't extend a root partion on MBR, if there's swap after it.

let's see if that holds for GPT too

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?

both?

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

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.

s/line/line)/

(The above based on a quick scan of the source code - it may be wrong or not applicable to your target FreeBSD version.)

adilix, if you have a question, it's best to ask it directly of the channel without waiting for someone to gr... oh well.

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?

thanks V_PauAmma_V

hrm… can't resize a GPT root partition either without deleting the stuff that comes after

I guess I'm just too used to ZFS…

but, also, for some reason… growfs didn't add a swap partition…

never mind, ignore that bit

meena, passwd(5) seems to say that's not an option. The *LOCKED* prefix disables all forms of authentication.

V_PauAmma_V: my reading of pw(8) is that you should still be able to login via ssh keys

(ZFS is so much easier…)

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

meena, test it with vipw(1).

meena, see the following excerpt from passwd(5): bsd.to/xU5y , and note the different wordings for '*' and the '*LOCKED*' prefix.

Title: dpaste/xU5y (Plain Text)

VimDiesel: right, before destroying this VM, i should test it

I added two users, after all

VimDiesel: works with SSH keys

V_PauAmma_V: works with SSH keys

Uh. Then passwd(5) is at best very misleading on that point.

verified with other user without ssh keys and it's failing

Title: gist:d6f54f331b54e6529308d7d9a103d94a · GitHub

*nod*

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?

(That's worded strangely, but you get the gist)