did you export that var? all of my preamble uses, for instance, look like `export ZFSBOOT_POOL_NAME="tank"`

Hi all anyone knows if exists a topic for SEO?

not necessarily on this server

jschmidt ya literally it has: export SCRIPTEDPART="mfid0"

i might have that wrong. maybe it should be PARTITION="mfid0" i have trouble understanding man bsdinstall a bit

how to enable internet on Realtek Gaming 2.5GbE Family Controller and Intel(R) Wi-Fi 6 AX201 160MHz drivers to enable the net in freebsd 14.2 ?

recompile?

i don't have net i can't use ports pkg

on another machine

they are just not found

who knows

l00py: you?

Hello! I'm only asking this here because it's crickets in #bhyve and #openindiana...has anyone successfully installed openindiana in bhyve on a FreeBSD 14 host that gotten X to work? vesa looks to be blocked since i'm using uefi mode

ya i just needed partitions="mfid0" looks like. going to try that. then add partitions="mfid0 gpt" if mbr is used which it probably will be

brutex i have an asus crossfire viii mb with rt 2.5g and intel 1gig ether ports. i dont think i could get rt working so i just used intel with no probs

but its' been a few years so don't remember details sorry bud

xanthor i never used openindiana sorry maybe someone else has. also try mailing lists?

i know that's not really helpful but if you're desperate enough.. hehe

i'm going to keep poking at it. Pretty sure I need the xorg framebuffer driver based on how Debian is working in bhyve.

but...there isn't one in the OI repos!

it's funny though...looking at all the things that openindiana brings to the table, i'm just like "Yeah so FreeBSD does all that"

it is the superior unix

i don't think i've seen one false advertisement about FreeBSD from anyone official

pretty remarkable

whoa 14.2 now brings OCI to freebsd that's so huge ty dch and core!

wtf scripted install with export PARTITIONS="mfid0 gpt" doesn't boot, but if i do manual installer and select mfid0 disk and gpt partition table it boots?

scripted install with export PARTITIONS="mfid0" works too (uses mbr)

is it supported to send a ZFS snapshot of a FreeBSD system MAJOR.SOMEMINOR to a FreeBSD system MAJOR+1.SOMEMINOR?

for example can I safely send snapshots from a 13.x RELEASE to a 14.x RELEASE and the recover from that 14.X RELEASE to a 13.X RELEASE afterwards,

s/the/then

mage: yes, this should work fine, but if you import the sent snapshot to a newer version zpool, that pool will not import on the older system and sending the filesystem back might not work either

there are no "versions" any longer, it's all about the features you have enabled

dell poweredge r720 in uefi installing 14.2 w/ ufs. manual install to mfid0 using defaults works fine. scripted bsdinstall with: export PARTITIONS="mfid0" and system can't boot. i'm stuck, anyone know what i'm doing wrong pls?

l00py: I had trouble installing 14.1 on dell poweredge r620 onto mfid0 too, when doing full manual partitioning. The only fix was using guided partitioning, deletion all auto-partitions, and then re-creating new partitions (UFS)

ukky ok prepared to be weirded out? i go back to the room the server's in and it had booted. so i rebooted and watched it and after it said all of the boot options failed, including FreeBSD and windows boot manager and pxe and stuff, it sits there for 30 seconds then boots into freebsd (WTF!?)

i got all the info so what it said is...

start pxe over ipv4, server response timeout, boot failed efi network 3, pxe no media detected, boot failed efi network 4, then next screen...

consoles: efi console, reading loader env vars from /efi/freebsd/loader.env then freebsd efi loader block of text/info, then ignoring boot0006: only one DP found, trying esp... setting currdev to disk0p1, trying pcieroot ... setting currdev to disk0p2

then loading /boot/defaults/loader.conf etc and it boots

so wtf?

hey any ideas on how to get my Intel AX201 wifi somewhere past the year 2003? I see an ax210 kmod but I don't think it works for AX201.. and the only media listed is 802.11a/b/g :/

this is on 14.2

afternoons

ivy: thanks

hmm.. FreeBSD 14.2.. is drm-61-kmod broken? Tried both pkg and ports make install but the console just hangs when I kldload i915kms.. console is still responsive, but I have to then ctrl-alt-F2 to get into a console I can work in .. and startx still doesn't load. (Alder Lake 12th gen Intel Iris xE)

worked on 14.1.. once I was able to compile drm-61-kmod.. but 14.2 it doesn't work any more

did you install it from ports?

yeah did a git pull and everything

is there a particular branch I need to be on?

No, it just has to be built with the kernel you are running. Do you have the OS sources in /usr/src?

I ran freebsd-update -r 14.2-RELEASE

I still get a message about the boot loader being too old

freebsd-update -r 14.2-RELEASE upgrade that is

hmm does freebsd-update not update /usr/src?

/usr/src/UPDATING shows 14.2 in it

and my /usr/ports is on 'main' branch

drm-61-kmod in ports shows port revision 2..

/usr/src may need to be on the 14.2 branch

no .git in /usr/src

do I need to git clone /usr/src?

Hmmm....over the past week lots of people have been reporting problems with i915 and the drm kmod with 14.2. Wonder what's going on there.

drm-61-kmod worked just fine on 14.1

Yeah that's what everybody else who's reporting the problem is saying too.

pertho: That's what I do. You can also copy in the src tree from 14.2-RELEASE

pertho: Point is, if it's building against kernel sources, you need the right kernel sources, not some old version

freebsd-update doesn't update the kernel sources?

seems like an oversight :(

It should do that by default if they're there

Here i915kms 14.2 worked on 12th gen but not on 11th gen (intel gpus)

14.1 worked fine

HER: yeah i915kms in drm-61-kmod worked perfectly on 14.1.. 14.2? It loads the drm firmware and just hangs there.. no system freeze (like with drm-515-kmod.. because that was far too old for my chipset)

and I'm on 12th gen

pertho: strange.. works fine in my 12th gen

so i wonder what is the probl

drm-kmod issues going from 14.1 -> 14.2 freebsd.org/releases/14.2R/errata

yeah but I recompiled it with 14.2 sources

is there a definitive way to check my source is 14.2? Is there a version.h or something?

what about the message flashing right before the system boot/menu (when bsd logo show up)

HER: Your Boot loader is too old? :D

I getthat too

also my iwlwifi(4) device is on 802.11a (Intel AX201) :(

i dont know, it appeared after 14.2 upgrade

pertho: try wifibox for wifi ?

I see AX210 kmod package.. but.. nothing for AX201?

pertho: why would the bootloader be too old ?

HER: no idea.. I updated with freebsd-update

pertho: but why do you think its related to bootloader being too old ?

(i have no idea what the messsage says)

no.. drm kmod is a separate issue from 'bootloader is too old' (after upgrading to 14.2)

how do I check drm-61-kmod is compiled against 14.2 sources properly?

any versioning inside the files?

postsnap fetch update ?

I'm on 'main' branch in ports (git)

pkg info drm-61-kmod just says: Architecture : FreeBSD:14:amd64

pertho: git checkout tags/release/14.2.0 ?

Say, what's the short story of why we don't have gcc*-libs-only-packages on FreeBSD? Why do I need the full compiler suite just because some software has runtime deps on the libraries?

I'm sure this is a discussion as old as GCC itself (and now llvm/clang), so I'll take the TL;DR. :)

Ltning: Separate packages for shared objects, binaries, "development files", etc. is rarely done on FreeBSD (I can't think of any immediate examples).

Yes, but I'm trying to understand "why", since especially these compiler packages are absolutely humongous

At the end of the day, simplicity.

I suspect because it would make more sense to do in a subpackage world

have you met the GCC build process?

I have not had the pleasure, no.

Simplicity is a perfectly valid reason.

It's only a pleasure if you're a masochist.

just building a subset of what the GCC project builds seems to be a complete PITA

I had kinda hoped that the job of splitting it up, having been done already for all the other kids (linuxes), was already done - but .. clearly not.

I think you'd see no objection to splitting out gcclibs if we could just segment the existing build

We just happen to be so lucky that we have to adhere to the PCI DSS, which says not to install any unnecessary software etc. etc., and even actively *reamove* dangerous stuff like compilers and such.

I don't know about .deb, but rpm .spec files have separate sections (for -devel, -utils, etc.) so their build system already separates the packages after building without much intervention from the builder.

On the other hand, Slackware Linux, like FreeBSD rarely separates packages.

yeah, I think in other nixen it's largely a matter of it being nearly-trivial to do

Which is of course complete utter bollocks, compilers are no more or less dangerous than (a) cat, and our reasoning for not doing any of that is "then we won't have a supported system". Which has flown for 15+ years, I expect it'll fly for a while longer - but this question keeps coming up.

Of course that compilers are also in base kinda muddies things, makes it pointless to "fix" the packages if base still has those bits. But hey, pkgbase? :D

Yeah but you can also make the same argument for say, python or perl.

Those can be equally as dangerous as a compiler and they're necessary to run whatever python/perl program you want to run anyways.

Obviously. Trust me, we have.

So when I'm asking this, it's mostly because I hate staring at pkg downloading three different gcc versions when I do pkg upgrade in prod.

If we could find someone willing to sponsor some subpackage work, that might be good

:-)

It's not at the top of my list, I'm afraid. And my budgets for this kind of stuff have shrunk dramatically recently :(

(Right now I'm struggling to educate new brass that it's a Good Idea(TM) to support projects we care about)

woof =\

I mean, one could probably script it.

cp -a /package/root/bin/* /somewhere/else ; and then make a package out of /somewhere/else using it as the package root directory.

Ltning: if there's any way I/we can help, shoot me an e-mail

we can probably conjure up some evidence that it's a Good Idea(TM)

With the brass? Eh, this is my fight, mostly. But I sure will if I feel they don't budge.

"Enough with this open source already!" -new brass

Yeah- fair enough

lmao wat

it's just a few packages, what's the big deal

(Says brass who are just in luuuuv with aws)

You can't really help people like that.

TommyC: you can, you just need idiot speak

"line go up" or something

Well, some of the lower-level brass are kinda ok, and seem to understand (much like a toddler understands how a car works), so I'm trying to work through them.

(And I was allowed to throw money at eurobsdcon, and I need to tell the foundation to send their annual invoice too, now that I remember)

Someone hired MBAs?

"Accel-AKKR". Don't ddg it.

Warning: Facter: Unable to getenv for pid 1, 'uninitialized constant Facter::Util::Linux'

The fun of living in a linux world

hah

Ltning: ah yes, i have that too

Argh, I'm using squid in an attempt to cache freebsd-update, but every time I get TCP_MISS on the interesting parts. The metadata gives me a TCP_HIT, but all the actual patches are misses.

But when I look at the squid log, I see the exact same requests being processed for each freebsd-update run, yet they are not cached. I'm going crazy here.

I think there's a 'top size' setting for the cache. It won't cache anything over that size. Is it tuned correctly?

Yea it's massive, 16GB in memory, 10GB on disk

Okay, well, that's not it. XD

But I see squid is RELEASE-ing objects all the time. Is update*.freebsd.org giving really short cache times?

anyone know how to get an Intel AX201 WiFi working in something beyond 802.11g in FreeBSD-14.2? I see an AX210 package for a kmod.. and some other series' (200, 7000, 8000).. but what specifically supposed the AX201? Or is there no support?

You should be able to tune the cache time on squid. It could also be throwing out larger items if other things are also being cached and maybe accessed more.

It's been a long time since I ran squid, so I'm kind of just throwing a few things out there. :/

Hrmf, opnsense squid doesn't let me override lifetime

pertho: what driver is that?

i'm stuck and really need help pls. dell poweredge r720 in uefi with hardware raid putting on ufs. stock 14.2 install boots fine. my scripted bsdinstall with NOTHING but: export PARTITIONS="mfid0" gets a hanged boot until pxe times out, then it boots. why isn't it just like the stock install?

l00py: Can't help, sorry .. bsdinstall is not something I often touch :D

l00py: If the Dell R720 has SAS dirves then use ZFS instead of UFS.

ya sas drives but it's hardware raid so no zfs

l00py: switch to mrsas(4), use JBOD, use UFS

l00py: switch to mrsas(4), use JBOD, use ZFS

but the stock install works fine

i don't really want to just 'avoid' the issue i want to figure out why my scripted bsdinstall with ONE setting doesn't work the same as the stock installer

if you are fine with this, then why asking for advice ?

l00py: Have oyu tried using ZFS? There are only to options....You tried one option and it didn't work :)

l00py: what is export PARTITIONS="mfid0" mean? I boot off mfid no problem on a 710 iirc

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/mfid0a 90384476 43018616 40135104 52% /

rtprio well that's supposed to tell bsdinstall to use mfid0 to put ufs on. same as when in the stock installer i manually select mfid0

are you saying when you script it, it doesn't work at all? when you inspect the installed disk what's on it?

it ends up booting fine, just after the initial delay

i rebooted and watched it and after it said all of the boot options failed, including FreeBSD and windows boot manager and pxe and stuff, it sits there for 30 seconds then boots into freebsd. it says: start pxe over ipv4, server response timeout, boot failed efi network 3, pxe no media detected, boot failed efi network 4, then next screen...

consoles: efi console, reading loader env vars from /efi/freebsd/loader.env then freebsd efi loader block of text/info, then ignoring boot0006: only one DP found, trying esp... setting currdev to disk0p1, trying pcieroot ... setting currdev to disk0p2. then loading /boot/defaults/loader.conf etc and it boots

but when i run the stock installer, still ufs to mfid0, it boots right into it

no boot options failed stuff, no pxe attempt

what's the bios boot order if it goes from disk to pxe back to disk?

when i run the stock installer it detects my scripted install in uefi and asks if i want to remove it and put its in, i say yes. so maybe my scripted install doesn't do the same, and the freebsd boot option that's failing is the old stale uefi entry from the stock install?

lemme get that for ya

rtprio sorry it's taking a while i already had the ePSA running and it's almost done

no worries, mine also takes forever to boot up

ok back..

uefi boot sequence: unavailable: freebsd, embedded sata port optical drive, unavailable: windows boot manager (not sure why that's there at all), integrated nic1 port 1, port 2, port 3, port 4, integrated raid controller

rtprio ^

u`u`u`u`u`u`u`*******

and 'freebsd' and 'windows' are uefi ?

where is that coming from, since 'raid controller' works, just put it at the top

no idea where windows is coming from. know how i get into uefi to see what OSs are set up in it? maybe poking around in that will help me discover root cause while cleaning out windows trash

i think server had windows on it when i bought it

ah i found where i could delete the windows boot option so that's gone

i left the freebsd boot option because what i'm gonna try is run stock installer again just like i was doing, then NOT let it remove the other freebsd uefi entry, then after it installs and reboots see if it has same boot glitch as scripted install. that will tell me a lot

rtprio ok got more info...

reinstalled stock, had it leave the other "FreeBSD" uefi entries, named this uefi entry FreeBSDstock, still rebooted fine. i noticed that in the boot options there was a "FreeBSD" on its own line, and there was a line "integrated raid controller 1: FreeBSDstock" that the stock install obviously made. it was on the top line

so then i thought maybe the magic would show when i left the uefi name FreeBSD instead of using a different name, to get the conflict, so i reinstalled stock, left the existing ones, named new uefi option FreeBSD. still boots fine, and the boot options are now:

integrated raid controller 1: FreeBSD, then on its own line FreeBSDstock (grayed out) and on its own line FreeBSD (grayed out)

so what i'm gonna try now is delete all freebsd boot options to get uefi clean, then reinstall my scripted installer, and see how it sets up the boot options

brb

go into your uefi console and remove some things eh

ok got it half way figured out. just as i thought when my scripted install ran, it didn't create that integrated raid controller 1: freebsd, boot option line for it. if i select the lower line integrated raid controller 1 efi fixed disk boot device 1 it boots right into my scripted installer

so the stock installer is creating a uefi entry for raid controller + freebsd that works by default, but my scripted installer isn't

not sure how to make it do that but that's what i need to do

i think vermaden.wordpress.com/2024/02/27/important-efibootmgr-command and forums.freebsd.org/threads/how-to-f…in-modified-bsdinstall-script.85335 will answer that for me

seems i need my bsdinstall installerconfig script to set up a efibootmgr command

rtprio what you think?

did you do the install with efi or mbr?

rtprio how do i know?

l00py kenv | grep efi-version

maybe you want to check how was it booted ? sysctl machdep.bootmethod

do you have an /efi directory that's mounted msdos?

mzar: that's a new one to me. nice

rtprio: I am providing only useful tips, like: switch to mrsas(4), use JBOD, use ZFS

;-)

I would absolutely suggest the same. Although, I would suggest an HBA (or "IT" flash of the RAID controller,) if possible.

but my shift is over, Good Night

mzar: See ya'!

l00py: Didn't we speak recently about the flashing of the H710p Mini or something? Maybe I'm mistaking you for someone else?

mzar: Early on in this dudes diatribe, I suggested to reinstall and use ZFS and this dude totally dismissed me as being utterly illeraite in anything technical !! :)

how safe is reflashing the card to jbod?

rtprio: Incredibly. Many people have been doing it for years. I do it every single time I buy anything that will be utilizing ZFS.

i have a perc h700 / megaraid but have only been using it in raid mode

rtprio: It's quite easy and very well documented. Especially for supported Dell Perc's.

Well, even JBOD is still hardware RAID. That's why I always flash to "IT Mode" (basically just goes from RAID to HBA.)

ok just confirmed from within the stock install and scripted install that efibootmgr -v output is different. so bingo. ok now for rtprio's question lemme check

rtprio: Are you saying you have an H700 series PERC or is it literally an H700 (and not an H710 or something?)

cparman " Early on in this dudes diatribe, I suggested to reinstall and use ZFS and this dude totally dismissed me as being utterly illeraite in anything technical !!" stop lying. i said i wanted to figure out the problem first

which i now have

ek ya that was me

remember my boss didn't approve any firmware modding, just pure software (OS) change from linux to freebsd

l00py: Okay, cool. Just want to make sure I'm not regurgitating a bunch of swill to you. :)

yep np and ty

l00py: That's unfortunate.

ya

obviously zfs > *

l00py: You are spinng your "Wheels" on something that can be easliy resolved by using ZFS, Dude

so now i need to figure out how to make the scripted install's efibootmgr -v output match that of stock install

You'd get much better performance out of an HBA with hardware RAID (ZFS) than you will with JBOD. But, it is what it is. I get it.

cparman cool so just ignore me and stop whining from the sidelines buster

imagine obsessing over another man's hardware

I am, F-tard

and yet here you are still whining

this is not productive discourse

and I will continue

Okay, people. Let's not get into any nastiness, please.

rtprio: Do you always need to flash Perc cards?

well, my system was second hand and was running hardware raid,

i didn't feel comfortable at the time flashing it

and i knew enough to not make 7 volumes of one drive each and run zfs on it

so i left it the way it was

rtprio: I have a Perc on a small dell server that I have set up as jbod and has been working fine for years. However I only see the that the drives allow just 150MB/s ? (da0: <ATA HUS722T2TALA600 MU03> )

the drives don't really show in dmesg

rtprio ok confirmed that both stock and scripted install return UEFI for machdep.bootmethod

now to get efibootmgr -v of scripted install to match stock

s2r: mfi0: 57267 (boot + 73s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=20, scsiType=0, portMap=06, sasAddr=5000c50042793249,0000000000000000

JBOD will certainly work, but it'll still require hardware RAID on top of software RAID (with ZFS.) Which, in turn, degrades performance and adds extra steps for drive replacement.

because you have to single drive raid a new drive before the zpool replace?

rtprio: Exactly.

rtprio: I force the use of the mrsas driver to detect Perc710 (I think that's the one I've got) via hw.mfi.mrsas_enable="1" in device.hints. I did it because at least when I installed the server the drives where shown as mfiX or something like that.

And nearly any RAID controller can be flashed to an HBA since most firmware is based on (or using) MegaRAID/LSI or something popular like PERC.

at some point i'll slap a dual nvme card in it, retire the very old ssd, flash the card and zfs it

s2r: so you say try the mrsas driver rather than mfi ?

Sounds like a good plan to me!

You don't get the perks of the RAID controller reporting on drives and telling you which one died and whatnot, but there are easy ways around that.

it sounds like mfi -> mrsas is something i should do at the console rather than 1500km away

Well, not usually. Sometimes some of those things work (drive activity/failure.)

rtprio: I wouldn't do it since I don't want to cause any issues to anybody's server. I found that mrsas performed better than mfi in my case.

the efibootmgr -v line that stock has that i need to get scripted install to have is: Boot0007* FreeBSD HD(1,GPT,...guid...,0x28,0x82000)/File(\efi\freebsd\loader.efi) mfid0p1:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/loader.efi

when i get that working i should have it all done. THEN i can show boss working freebsd replacement for linux and petition for flashing to IT mode and convert to zfs

contrats

l00py: Very nice! What, exactly, are the stipulations for an approved migration to FBSD? Just proving that it will work on that system? Or, is there there some kind of performance or software compatibility testing that needs to happen?

just proving it works. i could already get there by cheesing it in the 'bios' and moving the integrated raid controller 1 entry to the top, but i want to provide perfect match in ux with the stock installer in the scripted installer. so then i can show that freebsd is both a seamless replacement AND automated/unattended install using scripted

bsdinstall

if i can do that he'll let me flash card and put zfs on because you said i can flash back if needed

i already have raid card (perc h710p mini) driver on flash drive if needed for that

so what i gotta do is use the scripted install as it is to find the right efibootmgr line to make it match stock, then put it in scripted install, then done

l00py: Gotcha'. That's pretty nice, then! At least they'll let you replace with FBSD if it can be automated and such. I wish my ${JOB} allowed that. Although, I did sneak in some FBSD installs where I could.

yep ty ty. looks like efibootmgr --activate --create --label FreeBSD might do it going to try

no. efibootmgr --activate --create --label FreeBSD --loader mfid0p1:/efi/freebsd/loader.efi was accepted tho. rebooting to test

booted right! now to add to scripted installer and try a fresh automated go

l00py: Great to hear!

IT WORKS!! ty so much ek, rtprio, mason, mzar, s2r, and tsoome! that's 1 less linux box and 1 more freebsd box in the world now thanks to your help

and now i can try to flash the card into IT mode and switch to zfs. ek since you've done 50 of them mind giving a quick rundown from your experience?

FlexibleRick: \o/

um

l00py: \o/

weird mistab, there

l00py: Sure. I just follow the directions at fohdeesha.com/docs/perc.html and I've never had any problems at all.

l00py: How did the many one-disk raid-0 attempt go?

Especially with the H710p and H710p Mini. Don't tons of them. It's really simple.

mason i didn't try that 1 i just went from getting ufs on hardware raid to now flashing raid card to IT mode for hba so i can put zfs on it. boss said if i could get step 1 working i could go right to endgame

ek ok ty

Alright, good enough. That's the best answer anyway.

and this is compatible with sas HDs right? we got 1.2TB 10k rpm

l00py: Just pay attention to which drive(s) you want to use for booting and you should be fine. If they're all on the same controller, it shouldn't really matter.

ya 8 of them, want just 1 large pool

l00py: If the RAID controller supports it, the "IT Mode" flash will support it.

ok great

You're going to boot from the same large pool?

i was planning to. that bad idea?

most zfs i ever done so far is a mirror on 2 nvme. tips for handling 8 drives very welcome

I wouldn't say it's bad. Just different. Generally, most people would create a ZFS mirror on two (or more) smaller drives and then setup the storage pool on the larger drives. Just to keep things "simple."

Booting from one giant pool will certainly work, though.

hm ok. think i should run the idea by #zfs too for mixed opinions?

If you have 8x 1.2TB disks, I would recommend a RAIDz2 configuration.

l00py: Sure. You can run any ideas through many places. More information never hurts!

i'll read on raidz2 tyvm

Welcome. Have fun and good luck!

:D

(I don't think you'll necessarily need luck. :) )