i'm on the memstick install shell, how do I increase the size of tmpfs mounted on /var and /tmp?

I have an old machine that I installed opnsense on and it was working perfectly until I installed a intel pro/1000 PT quad port nic. With the nic enabled the boot time went from ~1min to ~20min. If I pass dev.em.X.disabled="1" for all 4 ports at boot it boots up in ~1min again, but as soon as I enable any single port it kills the boot time again.

I have swapped cards to confirm it isn't the card and I have booted FreeBSD 14.2 to confirm it happens with base FreeBSD as well.

btw anyone following my mem thrashing issue from a few days ago with bhyve on ufs resulting in way too much mem and swap used on host system, AllanJude gave great tip "-s 1:0,virtio-blk,/path/to/file,nocache" where nocache is supposed to make ufs not do any caching on the truncated sparse file. ofc i already switched to zfs (lol?) but i'll try it

on ufs on some other boxes soon

demido, oh interesting

demido: can't imagine running jails on ufs these days.

ghoti why not? jc

i read something about zfs arc and bhyve fighting for mem, then neither end up using it and i end up with swap getting used while having tons of Free mem, so it's good to set a max arc size. anyone learn that?

my right alt key in qemu does not work in the freebsd console that i just got after installing the vm, i read the docs to set the grab-mod key sequence to lshift-lctrl-lalt but i can't get my right alt key to work in the console, `editline` does not seem to recognize it

zenmov: instead of qemu you can use bhyve for virtualization, with bhyve all of the keys work

that's fine, sure. though i wonder what's causing that behaviour in qemu, the cli options i pass to qemu are sane too :(

Checking integrity... done (2 conflicting): webkit2-gtk_40-2.46.5_1 conflicts with webkit2-gtk3-2.34.6_10 on /usr/local/include/webkitgtk-4.0/JavaScriptCore/JSBase.h, plasma6-oxygen-sounds-6.2.5 conflicts with plasma5-oxygen-sounds-5.27.11 on /usr/local/share/sounds/Oxygen-Im-Cant-Connect.ogg

was just sniffing around in raid card bios settings and i saw only the first physical drive was marked bootable. so what happens if i turn server off, move it, turn it on, and that 1 bootable drive failed during power off. the whole array is non-bootable and all data lost now or?

due to limitations of wifi dirver i use wifibox to get faster speed. i also have em port and i had lagg failover between wlan0 and em0. could i use lagg between em0 and wifibox0? \

other thing is is that lagg0 have to start after wifibox is up i would think

demido: I'm not saying UFS couldn't or shouldn't be used ever, but that's not a case study I could write. I find the ZFS toolset invaluable, especially with jails, and I wouldn't want to do without them.

ghoti ah. ya the only time i'd not use zfs is if i have to use a raid card that doesn't have proper hba mode. and in that case, i either choose debian or freebsd ufs. and in that case i'm still leaning freebsd ufs. opinion?

#/join #ghostbsd

close but not quite

getting crappy memory issue again. i have 47G free, and console messages that swap pager is out of swap space

getswapspace failed

i even set vfs.zfs.arc_max to 8G

looks like disk_dev defaults to file with vm-bhyve. i could try sparse-zvol but any hope that fixes this memory issue?

ghoti you run bhyve vms on zfs, you know how to fix this?

cursed error eh

so what's using it?

looked into kernel memory stat?

is it resolvable ?

owww

ketas using what, the swap or the 48G of Free mem?

no idea mzar, you reported it to bapt right?

demido: well all?

swap usabe is just sideeffect

demido: I regularly use ZFS send/receive (not just for backing up and moving jails), snapshots and backup/restore with the .zfs directory in each filesystem/dataset. Aside from the RAID functions, ZFS still has a lot of uses.

ya the main issue is i have a host with zfs and bhyve, and tons of mem goes Free while swap gets filled until pager starts crapping out console msgs. same on ufs

no clue wtf

ketas: pkg 2.0.4 -> pkg 2.0.5

i shut down the bhyve vms and the swap emptied out heh

but I have to fetch it and install on all the workstations, one by one

Demido, sorry, I do run some bhyve but I guess not enough to be stung by the same bees.

demido: Are both VMs the same OS? Can you afford to not run one or both for a period to test actual cause?

My gut feeling is that this isn't a normal bhyve problem, otherwise more people would have experienced it

sbr i'm running 3 bhyve vms, all debian, on freebsd host. 53G ram to each vm, 32G ram left for host

it's not production yet so ya i can experiment

it's 14.2 with latest updates

mzar: does upgrade of just pkg work?

What happened to the wiki of this soekris.com/support.html :/ Anybody managed to boot the 6501 from mSATA? it boots from usb stick just fine does not boot mSATA with any of the slots

demido: In your shoes, I'd try reducing VM mem to 40g giving you 40+40+40 and 72 for the host.

demido: as an aside, do your vms actually max out available mem?

sbr why give host more mem when it doesn't even use the 50G it has free?

and no vms don't max out

resident never gets to more than 80% of allocated. this time even less

I don't entirely know how the mem management of byhve works but would guess it wants a continous block and as they grow the system may (hunch) be moving them around and as there isn't enough free system memory to duplicate out as it grows you end up with your swap troubles

> doesn't even use teh 50G it has free

Just because the active apps aren't actively claiming it, doesn't mean its not being used

ketas: pkg add ./pkg-2.0.5.pkg solved

sbr so why does top mark it Free if it's being used? and what would be using it? host does nothing but run 3 vms

Like I said, making a big assumption about bhyve's memory management, based on how programming lanagues tend to manage memory. bhyve may need to move stuff around as the VMs grow, to find continous addressable space and if its trying to move around 53gb it may struggle. It wont be holding onto any of that for long but needs free mem to do it

so this box has 192gb ram, that mean i need to make 192gb swap?

I hadn't gotten to swap but I was just about to suggest that as another test, back in the day (this ages me) the recommendation was your swap was double your ram but since machines go way more ram I think that was drastically reduced. My VM machine has 32gb physical and only 2g of swap but I only run small vms with 4g each so always have plenty free

192 is probably overkill but probably the size of your largest VM would be a safe number, so 54GB to be safe

vm-bhyve has an option wired_memory="YES", maybe i should use that? it says it doesn't allow swapping out

I'm not really a noob but im a noob compared to my idols, i want to be a programmer, does anyone have some useful must-know tips to pass on to a new BSD user coming from 10 years of Linux ?

I just started reading the zfs page of the handbook

I didn't expect it'd be that easy and convenient to use

I'm getting *hammered* by ssh attacks atm, most of it dropped by preauth (e.g. AllowUsers doesn't match)

dch hey

was expecting these to get passed through to blacklistd but AFAICT it never gets invoked

working on the mem issue still. got more info when you're up for hearing

how fares the vm juggling?

well first I need to get this ssh attack under control, I got paged for it :-(

i tried switching to zfs but still using file backed vms. didn't fix it. then switched vm disks to zvol-sparse, still didn't fix. so now i'm trying wired_memory setting in vm-bhyve but i'm seeing bhyve really eats a ton of ram more than the vms are allocated

ya np

demido: you need to figure out if its "just" storage related (in which case I'd ignore it)

or if its something else entirely

it's mem. the reality is bhyve uses lots of host ram to run vms

i saw the same swap thrashing with ufs and several zfs config variants

so even tho there was always tons of mem free, using the wired_memory setting i'm seeing that there wasn't enough vm + host ram available. bhyve kinda a pig heh

using wired_memory yes on the vms, 55G Free on the host, still getting plenty of swap usage wtf. dude so what, bhyve requires the host to have as much mem as vms are given? so 2 vms each getting 64G ram each, wired, requires the host to have 128G ram in order to not swap?

wired also means contiguous

likely it works once or twice then something ruins contiguous

hmm

think it would help my situation to jack up the swap?

sbr had the idea that i should make my swap as big as biggest vm's ram, so 64G swap if i want to have vms with 64G ram

I don't even know

dch: yes, that's how blacklistd works

maybe switching to fail2ban will solve the issue

I spotted it long time ago and probably some sophisticated attacks ending on preath could be also harmful

mzar: no thats exactly not what bl[ao]cklistd does, forums.freebsd.org/threads/blacklis…immediately-according-to-logs.82523 wrong users don't bump the counter

yes

in cgit.freebsd.org/src/tree/crypto/openssh/auth.c#n501 the notify is sent (good)

and then in cgit.freebsd.org/src/tree/contrib/blocklist/bin/blacklistd.c#n257 its ignored (bad)

the same in the upstream github.com/zoulasc/blocklist/blob/master/bin/blocklistd.c#L257

ok the approach in the forum post is purr-fect

things are getting banned like you'd expect

dch: maybe it could be triggered by option instead ?

Hey everyone, just wanted to say thanks for the help over the past few days on my issue of the ports tree not being able to build anything. Turns out I was forgetting to "git pull" the ports tree after cloning it.

dch get a chance to look at my mem issue updates?