salvadore: it says 1301000, which apparently corresponds to the initial 13.1 release. but also the drm-kmod version in pkg is still from 20220907, which is from before the PR to support that firmware was merged… so I guess the firmware is there, but the driver package to use it isn't yet?

what even is going on in -social

:-|

-social is doing its job. purposefully serving now

I have 5 full scrollbacks of that

Wow. Just wow.

micttyl: I think it is doing the reverse of its job, because I wanted to post there about something unrelated to freebsd itself but I cannot because I do not want to attract the attention of that

phryk: the graphics ports are a bit complex. drm-kmod is only a metaport: it installs other ports and does nothing else. In my case it installs drm-510-kmod, and its latest version is not v5.12 which I believe is what you want, but v5.10.163

I guess a new port called drm-512-kmod will be created in the future for that

drm-kmod also installs gpu-firmware-kmod

which is a port with many flavors and might include the firmware for your graphic card

corrrection: it is a port with many dependencies that have many flavors

I have a system with many many jails and which takes time to stop, thus I'm getting:

Jan 17 10:10:57 troubadour rc.shutdown[91773]: 120 second watchdog timeout expired. Shutdown terminated. Jan 17 10:10:57 troubadour init[1]: /etc/rc.shutdown terminated abnormally, going to single user mode

any idea how to raise this?

I've already kern.init_shutdown_timeout: 180

and I haven't touched the default rcshutdown_timeout (which is 90)

so I'm wondering where does this 120 comes from?

ah yes, it's that.. sorry

otis, would you happen to be around?

jbo: sorry, ETOOBUSY today.

otis, good luck!

ok, so i should be able to create a new boot environment with bootclt, mount it and chroot into it, and then run freebsd-update and pkg update? i need some recompiles to run into the background. then i should be able to activate the BE for next boot?

hrm, that's right. pkg gets no network connectivity while inside "bectl jail XXX"

ah, bectl -o ip4=inherit jailname gives me network to run pkg

Looking for some feedback on ZFS on block storage volumes from cloud providers. Since these are already redundant from the service provider, would it be sufficient to run a single virtual disk as a ZFS stripe, or is it still worthwhile to do mirrors or raidz on these?

ggb, runnings lots of hosts with ZFS on top of virtual block devices. works great. as you mentioned your provider will usually already have all the fault-tollerance, backup stuff etc. set up behind that virtual disk you get. so based on my knowledge & experience simply using such a disk as a one-disk stripe in ZFS works great.

my reasons for still using ZFS are mainly for maintenance/features such as the ability to easily take snapshots, setup dataset encryption and replication

jbo: thanks! This is what I was thinking. We use FreeBSD and ZFS as our application host for a product we are launching. Each customer gets an isolated process of our application and a ZFS dataset. For redundancy/HA we plan to always keep two hosts live from two different providers.

ZFS makes deploys super easy -- stand up a new host with the new app bits, `zfs send` a customer's dataset from live to new, after first send is complete, turn off live host, send again, turn on on the new host. We can afford the momentary downtime on our backend hosts.

Anyone good with C++ and want to render an opinion? I get this on FreeBSD, where using the same version of the compiler on Debian doesn't see this error. A friend's also said OpenBSD compiles this code out of the box with their base tools and they don't see this: bpa.st/T65NW

Title: View paste T65NW

mason, my wild guess is that long long on FreeBSD is longer than long, but not on the other platforms.

V_PauAmma_V: bpa.st/CRF5I fwiw

Title: View paste CRF5I

same on Debian Bullseye and FreeBSD 13.1

If you're using C90 then long long is a nonstandard extension so could be anything

Maybe it's not the same in C++?

C++ generally just refers to the relevant C standard

I don't know, then.

hrm

FWIW, there's a set of instructions for building this code, so presumably it was valid when written, making me wonder what's changed: azerothcore.org/wiki/freebsd

Title: FreeBSD | AzerothCorefreebsd - AzerothCore

Windows64 is the odd one out with its LLP64 model stackoverflow.com/questions/384502/…-bit-size-of-long-on-64-bit-windows

Title: c++ - What is the bit size of long on 64-bit Windows? - Stack Overflow

That said, it's conceivable the change was in that code, and not FreeBSD, because there's a time counter bit that I can't imagine ever worked on FreeBSD.

not counting Cray

for your error int64 looks the closest you'll need to see what it is defined as

probably long

and you have no long long overload

if so the error looks right to me

if the others are using g++ and you are using clang++ that may also be part of the reason, g++ tends to be laxer

Uses Clang on Debian as well.

But yeah, maybe __int64_t differs. Haven't checked that yet.

Interesting. In /usr/include/x86/_types.h __int64_t is either long or long long based on #ifdef __LP64__

I see __LP64__ defined in both FreeBSD and Debian and sizeof(long) and (long long) is the same on both, 8, and __int64_t matches.

Maybe there's some notion of type not being satisfied regardless of it all boiling down to a size.

it's not just a question of size

long and long long are different types even when both 8 bytes

Yeah, that's what I was wondering.

just as char, signed char and unsigned chat are 3 different types

sure

I still wonder what's different then, with Clang the same version on both sides.

Said differently, I wonder why there's no long long overload as compiled on one but not the other.

mason: some embedded C compilers let you choose the size of types on the command line

meena: that's an interesting feature

makes it "easy" to define your "exact" dialect of C. arxiv.org/abs/1909.06353

Title: [1909.06353] That's C, baby. C!

This is a C++ issue, but yeah.

I had my FreeBSD desktop crash and reboot last night at almost exactly 3am. Rebooted okay.

Can't find anything interesting in any log file. No interesting cron activity at exactly that time.

First crash and uncommanded reboot in the last year. So that's pretty good regardless.

could be hardware

A hardware problem is always a possibility. Cosmic rays from space and all of that.

I'm new to FreeBSD and I'm running stable/13 (because of iwlwifi). To keep it up-to-date you have to regularly rebuild it from source? docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld

Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

As I understand freebsd-update doesn't work in STABLE.

I'm reading this: docs.freebsd.org/en/books/handbook/cutting-edge/#stable

Title: Chapter 25. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

when I login I get `ld-elf.so.1: Shared object "libncursesw.so.8" not found, required by "zsh"` and am then logged out

via a console and via ssh

gp5st: as root too?

I just did an update and thought i had pkg update everything

Kalten, I'm trying to remember the root password

why it's not in my password manager is beyond me

you could boot into singel user mode—no password should be required

Kalten, I'll see if I can. It's a Digital Ocean droplet

as root you could reinstall zsh ncurses etc. or `chsh myuser`

to change the users shell until zsh works again

yeah, but if I can't?

is there a way to get ssh to not launch the default shell and instead just run a command?

Maybe `ssh user@host /bin/tcsh`

dont be fooled: you seem to be missing the prompt in that case, but it seems to work

(does ist work with a defect shell as default?)

ah, i was able to get into single user mode, by just spamming trying to get a console while it booted from the DO admin pages

:( pkg doesn't seem to work in single user mode?

at least i can change /etc/passwd?

or not? vi is erroring about the file not of the right type

`chsh -s /bin/tcsh myuser` should do it.

it's a read-only file system

`mount -w /` I think

inside `/etc/shells` you can see the allowed shells.

mount -w / worked

thank you

pkg won't work because dns won't work

how did I get into such a broken state

in single user mode? No network is up.

no, i rebooted and logged in

Maybe `service netif start` but I am not shure.

ah

strange.

it's like ti's missing routes to everything

does `ping www.freebsd.org` work?

no

unknown host

Does `ifconfig` give a clou?

ping 8.8.8.8 gives no route to host

(I ment clue :-) )

ifconfig shows the loopback and the one nic with the correct public address

strange IP.

it says status active

no, the ip is the one it's supposed to have

is some firewall closed?

`ipfw show` if you are using that one

it has 3 entries in it. I don't remember what they were before upgrading

I'm in the remote console it provides since I can't ssh in and can't copy/paste from it

last one `deny ip from any to any` I assume.

Is there some `allow ip from any to any`

the last is a deny ip from any to any

the middle is an allow up from any to any

the first is deny ip from table(1) to any

there are 4k entries in table(1) but my home ip isn't one of them

I assume the first entry is not "00001" (first row of output) but a grater number. Try adding `ipfw add 1 allow all from any to any` and to delete that entry afterwards `ipfw delete 1`

it's 00030

i added a default route, so it'll resolve stuff now

which means you can temporarily add a rule before that

and i can pin 8.8.8.8 but i can't ping freebsd.org or pkg.freebsd.org

it'll resolve them, but not ping

I added the tmp rule but the same behavior

how did this get so messed up

And `host pkg.freebsd.org` does not work?

it'll resolve it

I rebooted and now I have not-my ip address

give me a second

So you have a static IP address but now it is wrong? In that case it begins to sound like some hardware error in the host of your virtual mashine?

(even more than one ;-) )

I'm not sure

I feel like every time I upgrade things like this happen

I don't know what i'm doing wrong

aaa

ok, i have a network now

but I can't get pkg to work

approximatly what is the error

sorry, it took me a second to rememeber where screen shots got sent to :-\

pkg-static does exist and gives the same results

now we are getting somewhere!

There is no release_2 on pkg.freebsd.org/FreeBSD:13:amd64

Title: Index of /FreeBSD:13:amd64/

why is it trying to get that then?

Look into your `/etc/pkg/FreeBSD.conf`

ok, one sec

the url says release_2 in it

url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly"

ok

or better

https instead of http

and latest instead of quaterly, iff I am right

(or memory serves)

that seems to be doing something

I'm also going to take this to 13.1

I think I typed only 13-RELEASE when i did the upgrade

but first update the system, so that uname tells you 13.1-RELEASE and reboot

OK

give me a few minutes

thank you for your help

it's greatly appreciated

`${ABI}` inserts the correct path for the current system (archetecture, release)

you are welcome

it's at "applying patches" from a `freebsd-update -r 13.1-RELEASE upgrade`

`freebsd-update install` now

ok, uname says 13.1-release-p3

doing the pkg upgrade now