im trying out rust. i got it working to build bins for freebsd, but now i'm trying to get it to build bins for friends on debian and i can't figure that out. termbin.com/llew thanks for any help figuring out cross compiling!

termbin.com/qhmh has new output, i tried forcing use of gcc with RUSTFLAGS. i think it got me further but now it's saying undefined reference to x... some extern functions couldn't be found

looks like you need to build lld with zlib support

gotta be another way

termbin.com/i31f has more info in it

which gcc native lib has "open64" in it? then i can see if my FS has it

and if so, i gotta pass the -l path in RUSTFLAGS, and if it doesn't exist i gotta find the pkg that has it and install it?

for example an error it gets is undefined reference to mmap64. i searched web and it says that's defined in gnu c lib sysdeps/unix/sysv/linux/mmap64.c. so i searched my FS for that file and it doesn't exist. is there a pkg that i can install that has it?

i already installed gcc pkg but i don't think that's enough?

can anyone get crosscompiling for linux from freebsd working using rust? using any combination of targets and whatever else

You could always create a container (podman), jail (bastille), virtualisation (bhyve) session, or linux compat layer area for linux compilation

ya i just wanna get it working natively with rust's cargo tool. it works for other OSs so we should be able to use it too

my prob is i'm weak with cross compilation, fixing lib path issues, general debugging related tot his

using the musl target i can get compilation to succeed, however the generated file doesn't run on linux. termbin.com/z8in has details

any clue how to fix that up?

nvm, installed cargo-zigbuild and got it working in .1 seconds

fuck me zig is badass

trying to clone an entire disk with "dd if=/dev/da0 of=/dev/da1 bs=1M", things has been running for over 10 hours, barely written 50GB and I'm not even seeing a partition table on da1… i feel like i'm missing something obvious.

If it has written so little in so much time, I'd start doubting the health of the source disk

But I prefer using ddrescue (on Linux, at least); that shows a lot more information on speed of syncing, problems, etc

Alver: it's complicated. this is ona a hyperv vm i'm trying to migrate to a physical disk (which has been passed through to the vm).

i'm pretty sure the source disk (i.e. the vhdx file and the disk it lives on) is healthy, didn't have any problem with reading/writing the virtual disk, got 25MB/s IO even with AES+HMAC and only a single core and the disk the .vhdx lives on being connected through USB.

Oof, passthrough

but to make things even more incongruent, the target disk is an SSD connected via USB. my throught was that inside the vm both just look like any normal disk and a dumb clone should do away with the differences. :P

So VM with disk living on USB, writing to a passthrough disk which also happens to be on USB

Yeah, that's going to be slow as sucking a turd through a straw

Alver: yeah, but if it's not inherently broken, i should see a partition table after the first couple MB, right? writing 50GB and no partition table seems to indicate the entire process is somehow not working to me.

That's what I would expect too, yes

Although you

Although you're technically using the same disk between two different OSes, so one may not be aware of the other until you force it to really look

(on Linux you would be doing a 'partprobe' so the OS checks what really is there, rather than rely on what it knows about the disk by its own actions)

mh? which one? the target disk is unmounted/offlined on the windows host.

Ah, my bad.

you can't select it for passthrough to the vm unless it is.

Well, even then. If I dd a disk on my laptop to another one, I also need a partprobe before the OS realises the dd has added something significant to the partition structure

so either the process isn't working and i'm wasting time waiting for it or the metadata is at the end of the disk for some damn reason (geli, gmirror, gpt, ssd, wtf?)

HyperV doesn't allow concurrent access? Silly. Probably possible in some tucked away setting. But irrelevant here

Alver: no idea, not an MS person. maybe it also allows passing through unmounted partitions, i don't particularly care ^^;

GPT has a header at front and secondary at the end of a disk, iirc, so yes

Any particular reason for the action in the first place? Because I Can (TM)?

Alver: spent all day yesterday creating a rather involved setup with gmirror and geli, didn't want to redo the entire thing on native hardware today.

phryk: what is the underlying filesystem on these drives?

voy4g3r2: ufs.

doh, was hoping zfs.. nevermind :)

zfs send / recv

which reminds me, that i just yesterday stumbled onto the dump command, but i'm not sure it can be leveraged to pull this off.

it should be able to.. i used gpart to prepare a drive

voy4g3r2: zfs on a 1-core vm with 2G memory? yeah, the 1MB/s the dd is doing right now would seem fast then… 🙈

then did that zfs send / recv setup

yeah, but the gpart setup is like half the work.

or rather, gpart, gmirror and geli. and probably some other thing i forget.

my exposure to that is limited to local machines, all physical, so YMMV

but the network connection from one building to another does SUCK and only dd like 4mbit.. dang trees

i tried the dd route with cloning a zfs filesystem and then was told.. that is crazy, use zfs send / recv .. did not want you to have that same experience

Alver: did "camcontrol reprobe da1" which ought to be the equivalent of partprobe, i think. still no partition table. i think this is doomed^^

voy4g3r2: why would it be crazy tho? seems like a straightforward way to skip the work of manually reproducing the exact same partitioning and geom setup.

i'm also pretty sure that i've used dd to clone entire disks before… tho that was physical hdds of the same build/size, if memory serves.

yeah well, my situation they were not the same size and while it can achieve the same goal... the approach they take is diferent

why do assembly when you could do the same thing in c

type situtation

not quite the same. assembly is usually more verbose, but here, the "high level" approach (i.e. zfs send/recv) is the more verbose one because you have to manually replicate the partitioning :P

anyhow, thanks for the feedback, at least i know i'm not completely off the mark in my thinking. :P

no you are not.. i just saw the horus and like.. maybe they did not try that

analogy may have been "off" in my mind. assembly is more verbose and more cumbersome (dd) and c is cumbersome but more abstracted away from those details (zfs)

but will work on that mental model more in the future.

in my mind, one `dd` just looked way less involved than like 3 dozen gpart/gmirror/geli calls. :P

yup, same approach here

then i remember all the times, i had to expand code and make more of it to be more efficient with less of it. it is a mind f*** at times

yeah, i probably should've gone the same route as when i last set up my homeserver: write a shellscript you run from the installer image that does the entire installation. if anything fails, readjust the script, re-execute.

not immediately faster but reproduction of that system sure works within less than 5 minutes :P

that is possible but then i would ask myself the question "How much time would it take to make the script? Then subsequently how often are you doing that?" If the answer is less than the time to do the work.. in a year duration.. manual it is.. write down the steps in a txt file

i do this playing around as a hobby and keeping my skillset up-to-date and this is not my career. It has a side effect of helping me call BS on technology people, saying it is hard and you do not udnerstand

get all if I had a usb pen mounted in /mnt/blah, with it still mounted is there anyway I can can a directory listing for the folder below where it is mounted, I just want to rule out I did not accidentally do a rsync to what I thought was the pen, then remount it over it (I seem to have some disk space missing :))

no i guess

ok dokey

maybe nullfs mount it

?

oh yeah because It wont pickup the mount

nice cheers ketas

:)

UNIX gurus I need your wisdom ...

I need to replace a WORD in an existing file with the *contents* of another file.

the other file is raw quoted JSON so things like sed get very confused

is there another tool that could do this?

i'm not aware of anything good

maybe some templating thing helps :/

yeah trying very much to stay within base tools (this ends up as part of freebsd release generation tooling so we can't have nice things)

I have a sweet simple version already using textproc/jq but now I need to take it back to sed or perl or something

dch awk

[tj]: that is probably the right answer, I have gone 30+ years without reading the awk manpage but perhaps today is the day

thanks!

give me a mo

no actually I don't think I can be distracted writing awk for you today

np, I will have a dig and see what I can find

sed has \r i found

to read i a file

in

or r i mean

dch: it should be easy, but its awk so it won't be

awk too

ketas: r in sed makes this almost easy

sed '/REPLACE_ME/r raw' < json

and today again I avoided learning awk by using sed and perl

the perl version is not nearly so short

but how to get rid of original?

I will modify the json to put the REPLACE_ME on a single line

and then I can swap it in and remove it afterwards

-d ...

good work

yay team BSD++

awk would have been more fun

you only say that because there are nappies to be changed as an alternative

where to put the d?

i can't seem to get it to work

it inserts file after that

sed -e '/1/r b' -e d < a

sucker replaces entire linr

line

sed -e '/REPLACE_CAPABILITY_DATA/ {' -e 'r raw' -e 'd' -e '}'

just use a block

doesn't do ig

it

:/

ketas: which freebsd version are you trying this on?

echo raw > raw; printf 'before\nREPLACE:garbage,\nafter\n' | sed -e '/REPLACE/ {' -e 'r raw' -e 'd' -e '}'

works fine here on CURRENT

awk '/1/{while(getline<"b"){print}}' < a

same

13.4

aah that might be the reason

same in current

what

none of this works

in 13.4 nor current

:garbage is also gone

yeah thats fine, sed is line processed so i expect the garbage to go

ketas: what does `which sed` tell you?

I switched to /bin/sh and using /usr/bin/sed this works fine here

echo raw > raw; printf 'before\nREPLACE:garbage,\nafter\n' | sed -e '/REPLACE/ {' -e 'r raw' -e 'd' -e '}'

even works on a 13.0 (best I can get) here

it's one from /usr/bin

echo raw > raw; printf 'before\nREPLACE:garbage,\nafter\

n' | sed -e '/REPLACE/ {' -e 'r raw' -e 'd' -e '}'

before

raw

after

?

you say it works there?

exactly like that, /bin/sh

same result in sh

you get raw:garbage?

that would be fun then

no, just raw

the garbage is dropped because we are operating on lines

that's what i was saying

how to replace within line tho?

I will get the releng bit working, and then code-golf this evening on that bit. it will definitely come in handy in future.

file a has "-1-", file b has "333", how to get "-333-" ?

:}

:)

hah code golf is actual term

if perl is available, \Q$str\E

meh this problem has no solution?

surely i could get it done but...

here we go.. signal-desktop has been eluding me...

what's the *clean* way of copying over an entire freebsd to another disk, mostly worried about special flags like noschg. otherwise, cp -a seems fine…

when there's a non-unique gpt label, the partitions with those labels disappear from /dev/gpt – how do i refresh that after fixing the name collision? "camcontrol reprobe" on the affected disks doesn't work.

service devfs restart also doesn't do the trick…

cpio perhaps? Not sure if it retains everything

vkarlsen: if i read the man page of cp right, -a implies -p which *should* preserve "modification time, access time, file flags, file mode, ACL, user ID, and group ID, as allowed by permissions".

guess i'll just do a test copy with noschg

phryk: Yep, I'd test it first too :)

schg seems to be copied over fine. maybe my brain is just mixing up memories from trying to mv something. ^^

phryk: if you're on UFS (IIRC you are) use dump/restore, `tar xvpf` so you get hardlinks as well. there's probably a cpdup or cpio .

I don't think cp will do hardlinks

Yeah, to cp hardlinked files are just separate files.

yeah, just man cp confirms. thanks dch. the -P of dump/restore looks a bit sus, but i'll guess i'll read up on that.

dump/restore is quite reliable and robust.

yeah, i'm kinda baffled i just stumbled onto it yesterday for the first time.

sounds supremely practical.

holy shit i am an idiot.

phryk: any issues with backups /

?

i already set the system up with gmirror. and geli is *on top* of the gmirrors. so i can just do the partitioning and add the partitions to the mirrors and wait for the sync to complete. how did i not see that? :D

mzar: ironially while setting up a system for backups :P

phryk: docs.freebsd.org/en/books/handbook/book/#backup-basics will have complete examples

oh yeah gmirror would do it too

nice move

you could also do this with iscsi over the network

yeah, i already set it up with gmirror even tho it's just one disk because i'm very much advocating for disk redundancy for the official company backup server :P

dch: btw, a couple days ago i was already writing you a query and then answered my own question: prometheus belongs on the host and not a jail so it can report jail failures. :P

lol

Generally I am a huge fan of rsync which is an excellent general purpose tool.

But on FreeBSD you /should/ be using zfs and in that case you have zfs send|recv available to you and that is the best.

+1 if you're serious about data integrity, then zfs is the only choice.

rwp: i actually (mostly, still have do redo one setup) migrated away from zfs. too much pain, too many issues.

I have the best data recovery stories btw

I have a data recovery story where zfs pulled me out of the fire too.

phryk: I still don't get how you ended up with this opinion, zfs is so much better than any filesystem I've used at scale that its not funny.

i've done some crazy heart surgery too, both with and without zfs. i guess i'm a bit wasteful with just outright disk mirroring but it's saved me numerous times.

Definitely adding disk mirroring or any RAID redundancy level is significantly better than running on one storage device and counting on recovery from backup. That's no doubt.

dch: that might actually be the difference. i'm managing *counts in head*… 11 disks overall in my personal infra. zfs just had entirely too many footguns for me.

And definitely gmirror for mirroring is a good thing. It's the default for swap partitions and works solid.

("that" being scale)

But for archival data and for large arrays then zfs is another significant step up in reliability, scaling, and features.

rwp: interesting re swap. i haven't used swap in a long time, but this machine is probably gonna be so small it needs it, so i was wondering: two disks, two swap partitions: gmirror them for faster io or keep them as separate swap entries in /etc/fstab?

As far as footguns zfs really tries hard to be safe. I have screwed around with things quite a bit and zfs has often avoided being a footgun for me.

swap is also useful for coredumps. phryk with that in mind I go for encrypted mirror swap, under the assumption swap is rarely used

Regarding mirrored swap, if you want the system to keep running through a storage device failure then you must mirror swap. If you are always going to power down then it does not matter. But I want machines to keep running /through/ a storage failure. So I always mirror swap.

so performance is less important than integrity

There is almost no performance penalty on today's faster cpus for using .eli for swap so always use ephemeral encrypted swap.

rwp: i have had around a dozen zfs setups over the years and the one i currently have at phryk.net is the first and only one that didn't completely suck. i've had sooo many performance issues. like ridiculous <1MB/s read speeds on fully mirrored disks and oh so many weird issues with automatic mounting not working or randomly stopping to work…

yeah, with aesni, everything except /boot is encrypted. and that will follow as i have a vague memory that encrypted /boot has been possible for like a year now.

Maybe you are simply cursed? Have you pissed off any wizards or devils?

rwp: same disks worked extremely fine with ufs. wd reds mostly.

Definitely a curse then.

I wonder if you got those shitty shingled disks

good points about disk failures on non-mirrored swap tho. gonna mirror it, thanks for the hint.

they are complete pants with zfs

Even the WD Red disks slipped in some SMR versions before they got caught doing it.

shingled? you mean the ones where they cram more bits into the bits?

i have all traditional write disks, 1 bit per bit, don't recall what it's being called.

CMR Conventional Magnetic Recording

ah yeah, CMR vs SMR.

yeah, my wd reds are all CMR. the ones i used when i still did zfs where older 2TB ones. got 2 newer 4TB ones installed a year or so ago and 2 more of the same laying around waiting to be installed.

It seems that the quarterly binary pkgs have updated today. Which includes the binary pkg radeon driver that I use on my desktop. I get nervous because I know those are decoupled from the kernel and I have tripped on that snag before.

Saying older 2TB makes me think of another snag which is an incorrectly matching ashift because before the 2TB disks most were 512 byte physical sectors and after were 4K AF Advanced Format sectors.

Having an incorrect ashift=9 when ashift=12 is needed for 4K AF can be a huge performance hit.

And with new SSDs that ashift might need to be ashift=13 or perhaps even ashift=14 in order to avoid the write amplification problem.

rwp: yeah, went through the entire dance and reformatted one disk with the fixed ashift, let it resilver then reformated the other disk, no big improvement.

I haven't done the testing myself but I need to become familiar with that NAND flash benchmark tool (I forget the name) which can be used to deduce the internal block size of NAND flash storage.

also my disks definitely tend to get full and fragmentation is a bigger performance hit on zfs than other filesystems but zfs people constantly dismiss this being a problem ("just buy more disks lol") and thus there isn't even a defrag tool.

i mean, i'm already a bit sad that ufs has no defrag tool, but i haven't noticed any performance hit from the disk just getting full.

ufs does defragmentation in the buffer cache

hmm you can't have vdevs with different ashifts, so the only way is send|recv of the whole pool

i have no idea what that even means. fs internals have always been black magic to me.

phryk: then why make the first comment?

dch: yeah might not have been a resilver. i vaguely remember figuring all this out was a week or two full of frustrations.

phryk: yes we have all been through this, its very frustrating to hit it

[tj]: because i noticed the difference without knowing the internals?

and I still don't really know how to tell the actual blocksize of storage from vendor spec sheets. no idea why they make it so opaque.

[tj]: maybe i'm just fundamentally misunderstanding fragmentation. my understanding is that over time fragmentation accumulates and at some point will definitely affect performance.

"at some point" might take many years, but eventually the head will have to jump to a different position on the disk after every block, chunk, inode or whatever the right term is for a unit of read/write.

phryk, I've heard it it often repeated that fragmentation on a multi-user OS can actually be a good thing, as it provides an artificial interleave to help spread disk access between processes.

CrtxReavr: I'm not sure I understand. What would a disk with 0% fragmentation mean in this context? That it takes longer for cpu-threads to be switched between processes?

mzar: thanks

for what ?

mzar: audio/virtual_oss reference

has it solved your issue ?

still working on it

Ober: some somftware like internet browsers tend to use pulseaudio

pulseaudio allows you to switch input/output with pacmd(1)

hey all where can I get a list of all possible kernel options devices etc for a stock 14.1 RELEASE, I thought LINT+NOTES but apparently not :) might have changed over the years

Ober: wiki.freebsd.org/Sound#virtual_oss_.28advanced.29

When I see something like this in the logs it makes me wonder if there is an atomic write problem. "Jan 10 09:24:12 madness kernel: <6n>fns fsse rsveerrv er hhyysstteerriiaa:://hhoommee:: nnoott rreessppoonnddiinngg"

if signal uses electron why does it even have an EOL clause

and man .. it only uses 1 cpu to compile in ports.. boo

voy4g3r2: I agree it’s a pain as it breaks too often because of it

Mine is also broken right now

Periodically breaking is making me consider alternatives

phryk: one of my rootfs copy scripts does: chflags -vv noschg /dst/var/empty && tar -cf- -C /src . | tar -vxpf- --clear-nochange-fflags -C /dst

\sfqsl

oops. Wrong layout