So is the xorg xserver package like maintainer timeout?

So.. I'm installing on this system with three SATA devices - a hard disk, a smaller SSD and a small fast msata card. I figure I'll boot from the SSD, perhaps use the MSATA as dedicated swap, and the HDD may disappear in the future...

But regardless of where things are plugged in, the HDD always seems to show up as ata0. Is there a way I can "pin" the SSD and msata device to ada0 and ada1 respectively? So that whatever else gets added or removed leaves those two in the same position?

this question came up before, and i don't remember what the answer was

ghoti, I have a system which after installing I needed to rearrange disk drives. The daX device names followed the disks regardless of which SATA port they were plugged into. I did not expect that.

So... I deduce that this information is somehow stored on the drive data area somewhere.

Meanwhile... Instead of using the adaX names anywhere, use gpt labels instead. Those you can set and will definitely follow the drive.

Since I have identical drives I created gpt labels with the drive serial number embedded so I could easily map one to the other.

rwp: I've never use gpt that way... Are you suggesting I can simply replace /dev/ada1p2 with /dev/gptid/<mumble> in /etc/fstab and "it will just work"?

ghoti, Yes. Almost. /dev/gpt/mumble will work. Or if you are using ZFS at least I know gpt/mumble works.

ghoti, Example from here: bsd.to/Sj16/raw

Title: Sj16

"gpart show -l" will list the current labels. The installer sets up numbered labels such as bsd.to/4idq/raw

Title: 4idq

If those are okay then great. Otherwise can use "gpart modify -l newlabel adaX" to change existing ones.

Using GPT labels requires GPT partitions of course. But that's typical these days regardless. And then there is no concern over the ordering of adaX assignment.

There is a previous disk label technology in FreeBSD that is now considered obsolete. Searching around you might find old docs on the previous. Best to be aware that the old method has been used but is now replaced by the GPT label method.

The other hint I will provide is that the kernel allows only one access method at a time. As soon as /dev/gpt/mumble is used then all other alternate paths are no longer available. And the reverse. So as soon as I configure /dev/gpt/mumble then /dev/gptid/otherid disappears and is unavailable. It's only singleton access allowed.

rwp: That's bitten me hard in the past.

I should probably write this up in wiki form as an explanation rather than leaving it in a bug, but RhodiumToad was kind enough to inject some clue when I first encountered it. bugs.freebsd.org/bugzilla/show_bug.cgi?id=230246

Title: 230246 – GPT label mishandling

Hi, i am at the shell prompt inside the freebsd dvd boot iso. I want mount a pendrive that has two partions, which in Linux showed exfat, but here fdisk /dev/da1 for da1s1 shows (NTFS, OS/2 HPFS, QNX-2 (16 but) or Advanced UNIX).

How do I mount that partition

mount -v /dev/da1s1 /media throws Invalid fstype: Invalid argument

Same with mount -t ntfs or ntfs-3g

gpart show

mount -t msdosfs /dev/da1s... /media

otis: thank you, will try that :)

I think I'd did that i still got the same error, but nevertheless will try again to be sure

what filesystem is it sozuba ?

rtprio: exfat

I've booted into Linux now

is there a way to determine which make (bmake, gmake) is running a make file? I'd like to make my make file abort if run with the wrong kind of make

not really

GNU make has internal variables MAKE and MAKE_VERSION, you might be able to guess from MAKE_VERSION

crb, on my system "make --version" returns nothing, while "gmake --version" returns strings about GNU, GPL, FSF

maybe also use the strings command on the binary, grepping for GNU

Anyone knows how does FreeBSD boot on ARM64 systems?

it does boot up;)

antranigv: at least on RPi: u-boot, uefi, loader, kernel

UEFI! I need UEFI!

damn itttt

best up to date resources to learn everything about jails and especially using them as a foundation for containerized web apps?

docs.freebsd.org/en/books/handbook/jails for sure but anything else?

Title: Chapter 16. Jails | FreeBSD Documentation Portal

polyex well, you can ask here

polyex I've been running everything in Jails for years now

polyex sadly, the Handbook Jails is not completely up to date with latest awesomeness, but I'll try to update that too.

antranigv ty. what are the main awesome things with jails the handbook doesn't talk about yet? and ty for updating it whenever you can!

polyex the VNET part is not documented that well. here are two blog posts of mine to get you started with VNET jails. weblog.antranigv.am/posts/2020/06/vnet-jail-howto and weblog.antranigv.am/posts/2021/04/2021-04-20-07-02

Title: VNET Jail HowTo | Freedom Be With All

There are very modern Jail managers, I recommend checking out Pot github.com/bsdpot/pot , BastilleBSD bastillebsd.org and the one that I wrote, called Jailer github.com/illuria/jailer

Title: GitHub - bsdpot/pot: pot: another container framework for FreeBSD, based on jails, ZFS and pf

Note: Jailer is basically a Jail.conf wrapper, it doesn't work like a service. and I'm updating the code right now for more features. And the docs are very bad :D

polyex P.S. to be clear, I mean documented in the handbook, otherwise everything is documented very well in the man pages.

at some point i had some much headaches with all jail tools and managers, so now, i trying them from scratch, courtesy of dch and his guides

ty! btw why use a jail manager? reading the handbook it looks REALLY simple to directly set up jails

antranigv ^

polyex personally I created Jailer for my company, I needed a Jail manager with a JSON output, ZFS manager and pf integration out of the box.

and for the others, well, everyone has their reason :)

pf integration extends jail networking so they can have their own pf rules separate from host?

polyex with VNET Jails can have their own rulesets. yes. In Jailer, we just automate some things such as ./jailer nat add j0; or ./jailer rdr add -i vtnet0 -a my.second.ip.addr -p tcp -r 80 -d 8080 jail0

antranigv why do you need zfs manager integration?

FreeBSD Handbook says: To make USB storage devices "mountable as a normal user, one solution is to make all users of the device a member of the operator group" and then allow that goup to mount 'da*'.

Do I necessarily have to use the group "operator" for that?

I guess not.

I'm askin because I'd like to create a new group just for that purpose.

polyex so I don't have to manage it manually.

antranigv sorry i'm dumb but what's there to manage? if host has zfs then the jail just gets a dir and that's it no?

polyex there are no dumbs here :)) well, I have a seperate ZFS dataset for each jail, which gives me the ability to do things like zfs rollback zroot/jails/j0@when_it_was_working

nice!!

antranigv ok last q, why json output? and doesn't freebsd already have support for other format output in commands? libxv or something?

yes, libxo, for cross-output. We use Jails in our products, so we needed some outputs that `jls` can't do out of the box

polyex for example, default gateway, which bridge it's connected to, etc etc.

default router**

No one's using gateways.

i thought gateway and router are synonymous but no?

Only sloppily so. . .

A router passes traffic of the same protocol between broadcast domains.

they were back in the 70's but later divided in meaning

A gateway translates traffic between networks speaking different protocols.

Pretty sure you're only dealing with IP.

Early in my career, I dealt quite a bit with IP to IPX/SPX gateways.

tyvm

antranigv: isn't the setup in weblog.antranigv.am/posts/2020/06/vnet-jail-howto incomplete? I don't see where something is connected to the bridge.

Title: VNET Jail HowTo | Freedom Be With All

SKull: at this line exec.prestart += "ifconfig bridge0 addm epair${id}a up";

mage: Ah! Now I see it. Thanks :)

Bitter that the complaint about documentation for vnet jails comes from 2020 when I had wiki.freebsd.org/action/info/MasonLoringBliss/JailsEpair up the year before that.

Title: MasonLoringBliss/JailsEpair - FreeBSD Wiki

zfs in 13 doesn't require opensolaris onymore?

wow

why opensolaris still in system?

Title: Solved - From 12.2 to 13.0-RC2 : do I need to keep opensolaris.ko ? | The FreeBSD Forums

> opensolaris.ko is not needed anymore

> it will not be used anyway.

so why it is in base yet?

clearly to upset you

very funny

mason: i've never felt that it was badly documented. I mean, I didn't really understand it for a long time... But not for lack of proper documentation.

hahahahaha...

VVD: why do you say opensolaris is not needed anymore?

why do you think that?

Title: Solved - From 12.2 to 13.0-RC2 : do I need to keep opensolaris.ko ? | The FreeBSD Forums

it was quote

SKull: No, no, just saying, antranigv's article notes a Twitter post from a year after I started documenting how I do it.

Frankly the more the merrier for documentation.

is make.py just ignoring my --cross-bindir and building a bootstrap LLVM??

mason, Yes. It's tripped me up too. When things automatically happen it leads to trouble. I have learned to always wipe off any signatures on storage as I go.

If I have to rebuild something then "zpool labelclear -f gpt/foo" and "gmirror stop foo" "gmirror clear gpt/foo" are required to prevent them being automatically started undesirably.

rwp: If I were a really good person I'd figure out how to get GEOM to untaste things.

That would be wonderful! But even better would be to prevent it tasting things in the first place and avoiding the problem from the start!

More workarounds: I often live-boot refracta and then use the utils-linux utility "wipefs" to search and clear unwanted signatures.

Does such a utility exist in FreeBSD to clear structure signatures from storage? I can't deduce an equivalent. Beyond dd'ing over the entire drive.

rwp: hrm

Oh! util-linux is in ports. I was looking for wipefs but completely missed that it was in util-linux already in ports. I'll try that next time.

Does it know about FreeBSD-specific signatures?

Still wouldn't help once something has already been tasted.

Well... It knows about gpt and zfs signatures at least for certain.

Maybe I'll add that on my vapourware projects list anyway. Anything that requires a reboot to recover from is worth attention.

s/on/&to/

Agreed. Automatically tasted something and then needing to reboot to get the taste out of the mouth is not good.

I rather want to test "wipefs -n /dev/foo" to see if it lists all of the FreeBSD signatures specifically gmirror signatures but don't have a victim system where I can risk it at the moment.

Oh, I might.

Half a sec.

Sounds like a job for a throwaway VM.

Eh, I have hardware I can risk.

Yes. But it needs to be a VM with specifically a gmirror running.

Mirrored anyway so worst case it blows away half a mirror.

This has gmirror *and* GELI *and* ZFS.

I just ran it on a gpt and ufs based VM and it did not report any signatures. Hmm...

rwp: Not wildly chatty: bpa.st/S33IA

Title: View paste S33IA

Hmm... I am also getting "wipefs: error: /dev/vtbd0: probing initialization failed: Operation not permitted" on the VM too.

So maybe dd is the only way. But that's a painfully long time to wait on larger storage devices.

And that does not address the problem that the device will already have been "tasted" and therefore a reboot is needed to clear things. :-(

mason, Thanks for connecting signatures, singleton access, and specifically GEOM tasting all together as related. The dots were not all connected in my head yet.

Happy to help.

hi. question: can i use ports(7) for local dev? - ie. clone the git repo for i3 wm and use the ports tree for installing needed dependencies + freebsd-specific patches?

Probably no need, unless you plan to submit and maintain the port.

It's also not a good idea to install non-ports things to your ports prefix (/usr/local/ by default).

what's the recommended workflow for hacking on already ported projects? git clone the upstream then install all deps manually?

I've usually copied the port dir to .bak

Then build the new version in the original directory.

Get it working and tested, build a patch with diff -ruN

File a PR.

Usually share the patch with a few friends for testing, prior to the PR.

interesting...

thanks for the help, trying to understand...

what if i were an i3 developer / contributor? (i'm not)... so not just porting, but working on new features or bugfixes in a local repo?

I'm not a good person to ask about that. . .

Overwhelmingly, it's a linux-centric world, so our ports have an upstream. . .

I would assume i3 has has a git repo you can submit patches to and submit a PR to to them.

crb: to make Make fail if you have the wrong make, use features that are exclusive to the Make you want. Otherwise, most Makes have some kind of indicator you can test, but I'm not aware of anything standardized.

ajr: perhaps some context around why ports exist would be good; when they were invented (see cgit.freebsd.org/ports/commit/?id=d27f048e966a8ab178), there was no such thing as third-party software repos. Instead, you had to manually find the software, download the tarball, extract it, read the INSTALL file and follow the instrustions (usually quite carefully), and because the developers of the

software didn't widely test their software, you usually had to patch it manually to work on FreeBSD.

There's nothing that's substancially changed about it since then.

FreeBSD uses the ports framework to create binary packages, but that doesn't really change ports themselves, it only means you don't have to compile the software if you're happy with the defaults.

debdrup: and they handle errors in the patches, and dependencies from other programs/libraris, etc

Kalten: yes, I was getting to that.

You can save the options you choose,

Please stop.

If you want me to...

I suspect debdrup doesn't need ports sales pitches or lessons. ;)

A port is a Makefile with information on where to find a particular software (along with a checksum) as well as information on how to build it (including, optionally, building it with different features enabled or disabled), and a list of patches to make the software work on FreeBSD (usually this is only needed if upstream is recitant to accept patches from people porting software).

I'm not sure it's possible to retrofit it so that it can be used for development the way you want to, but I'd also like to think that any developer with enough interest in porting wouldn't need the set of patches required for it to build.

debdrup: can i override tarball download+checksum and point it to a local git repo dir instead?

ajr: not easily.

the do-fetch: target can be anything you like, though.

I mean, yes - but it usually requires some sort of tarball, whether it's the product of a CI pipeline or a release process.

The MASTER_SITE macro generally points to an URI for that tarball.

So in addition to the local git repo you'd also need the CI pipeline to generate build artifacts from which to work on.

debdrup: the various ports that download particular github hashes grab archives because it's convenient, but I see no reason a local port couldn't `git clone` a particular hash and have just the same idempotency..

ghoti: ports don't require anything that isn't in the base system

but if one is using the ports system for a private solution, all bets are off.

They'd need git, svn and a bunch of other VCS' to account for all the ways that the source tree could be grabbed.

And also, build dependencies.

Distfiles, for all their problems, have two simple and expedient properties: They're fixed in place, and they have a checksum associated with them.

Using a VCS branch as the source of truth for some third-party software seems like an exercise that'd result in porter burnout.

ghoti: I don't have the history of what you're pointing to, only the pointing. :(

michaeldexter: ^5 is IRC speak for high-five. :P

Gawd I'm old. Um, high 5!

I think that one's origins are in gaming chat, but. . .

It works in IRC too.

Are we celebrating something?

It's usually just a greeting.

CrtxReavr: I'm pretty sure I've seen it on USENET going back to the time when online gaming consisted of play-by-mail systems.

I would also be shocked if it hadn't been heavily used on BBS' and MUDs.

I don't remember it going that far back.

I'm using the mrsas driver on thisAVAGO Invader SAS Controller. and when I insert a new drive, I'm told: kernel: da8: 150.000MB/s transfers <== that's for an SSD which smartctl reports as: "SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)" - so what's up with the 150MB/s == 1.2Gb/s

dvl: is it _any_ drive that it classifies as SATA 1?

Also, what are the speeds you're getting from it according to `diskinfo -cit`?

...don't run that if the drive has any data on it, actually

I assumed it was a blank drive, but that doesn't seem like a safe assumption now that I think about it

where's my zroot gone?

;)

Well, hopefully it wouldn't be on the 9th disk inserted.. :P

debdrup: Not sure if this answers your question, but the above drive is a WD Blue 4TB, and with another INTEL SSD as well.

Both have 150MB/s

150MBps according to CAM?

debdrup: Yes, I guess that's CAM printing that kernel message?

Do you have a spare SATA port on a controller that isn't the SAS controller?

Yes, that's CAM.

bin.langille.org/?13f9dfc384dc584f#…JA4hGXhP4UR2TThbgRYyEzNkNnsEyUzxY4d <-- diskinfo

Title: PrivateBin

No, everything on this Dell R730 is the SAS controller. I have two SSDs in PCIe slots and they register as ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)

Are there other disks attached to that SAS controller?

Yes, and they are all 150.000MB/s

That paste I sent you: convert 466825 kbytes/sec to Gb/s => 3.7346

Perhaps, and I hope this is the case, the mrsas driver is just reporting incorrect values.

kB to Gb?

Or do you mean 3.7346GBps?

Yes, that's the conversion I did. to Gb

Gb != GB

Agreed. It's also 466.825 MB/s

It's still ~466MBps, which is a lot faster than the reported 150MBps from the kernel.

^ agreed

So I'm tempted to say that it's mrsas(4) causing it to report the wrong values.

Why that is, I have a hard time saying.

Since they're two different disks from two different manufacturers, it might be the SAS controller itself.

Could try not loading the mrsas driver and compare.

dmesgd.nycbug.org/index.cgi?do=view&id=6657 this also shows the same 150MBps value from CAM

Title: NYC*BUG dmesgd

Well, that might be mine

Are you rsr?

No, I'm not. :)

I thought I uploaded mine there, guess I didn't

dmesgd.nycbug.org/index.cgi?do=view&id=4266 this one is by mohr@ from 2018

Title: NYC*BUG dmesgd

That's almost certainly not you :P

Oh, mohr@ isn't a committer.. Regardless, I'm pretty certain that you can disregard the media speed reported.

Well, you can file a bug for it.

But I think it shouldn't matter for the purpose of bringing up your new toys ;)

8)

It looks to me like the Invader card is a RAID controller, though - so maybe keep an eye out for a proper SAS controller that can do IT mode

There's no equivalent of mfiutil for mrsas, is there?

debdrup: It does do IT mode

dvl: have you flashed it with IT mode firmware, or is it telling you that it's doing IT mode while secretly putting each disk in a raid0 of its own?

These were used at $WORK. I am not sure if they were flashed then or not, I suspect we ordered them with proper HBA.

I wish I knew of a way to check, other than to use a known-good controller and hd(1) on the character device.

I just commented out mrsas enable and I'm rebooting. Just to compare. I had saved that dmsg output I think but cannot find it now.

I'll just go into single user mode

Is it better to populate /etc/fstab with devices from /dev/diskid/* or /dev/gptid/* ? Is the former deprecated?

One is disk idents from CAM/GEOM, the other is GPT IDs - they're entirely orthogonal.

debdrup: Booting with the mfi driver, no transfers speeds are mentioned.

You can also use GPT labels via `gpart label` or GEOM labels via glabel(8).

dvl: huh.

dvl: well, the media speed shouldn't affect the speed of the actual data transfers anyway; I remember an old bug where some driver (possibly bge(4)) would list 100BaseT despite transferring at 125MBps using UDP.

media speed isn't some sort of bandwidth limitation

debdrup: my goal is simply to stop mounting the devices by driver name, as that may change as new devices are added. I gather both of these (diskid and gptid) will solve my immediate problem (the changing name of mountpoints). What else should I be considering?

ghoti: Is this a problem you have encountered?

ghoti: I'd suggest GEOM labels, as they can be named after ther serial number, bay location, and other salient information.

ghoti: Or is a problem you are anticipating?

dvl, right now, yes. I'm installing on a new machine that will be losing its ada0 shortly. Try as I might, I couldn't get that disk to name itself ada1 and leave the boot disk as ada0. Alternate naming to the rescue.

mind you, I'm looking at this from a ZFS point of view, where device names shouldn't matter. Or am I missing something?

I am in UFS right now. ZFS wouldn't be a problem.

Until ZFS vdev properties lands in the version my server is running, I'm gonna continue using GEOM labels.

debdrup: thank you. I see the label can be customized as well. That may also be helpful.

btw, is vdevprops(7) missing or is it just me somehow?

i see it linked in zpool-set(8) but man page isn't there

yuripv: seems like it's missing. it probably should be added to cddl/sbin/zfs/Makefile.

yuripv: Someone forgot to add it to the Makefile

No, it should be added to the upstream.

debdrup: I think that's a local thing.

sphex: if a manual page isn't defined by the FreeBSD build system, it won't be included.

The build system for the openzfs-docs likely works differently.

ffs this is the third computer i've touched this week that panics on me frankly its getting tiresome

dch: Why are you worrying these computers so?

mason: i don't know! 2 of them will panic as soon as I run poudriere or any other cpu intensive make-like actvivity

which is damned inconvenient

dch: Heat maybe? My last workstation jump was because trancoding would freeze the system.

I did some programmitic mitigations but it was tedious enough for me to want to jump ship.

30s isnt enough to get too hot

Could be, depending on what's failing.

more like 5s probably

Only plus side there is that a panic at least offers the possibility of diagnosis.

Panic String: Assertion VOP_ISLOCKED(vp) failed at /usr/src/sys/fs/tmpfs/tmpfs_vnops.c:388

welp

Ah, that doesn't seem heat-related at first glance.

oh my, zpool: install vdevprops(7) man page #666

dch: This isn't -current is it?

mason: it is, but a bit old, I should bump

dch: That seems like the best bet.

dch: are you running -current on 3 computers?

no, let me think. I have 2 with BETA2 that are being awkward, desktop is current as is this laptop

got some fixes in beta1 & beta2 that need testing

yuripv: have you ever heard of gematria?

no idea why is this number so widely spread in a specific context most people use

dch: seems like there was an overly assertive assert that got deleted in tmpfs recently

angry_vincent: nope, i just love the number :D

yeah at least 3 new ones sphex

yuripv: in bible it was just a Nero, the emperor. is how 666 encodes his name

heh I wish freebsd had "non-lethal" asserts. just print a stack trace and move on. for desktops and the like where you'd rather it tries to keep going even if it risks going bonker because the bug is real.

id far rather clean up after an assert than hand-edit a filesystem back to a usable state

and that was in the old days, when filesystems were simpler

speaking of simpler, how hard would it be to take the fuse.exfat and make a real freebsd kernel module from it

hoping for better performance?

that, and perhaps a kernel programming exercise

sphex: you could implement your non-lethal asserts with libunwind if you only need them in userspace?

utx.log begins Wed Feb 1 09:01:49 EST 2023

Where do I tweak how long that retains login info?

CrtxReavr: newsyslog.conf(5)