Hi, I'm playing with Linux compat with a Ubuntu base and cannot make OpenGL apps work, I found the nvidia driver are saved in /compat/linux but not /compat/ubuntu

How can I make them work in /compat/ubuntu?

are ARM cpu taking over?

unlikely.

how well does freebsd run on them?

I wonder if nvidia desktop pc coming soon

is archlnux faster than freebsd?

Only way to know for sure is to run your specific workload(s) on both and compare.

FreeBSD runs well on ARM CPUs, it's all the peripheral hardware that's the problem as usual.

pretty sure that guy is a long-term troll

Hey guys, I have an old HP Gen8 server with 10x SAS drives (hot-plug capable). after inserting one of the disks I get a message (in dmesg): "ciss0: Hot-plug drive inserted [blah blah blah]". However, the disk does not become "available". 'geom disk list' doesn't show it and there isn't an entry in /dev like there is when I boot the server with the disk already present.

is there anything I have to do to make the disk "work" after receiving the hot-plug message?

camcontrol rescan seems to do the trick :)

jbo: yay!

Hi. I've a trouble with freebsd 13 and VLAN on Hetzner VSwitch

Title: magnet_web paste from Someone at 217.168.150.38...

I don't understant how to reach 10.100.1.2 host

ferz: you need to assign all respective hosts to the same vswitch

then you need to configure a vlan on main interface of the server. the vlan ID is the "vswitch" number

and then you assign the IPs on the vlan subinterfaces

if you have vswitch number (vlan), for example, 10, then you need to, for example: ifconfig vlan10 create vlan 10 vlandev em0

and then you might also need to write all this info to /etc/rc.conf (using proper syntax)

otis: yes, vlan ID is 4000 and I've increase net.fib and used fib=1

Title: magnet_web paste from Someone at 217.168.150.38...

I've done in this way.

Other hosts are Linux on VLAN 4000 and they see each others

i wouldn't use "fib" unless you really need to

because otherwise you need to setfib -F 1 route get 10.100.1.5

eh, 10.100.1.2

or setfib -F 1 ping 10.100.1.2

otis: thank you

otis: I'll redo without fib then

it doesn't ping yet.

Title: magnet_web paste from "ferz" at 217.168.150.38...

I found a very interesting abstract - wonder if there is full video of paper somweher : THE FREEBSD APPLIANCE: LEVERAGING FREEBSD AND STRATEGIC SCRIPTING TO DELIVER STORAGE AND VIRTUALIZATION SERVICES

ferz: output of ifconfig? output from "arp -an" ?

anyone here running FreeBSD (cloud) servers without swap?

(context, in case you're wondering: github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/growfs adds swap, unless you tell it not to)

Title: freebsd-src/growfs at main · freebsd/freebsd-src · GitHub

that's some serious magic

i'm still missing the context though

otis: paste.scsys.co.uk/8853 arp and ifconfig output

Title: magnet_web paste from Someone at 217.168.150.38...

yuripv: whoops, sorry, in case you mised it: 14:00 <meena> anyone here running FreeBSD (cloud) servers without swap?

meena: yes, but what is the real question?

(or is it just a poll? :)

are you running a server without Swap? if so, why? and: How upset would you be if you made an image without swap, and a cloud-provisioning software squeezed some swap in there

people still run swap in 2023?

Seems like running without swap would be quite reckless.

we use swap to crashdump…

whats wrong with running swap

Nothing

The only real argument I’ve heard against it is SSD lifetime years and years ago. But I haven’t heard that as much more recentlyb

Might we see a 14.0-ALPHA (ready for binary upgrades moving forward to -BETA, -RC*, and -RELEASE) in the coming days?

Unless freebsd.org/releases/14.0R/schedule isn't current, a prerequisite step planned for April 25 was delayed, so your guess is as good as mine.

Title: FreeBSD 14.0 Release Process | The FreeBSD Project

coreystephanphd: as soon as we have a fix for OpenSSL 3 in ports and a decision on what to do with it on base, we'll get an update schedule

meena: +1

building from src, as non-root, with DESTDIR & MAKEOBJDIRPREFIX=/tmp/obj set, I still see lots of warnings about access

make[5]: warning: /lib/geom: Permission denied.

should buildworld even be doing this? why would it need to touch /lib/geom etc?

dch: there was a thread recently, and, i don't remember

I'm getting pretty close. bw, bk, all as non-root.

meena: I guess make release will be unable to make a memstick though

what about make packages? eh? eh??

is this a pkgbase thing

IDK surely all we need is sh, lua, and cc

everything else is sugar-goating users

mmmmmhh sugar goats

I use swop in clowd instances so i can get a crashdump if it happens

well well /tmp/obj/tmp/src/arm64.aarch64/release/oci.qcow2

I get all the way through to a built image without root

... its borked ofc

mktemp: mkdtemp failed on /var/tmp/temproot.OSt8VqBBa9: Permission denied

how?

Title: mm-mtree.sh « scripts « release - src - FreeBSD source tree

why can't this use a normal tmpdir

why does that invocation need root?

that doesn't when I fix /var/tmp/ which on these systems isnt user writable

users get /tmp/ and have to like it

anyway a bit further on we need chroot, pw "you must be root" also

oh, right

I still think pw needing root in an alternate root is a bit nonsensical

yeah maybe theres a fakeroot thing that fixes that

what do we use chroot for?

dch: we can TMPROOT to depend on NO_ROOT and then use /tmp

Why would /var/tmp be changed away from the default world writable with the t-bit set? What's the advantage of doing that?

This is the system default: drwxrwxrwt 9 root wheel 47 May 10 13:48 /var/tmp

rwp: the less place attackers have to write, .... the less place they have ... to write

Re: "warning: /lib/geom: Permission denied." I have been wondering about those too. I haven't figured out exactly what is happening at that point yet that wants root at that point. Seems very gratuitous at that point in the build.

If you want you could replace /var/tmp with a symlink to /tmp and I think that everything will continue working.

yes but sometimes as root/wheel I want a /var/tmp/

It's just that by convention /var/tmp is where files will survive a reboot. Like vi/vim recovery files. But by convention /tmp is always purged on a reboot.

and /tmp is a tmpfs in my place

these are somewhat restricted servers, so I'm fine with that

For restricted servers then I think you will want to build in a jail and then upgrade from there. Probably. Seems plausible. That's the route I am taking.

by convention /tmp _may_ be purged on a reboot, it's not usually a default

obviously making it tmpfs is one way to do that

there's also an rc.conf option for it

Purging /tmp on reboot is one of those cultural changes that happened about 1995 in the unix world. Using a tmpfs for /tmp seemed to flow through about 2010.

setting TMPDIR=/tmp may help with some utilities that try /var/tmp

I'm talking specifically about freebsd

Since the default mktemp is /tmp then that it tried to use /var/tmp tells me that someone already either set TMPDIR=/var/tmp or specified it on the command line.

If one were inclined one could hack a modified mktemp that always used /tmp regardless of TMPDIR or command line arguments. It would be pretty straightforward.

you're trying to build the src tree as non-root?

RhodiumToad, It is dch who is doing this. Working through the build as non-root.

But I agree with dch's unstated but implied feeling that building everything as root is "icky" and really should be a non-privileged build.

I would like a non-root build process working for me.

been a while since I tried it. let's give it a whirl

RhodiumToad: yep. buildworld and buildkernel are fine. its the final cd /usr/src/release && make ... WITH_CLOUDWARE=yes CLOUDWARE=OCI cloudware-release

ah

It basically works. But we do get all of these "warning: /lib/geom: Permission denied." types of errors on all of the system dirs at various points in the build.

tbh I'm curious how far I'd get

you get those errors in buildworld, buildkernel, or release?

Let me paste and post a build log from one of my builds...

I can see some obvious issues with building release as non-root, for example the fact that you can't set schg on files

It's 84MB in size. So, maybe fetch it and browse it with less rather than a web browser? proulx.com/tmp/freebsd/buildworld.out.txt

I am in the wheel group and therefore it had write permission to /usr/obj. dch is doing further overrides to put that elsewhere, and is seeing other additional issues.

Title: Snippet | IRCCloud

hm

^ this sort of stuff for example. IIRC this is actually from release build, but it is the same dirs and warnings in buildworld/buildkernel

so the thing with make is that it sometimes produces spurious "permission denied" warnings on dirs

When I ran that last build I forgot to give it a -j option so it ran to completion with one thread. Took a little over 10 hours on a modestly speedy box.

and in the cloudware section:

it checks for dir writability whenever you set the object dir, even if that dir never actually gets used

Title: Snippet | IRCCloud

so for example I have a readonly /usr/src, and make always whines about that.

dch: I reached out to Hetzner directly to see if they might furnish some credits for FreeBSD research, BTW!

RhodiumToad, That comment about chflags schg immutable is a good one. What files normally get that on a default system?

kraptv: I'm working on cloud-init and I think maybe the next release will be working a lot better on Hetzner, then they could consider providing official images again??

there's a bunch of PRs in the pipeline that should make it work less bad on Hetzner and DigitalOcean

rwp: libc, libcrypt, linthr, ld-elf, maybe a few others

I ran "find -x / -flags +schg -exec ls -ldo {} +" across my system and found only one "dr-xr-xr-x 2 root wheel schg,uarch 2 Dec 1 2021 /var/empty"

But maybe the -x trimmed too much.

I ran "find -x /usr/* -flags +schg -exec ls -ldo {} +" without too much thought to look over everything else and no other files with schg set found.

also init, chpass, login, opieinfo, opiepasswd, passwd, su, crontab, a few others

kraptv: cool! andrew@ has some initial patches for gpu boot loader, when I get time to test

what's gpu boot loader?

RhodiumToad: so the consensus is, building a release needs root still?

yuripv: people.freebsd.org/~andrew/0001-WIP-virtio-gpu.patch

I should have said "virtio-gpu loader support on arm64"

oh, i thought we are now running on gpu

(doesn't sound that crazy nowadays)

someone got linux running in a gpu shader.

yuripv: dashbit.co/blog/nx-numerical-elixir-is-now-publicly-available runs erlang vm bytecode in gpu. the sky(net) is the limit these days

Title: Nx (Numerical Elixir) is now publicly available - Dashbit Blog

rwp: how did you install? the system I'm looking at is a 13.2-stable installed via installworld

maybe release uses the NO_FSCHG option, I don't know

installworld sets schg for any program or lib that has PRECIOUSPROG or PRECIOUSLIB set in its makefile

RhodiumToad, A standard ISO installation and then standard freebsd-update upgrades subsequently.

My system is 13.1-RELEASE-p7 at this moment.

hm, I don't have an installer-installed system handy

lemme download a release

I am running a full binary installed system. freebsd-update with pkg binary packages. But I would like to be comfortable building the full system from source.

eh. I have to sleep now

ENOSLEEP!