Ug bhyve pass through is killing me:

ppt0@pci0:9:0:0: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1b21 device=0x1042 subvendor=0x1043 subdevice=0x84aa

bhyve: PCI device at 9/0/0 is not using the ppt(4) driver

bhyve -AHPD -c $CPU -m $RAM -S -s 3,passthru,9/0/0 \

did I miss something stupidly obvious?

devctl set driver -f pci0:9:0:0 ppt

put pciconf above already lists it as using ppt0, and it's listed in /boot/loader.conf: pptdevs="9/0/0"

Some devices just don't work as pass through

but running that command line results in the same error messages

does anyone know if the ASMedia chips support that?

I'm looking for a USB controller that supports passthrough and would work in linux running in bhyve

Looks like the problem is that the BIOS turns SR_IOV back off after I swapped out the previous USB board for this board.

Hey, it's all working, thank you so much

Good to hear.

mew?

is portsnap dead?

Now that 13.5 reached EOL and since it's not in 14.4, yes.

can someone please send me a test /msg?

Perfect. Thank V_PauAmma_V

hello there, is there a way to run "monthly_status_security_output" manually and get output to stdout by chance ?

try: sudo /etc/periodic/monthly/450.status-security

luser thanks will try now

luser thanks, it is doing something

nope, output is: (output mailed separately)

i guess there is something to do with security_output=/path/to/a/file

a working mailserver is mandatory. I don't know if FreeBSD ships with one?

I recommend installing postfix. But many people are using dma.

freebsd includes both sendmail and dma in both

base

someone sent me this like a year ago. I haven’t even looked in to it yet, but its on my to do list

last i used it, it did, sendmail was default, I think y'all switched to dma? locally i first switched to postfix (which had some very funny isde effects involving a misconfigured mailer.conf) then a local fork of qmail

but the question was about how to get the output on stdout, which wouldn't require an MTA. i would suggest looking at what 450.status-security actually does, and see if you can invoke the relevant bit by hand

i suggest postix too

so I guess I will deep dive into the script and will make a my own version ...

if there is that about security_output to a file, you could try setting that in periodic.conf and checking that file after running the script

that was the fastest I'd ever typed in a while, why do i type fast when i panic

you know speaking of mailservers, i was looking for a postifx forum or something and actually came up anything. Anyone know a good place to ask postifx config questions? Not specifically related to bsd at all

also file: /etc/defaults/periodic.conf:164:daily_status_security_output="root" # user or /file

i guess this assumes that I can feed a file into that variable?

GoSox: #postfix, ##email, postfix.org/lists.html

same is true for weekly and monthly

right now I'm in the middle of upgrade

will test it a bit later

worked:

echo daily_status_security_inline="yes" > /etc/periodic.conf.local

daily_status_security_output="/file" >> /etc/periodic.conf.local

i guess all pastebin are died, credits to ai ...

anyone want to think with me how to connect old ssh hosts from 14?

apparently poof, ssh1 is gone, poof, dsa doesn't magically poof host is upgraded

for one host i have to use old static dropbear binary

whatever is not supported now it sucks

oh the bear helped me agaij

so i fixed it with dropbear-2024.86-static/dbclient

hi, i reported this earlier today: bugs.freebsd.org/bugzilla/show_bug.cgi?id=294980

is there anybody in here that has encountered a similar issue? maybe years ago when the 14.0 first came out

bugs.freebsd.org is presumably overloaded right now and not responding to me. Can you give a clue as to the topic at least of that bug report?

yeah of course. i'm trying to upgrade from 13.5-RELEASE-p14 to 14.0-RELEASE, and when doing the first reboot, during init (right after the ntp service goes up) mrsas(4) detaches all the drives

it doesn't happen if i go into single-user mode

I don't know, but I will ask a maybe, did the bootcode get upgraded between 13 and 14? Since it works for you in single user mode I doubt that can be it though.

Did you say 14.0? That's unsupporte and has been for a while. Did you try 14.3 or 14.4 instead?

i tried with the older and newer loader.efi, but the problem persists

yeah, fucking bots

V_PauAmma_V, i tried with both of those, yes. still the same (with some extra warnings about deprecated sysctls)

Good spot V_PauAmma_V. (And apparently I have a sticky g key on my keyboard. LOL.)

i first tried to go all-in with 14.4, and when i encountered the issue i decided to go back and update step by step. not sure if that's a good idea

I don't have mrsas(4) disks, so I can't attest to that.

I would try again with the current 14.4-RELEASE but I still don't understand why the mrsas driver would detach all of the drives. I also don't have anything with mrsas here so know nothing.

it's really weird. i also don't see any changes to it nor cam(4) in the release notes

I don't have enough caffeine in me yet today but I recall a command to list out the rc runtime scripts. One might boot single user mode as you have done and then manually run each of those one after the other until you hit the problem. Then you will have narrowed it down.

rcorder(8), no?

sounds like a plan

Yes, rcorder, man page says "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" to print the list out. It is 196 files here. But maybe some bisecting would speed up the testing.

Again I am just going to mention things like a good stuffed monkey so that they are refreshed. Boot Environments will allow you to boot the previously working BE. From there you can mount the future one and reach into it to fix things or review things. Or destroy it and reset and restart.

haha. sure, i'm currently on the backup 13.5 BE :)

i can also remount rw while in single-user, but i couldn't think of anything to change

It is also possible to boot a BE and then craft a new Boot Environment installation that is upgraded and then try booting that new one. vermaden has a classic post on this forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662

So if /upgrades/ are just totally problematic it is possible to effectively do a fresh install that way on an existing system and step forward into it. (into? onto?)

that... sounds really neat actually

That article is 14 years old and just as relevant today as when it was written. I love vermaden's quirky writing style. "This is SPARTA!" LOL!

Humorously I am trying to complete system upgrades this morning too. For me a few systems moved to 15.0-RELEASE p7 (which has gone much better than the 14.0-RELEASE did originally) and all of the rest up to 14.4-RELEASE p4 and one canary system on CURRENT. And then the jails. I need to improve my automation!

yeah, i'm too lazy with this stuff ':)

i'm glad freebsd-update still works even after deprecation, but i've been thinking about doing this upgrade since last year

rwp, i was able to track down the issue to smartd(8)

if i disable that service there are no more mrsas detachments, and i've been able to upgrade all the way to 14.4 :)

(i was even able to go all the way to 15.0, but i think it's too early for now)

rodri, Woot! It was smartd? Weird! I did not expect that. Glad you got it figured out!

rodri, 15.1 is scheduled for June 1st so you won't have long to wait for the .1 release to upgrade to it.

Meanwhile... On 15.0R installing postfix has a few annoying configuration bugs at install time. I should file a bug report on it.

The stock file contains both inet_protocols=all and inet_protocols=ipv4 and having both generates an initial warning and then 19 more lines of addition warning.

i love mr. sas