Anything interesting change in 13.1 where null deference would be SIGILL (not 13.1... maybe even <13) vs SIGBUS (13.1)

Could even be amd64 only... Looking at updating www/node14 and running tests on the port there's a new failing test that causes what I think a null dereference. Based off nodejs comments and that this test isn't failing on 12 or 13i386 it appears it should be SIGILL.

But on 13.1 amd64 it's SIGBUS.

it should be SIGSEGV

It's possible I'm reading the nodejs test code incorrectly.

can someone checkout 3e5300e0ed3 from the /usr/src and tell me if you have a Makefile?

fatal: path 'Makefile' exists on disk, but not in '3e5300e0ed3'

(git show 3e5300e0ed3:Makefile)

It would be a SIGSEGV. SIGILL is for a corrupted instruction. Code (text) space versus data space.

crb: that's not an actual freebsd commit

whatever you did, you've managed to run off along openzfs (maybe you were bisecting)

--first-parent is probably your friend

kevans, I am indeed trying to bisect

crb: yeah, so you'll need to restart with --first-parent to avoid accidentally hopping down vendor branches

kevans, thanks a bunch!

yup yup

kevans: that makes huge difference, now I'm building. I've been stuck on that for a week!

crb: ah, you should've said something sooner. :-)

kevans: well I hadn't done a git bisect before and I just figured I was doing something wrong

newbie question - what's the port name of gtk for python?

I think that's part of the gtk port not its own port.

right

so it's possible that Gtk has come unglued

... it has! O.O

fascinating unix problems...

we're on. merci beaucoup skered !

I'm trying to get Python scripts working in the `pkg` version of HexChat on 13.1-RELEASE-p2. When I try loading `/usr/local/lib/hexchat/plugins/python.so` I get `Undefined symbol "PyCapsule_Type"`, which suggests to me it can't find the Python library for whatever reason.

I was wondering if someone might know what's going on or how I can probe this further. My hunch is that it's only looking in `/usr/lib` and not `/usr/local/lib`?

That should be part of libpython? python.so links to that?

ldd /usr/local/lib/hexchat/plugins/python.so

libc.so.7 => /lib/libc.so.7 (0x801083000)

And that's it.

fran, Could it be that you one version of python, say 3.10, installed & hexchat was expecting another version, say 3.9?

s/that you one version/that you have one version/

just had an sdma fail with amdgpu. it hanged the whole local terminal, and Xorg went T

remote computation remained available

bhyve(4) says "bhyve is considered experimental in FreeBSD." Is that still true?

Probably best to ask virtualization@

sounds like universal disclaimer

I'm somewhat skeptical at my ability to get relevant answers from FreeBSD technical mailing lists, at this point. Last time I got one at all, it answered the question I had specifically said I wasn't asking, then blamed me for pointing that out. I'll stick to IRC.

I only have my doc hat so I can't speak with any authority, but nothing about bhyve feels experimental anymore.

I've been using it in production for quite a number of years, as have many others, so I'd be fine with removing it.

I think it'd be smart to get the OK from someone involved with its development currently, though.

Fair enough. We'll see if one answers it in #bhyve.

aww just updated the cpu on my router to the most modern it can support

and still no vmm :(

CPU: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz (2992.63-MHz K8-class CPU)

vmx_modinit: processor does not support desired primary processor-based controls

I really just wanted to update it anyway so it was better at plex so no loss

but was holding out a little hope :)

weirdly though according to intels data sheet it does support virtulization on that chip

wonder what specific processor function its looking for

daemon: man page says it wants VT-x/EPT; while it seems that VT-x is supported, EPT is not: community.intel.com/t5/Processors/I…T-not-supported-by-Q9550/m-p/276699

Title: Solved: Is Intel VT-x/EPT not supported by Q9550? - Intel Communities

ah I see

hi daemon

heya wez

How's the BSDing coming along?

pretty well, I mean its BSD once you have a system working with it you never really need to do much :D

but its nice to upgrade from a dual to a quad

Can I virtualise it yet?

you can run freebsd in a vm or as a hypervisor (using bhyve)

AWS?

no reason why not

but not docker?

there are attempts at docker, but I think the general consensus is VM a linux instance and use that

its the easiest way

I made an absolutely microscopic gentoo build specifically for that purpose

I keep meaning to actually publish that config somewhere -_-

ooohh

hmm

might actually be a fun little side project

make a port that initilizes a minature gentoo bhyve vm

and connects a docker shim executable to it

~ no reason it should not work

I wonder how volume mounts would operate though

daemon: do it and I will use FreeBSD on docker (AWS Fargate) :)

well actally that would be a problem

because on AWS you would be in a vm already

so you could not run bhyve and emulate a linux

as you would not have access to EPT/VT-x etc

daemon: They have bare metal instances

that should work I imagine

at least vmware products can passthrough the required cpu features so you can run hypervisors in vms

(i'm running xenserver for testing on esxi)

interesting, I heard that passing down those cpu functions can cause some unusual behaviour

never tried it myself

phryk: so these disks use MBR instead of GPT. how can i rewrite a modern freebsd bootloader to my disk

gpart add -t freebsd-boot -s 512K -l gptboot0 ada1

gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada1

should i use GPT or MBR opn a new install on an m.2 SSD? it's a uefi motherboard. the default selection was MBR

GPT

CCFL_Man: for newly formatted disks, use GPT. if you have to keep using an older thing with MBR on top of it (don't wanna lose existing data, OSes, …) I assume you'd use -p /boot/boot for ufs and -p /boot/zfsboot for zfs when calling gpart bootcode

tho if you're on a halfway modern machine and do a new install, gpt + efi is probably the way to go.

btw anyone know if uefi secureboot is possible with freebsd yet? it's like the last big missing thing concerning security-wise for me.

s/concerning//

phryk: thanks!

thanks for the help

phryk, uefi secureboot == no

so when i create a lagg interface during install, it won't link up with the switch

in truth creating interfaces in the install is kind of pointless, as long as you can get into the system after it reboots after install is the time you want to target for setup

that's true

~ it takes a bit of getting used to but skipping the installer and doing it by hand can be 'handy' as well

the other truth is that when you configure the lagg0 interface, make sure to bring the individual interfaces up or else you will be pulling out what little hair you have left

oh yep

even though its a hateful thing to do what I like doing is triggering a customer script via /etc/rc.local

so rc.conf is almost bare except the essentials

ugly but pretty effective

custom*

I have a lot of daemons that require an ordered start up that is hard to predict due to network latencies and such; sync times

so I pop the 'daemon' application via rc.local to start a perl script that handles all of that stuff

oh, nice

this will just be a basic nas

it always starts that way :)

it certainly does!

is there a general consensus that with zfs and lots of ram, does the swap size need larger than the default

~ honestly if you are speccing a machine for serious zfs work you may as well shove a SATA/ssd or nvme in there and just use that as swap

but zfs is meant to use 'unused' ram

so there would be no requirement to change the swap allocation

I'm running FreeBSD 12.3 with up-to-date quarterly packages, and my system "appears to" hang almost every time I log out of KDE. It sits on a console screen with a frozen pointer, but I'm still able to SSH in and do a clean reboot from another system.

It seems to be related to PulseAudio. I noticed one message on the console: "Failed to create secure directory (/var/run/user/1001/pulse): No such file or directory" However, that directory does exist, it's owned by me, and it has 700 permissions.

Should I be part of any particular group (like 1 of the 3 "pulse" groups)? Any other ideas?

chriswells0, I am just a FreeBSD newbie who was going to ask my own question but first let me ask you how you are starting KDE? Are you lauching it with xinit, startx, xdm or other X Display Manager?

rwp: I'm using sddm.

Also are there any clues that might be shown in the ~/.xsession-errors file?

And I would also look in the /var/log/Xorg.0.log file looking for the "EE" pattern at the bottom for errors.

I don't have ~/.xsession-errors.

I haven't ever used sddm so I don't know where it logs output.

It seems like every other moment there is a new X Display Manager that is new and different. xdm, gdm, gdm3, kdm, lightdm, slim, sddm, ... well, you get the idea. :-/

In Xorg.0.log and Xorg.0.log.old, the only EE line I have is: "Failed to load module "ati" (module does not exist, 0)"

And since it starts up we can assume that is an early non-fatal error that it keeps going through. So not of note here.

There don't seem to be any errors in /var/log/sddm.log either.

(searching for EE and error)

The "EE" thing is a convention I have only seen in the /var/log/Xorg.0.log file. Noted tags information at the top of that log file.

sddm.log appears to follow the same convention.

It has mostly II and 2 WW lines (auth info and "could not setup default cursor").

I don't know the solution to your problem but I might suggest some things that might help.

I'm also able to log in and out without issues using xrdp, which uses xrdp for sound instead of PulseAudio.

I'm open to any suggestions. :)

When X is running are you able to Control-Alt-F1 to return to the main console? Or Control-Alt-F3 to get to vt3?

That would at least get you to a console that you can log into without needing a second system to ssh in from.

And then if that works for you then does that also allow it when your X is stuck?

Since you suspect PA you might try killing just the PA processes. It is possible (likely?) that some process at X exit time is still holding a file descriptor open which is blocking sddm from closing and exiting everything.

I'm able to get to another console from X, but it doesn't work when it's stuck.

Drat. That's a bummer. Because it is nice to be able to self-rescue all on the same keyboard.

If this were another OS and it were me I would run "ps -efH | less" and browse the parent-child hierarchy below the X server and see if processes are still running that should not be running. Then I would try killing those.

I agree, but I'd still be stuck having flashbacks from using Windows.

But I actually do not know the BSD equiv to ps -efH to get a hier sorted ps listing. Do you?

I don't know how to list that tree, and I'm also not sure which processes to kill for PA. The only one I know for sure is pulseaudio.

Honestly, I don't recall if I've every killed it after getting stuck.

"htop" can show the processes as a tree. "pstree" port also claims to do the same

"-d" option of "ps" could do that too

Just to show what I see on a SysV style ps output system. bsd.to/Jd0K/raw

Title: Jd0K

parv: Thanks. I installed htop.

+1 for htop which I find awesome and much preferred to the traditional top

The best feature is the bar graphs for memory usage. Very useful to check overall health of the system.

OK, I'm going to log out to reproduce it. I'll be back in ~5 minutes since I expect to need to reboot.

Take your time going but hurry back. :-)

Do not be surprised if "htop" shows more memory than could physically be installed in a system: htop-dev/htop #1039 -- eventually port would be updated with the fix

Title: Mem: 16.0Z on FreeBSD · Issue #1039 · htop-dev/htop · GitHub

1039 – two different spellings of "timezone" bugs.freebsd.org/bugzilla/show_bug.cgi?id=1039

Good to know. Thanks.

My own newbie question is how do I use Boot Environments to back out from a failed upgrade from 12.3 to 13.1 where I screwed up the upgrade?

How did you go through the installation/update?

Here is my current state now. bsd.to/aATb/raw

Title: aATb

After much searching I don't find any blogs that show anyone actually discarding a boot environment.

They all talk about having forethought to create a new one for the new upgrade. But alas I am now getting the opportunity to learn all about them now. :-)

I think from reading beadm(8) & bectl(8) man pages that I need to create a "newdefault" (or whatever) and then rename it into place. Which requires destroying the current default.

With "bectl(8)": bectl activate <next root dataset>. Then "shutdown -r now".

Does that sound about right?

parv, Right. That's how I was able to boot. I can set that to 12.3-RELEASE_2022-04-18_154217 which is the last snapshot which was fully functional.

And then I booted to that environment. And of course everything works there. But now I need to clean up.

I could bectl mount zroot/ROOT/default somewhere and make repairs. I might do that too.

But if I could just discard it and start again that would be a good option for me.

Yeah, forget repair; install anew

"install anew" as in flush and re-install a pristine system? Is that what you are suggesting?

Of course that is always an option but I don't think I have reached that point. Far from it! I expect to fully recover and then upgrade again.

And possibly have a different failure. Recover. And repeat. It's a pretty good system.

This is my first time using boot environments and let me say I think they rock!

Yes|No. I meant that create a new dataset of the current 12.3 root; then (try again to) update that to 13.1. OTOH, blasting everything out, and just installing 13.1 would not cause a broken update

That "anew" did not come out right

It was a little ambiguous. But honestly the documentation is a little fuzzy on these things.

I have given up on snapshot clones (as creates by "bectl") to create a base for updates. I use "zfs send | zfs recv" for that.

I must say that the possibility of creating a new zroot on one system, and then sending that zroot to another system that way, and then booting it, is very sexy.

That way I can destroy the old snapshots whenever I want & do not have to keep them due to being a "clone"

Right. Without needing to "promote" the clone.

Yes

And I guess in 2018 or so pool checkpoints were added. "I didn't know!" Or I would have checkpointed before upgrading. That would have been good forethought too.

To me, having "full" or "thick" root datasets provide better flexibility & ease of management at the obviouls cost of disk space

s/obviouls/obvious/

Though a pool checkpoint looks to be a very large hammer. It seems to be all or nothing.

So good that I now have the opportunity to learn something about snapshots, clones, promote, and boot environments. :-)

I can see the advantage of your zfs send zfs recv to create a completely deep copy with no entanglements. And likely disk space is not really a concern at that point.

But I didn't have the forethought to avoid my current problem. So I am going to go back and hack on it for a bit and see what I can learn from it.

With an intermediate step of sending the data to a file & creating a dataset from that file provides me with a backup of the dataset on another disk

rwp, Before the update to 13.1, you should also make snapshots of datasets responsible for /usr/local/ & /var/db

This was a default install of 12.0 (I think .0) and so has the default zroot pool layout with /usr/local being part of zroot/ROOT/default I think.

You can confirm that with "df /usr/local"

There is a /usr dataset (that is not mounted) so that /usr/home and such inherit from it. But non-listed /usr/local is on / (I think).

Yes. It's on zroot/ROOT/default and so part of the core dataset.

Before I actually snapshot'd, cloned, promoted, I thought I would explore "bectl mount default /mnt" first. Really cool!

Is that "default" from broken 13.1 update or is the 12.3 dataset the new "default"?

It's default from the broken 13.1 upgrade.

That allowed me to go in there and fix my current snag. I had changed root's shell to bash. But then broke bash by screwing up the upgrade recipe.

I know, I know, I should have avoided it but... With that broken then I had no way to log into the 13.1 system after boot.

And I rather wanted to try it again with the proper upgrade procedure anyway. But let's try to repair this one.

I was then able to edit the passwd database in /mnt the 13.1 environment, now mounted under /mnt.

( Ok. So "/usr/local" snapshot is covered by the snapshot of the root dataset due to the default ZFS set up during FreeBSD installation)

Yes on /usr/local being covered by the root dataset snapshot. That's the reason for the non-mounted /usr dataset.

I miss not having /etc/passwd and /etc/group and such directly. I don't understand why FreeBSD went to the binary database. A lot of trouble for very little gain. And loss of easy of admin IMNHO.

Install|Comiple static version of the desired shell

But anyway "vipw -d /mnt" allowed me to set the shell to /bin/sh (or csh if one prefers) and automatically runs pwd_mkdb on it. So that worked.

s/Comiple/Compile/ # What the hell was that!

Then "bectl unmount default" unmounted it. It's already marked as the default boot. Rebooted. I can now log into the 13.1 system and all is as it should be.

With a failed binary ports upgrade. But now that I am back logged in again I can now fix that easily enough using the pkg-static executable.

Wait, so the only thing broken in 13.1 update was "bash" package (because it was set as root's shell)?

Yes. Mostly. There was another thing too though.

The other thing that was odd during the freebsd-upgrade install phase was that there were a long list of complaints about /usr/src but I didn't run it under script and lost long list of whatever it was complaining about.

... along with all the other packages of 12.3 which will need to be reinstalled on 13.1

rwp: FreeBSD got that from BSD at CSRG

I have a git clone of the source from the as documented way to do that in /usr/src and that seemed to confuse things. I wouldn't mind to walk that again and see exactly what was happening there during the freebsd-upgrade install phase.

debdrup, I just don't see the advantage. The /etc/nsswitch.conf allows other databases to be used if one wants an open ended database for accounts.

And for most systems the small /etc/passwd file fits in memory trivially. So it is very fast. It's a convenience tradeoff thing.

But I am making my peace with pwd_mkdb and moving forward.

This is just a guess since I'm too lazy/tired to source spelunk, but I'd be surprised if it doesn't have something to do with it being a lot easier to cache, since it's the sort of thing that gets consulted rather often on a busy system.

I note that it fixes a problem that I experience with, ahem, other systems, that run "nscd" network services caching daemon. On those the nscd hashes entries and the order is hash-shuffled breaking ordering.

Regarding my upgrade failure and recovery... I ran "pkg-static bootstrap -f" to force a reinstall of pkg. Then "pkg update" then "pkg upgrade -f" is now running to force replace all of the ports. That should solve my broken shared library problem I created that broke my ports.

Thanks for the upgrade recovery help! I am really pleased with the FreeBSD robustness and ability to recover. It rocks! :-)

While that is running I think it might be snack time.

rwp: It seems like plasmashell that's hanging. I did have some other processes belonging to that user (keepassxc, ssh-agent), but I was able to kill them.

The keepassxc process (which I suspected as the issue before) wouldn't die once, but I was able to reproduce the issue another time without keepassxc running.

Once in a while some process would not end after sending TERM signal. But after sending the series of STOP, TERM, CONT, the process ends. So how do the series of signal make the process end in that case when a lone TERM would not?

Is it that because STOP signal "cannot be caught or ignored", the process stops; TERM signal is waiting, so on CONT signal the process sees that & ends?

There was also a kwin_x11 process.

I'll reproduce and try STOP, TERM, CONT.

I also found "kquitapp5 plasmashell" online, so I'll try that too.

Was "kwin_x11" process a child of "plasmashell"?

parv, It seems to me that if TERM is handled incorrectly but STOP, KILL, CONT, works, then that is an indication of a programming error.

I can envision ways to produce the bug. But it can't be the way they desired it. That or they were buggy in their thinking of signal handling.

Sorry, 's/STOP, KILL, CONT/STOP, TERM, CONT/' is what I mean.

Upon return from suspend a program can catch SIGCONT to do things like resize and redraw and such. And that might accidentally allow SIGTERM. But SIGTERM should work by itself.

parv: No luck.

I also tried killing kwin_x11 first. It did die, but then plasmashell still wouldn't die.