(because POSIX says so)

It used to be that POSIX was not a design by committee document but was instead a standardization of existing practice. Basically an operating system feature nonproliferation treaty.

I wasn't aware that I could have printing without cups.

right, but in this case it standardized lp rather than lpr :-)

The standards are mostly just a description of System V.

RhodiumToad, I am

but this printer works with standard subroutines built into computer's BIOSes

sfox, Sure! CUPS is the "new" (in the grand scheme of things) Apple dynamic configuration printing system.

and works with DOS

uh, no BIOS that I ever used had any printer support

sfox: do you have an lpd process running?

That BIOS comment throws my head into a tizzy too...

RhodiumToad, it's called printscreen. it's what that button is supposed to do on PS/2 & compatibles

sfox: and/or lpd_enable="YES" in /etc/rc.conf ?

i did not

thankyou, i will look into that

PrintScreen is an OS feature not a BIOS feature. Though in DOS it was usually a TSR terminate stay resident routine

don't enable it if you weren't using it before

is there any way to make the printer available over the network without cups too?

lpd supports remote access as I recall, but it's ancient and useless with most modern printers

Yes, I've done remote lpr/lp printing before with an HP printer, ages ago

rwp I have a laptop here from which my friend wrote a bootsector hex editor for REAL mode. When you press printscreen button the printer goes to work.

by ages I mean a couple years ago

Never did non-remote printing with lpr or lp, actually

sfox: that says nothing about how you're expecting the printer to work from within freebsd.

only over the network

sfox, Does it boot that program or is that program invoked from DOS?

I was talking to rwp about the BIOS feature. rwp, it's booted from a raw floppy.

Booted what exactly from a raw floppy? DOS? Probably. I am thinking it is booting DR-DOS, MS-DOS, or FreeDOS from a floppy.

the hex editor that was written in assembly

in a bootsector

it. doesn't. matter.

how you use the printer in freebsd is not in any way related to how you use it in any other OS

rwp we should probably take this to private message for further discussion on how it's implemented. I think it's annoying RhodiumToad

Agreed. It's OT here. We should be in -social or something talking about museum pieces.

seems like tracking latest pkgs isn't any less stable than quarterly because quarterly pkgs sometimes have problems too, and when latest pkgs have problems they get fixed faster. am i wrong?

latest gets more updates

this sometimes means that security fixes take longer because the latest package set is taking days to finish a build cycle

security fixes sometimes hit quarterly sooner than latest?

If it is a security problem then that will get fixed as an errata. Or at least should.

in terms of the package repo rather than the ports tree, the quarterly might or might not be faster, it's dependent on the build cycle

Mostly there is nothing that I use daily that I want daily changes. All of that ends up being wasteful thrash for me. Disruptive to me.

well my thing is i've run into broken (temporarily) packages on both quarterly and latest. but another problem i've had is quarterly packages taking a long time to get a version update i wanted. so it feels like latest is better than quarterly

for me

Can you give an example of a package that you use that you enjoy getting the daily changes? No judgement here. ykinmkbykiok. Just curious.

i didnt say anything about daily updates. when there's a new version of something i want, it obviously hits latest faster, rather than having to wait up to 3 months like on quarterly

if you want control over what you get, then build your own repo

ya i dont wanna do that. yet anyway

otherwise if you want latest, then use latest

I use quarterly but probably should switch to latest. I trust software devs to know their own software best.

my only concern about latest is with quarterly, i can provision a few servers over a few hours and know they all have the same or pretty close versions, but with latest a package could be updated in between those servers getting provisioned and end up with pretty different versions between them

bit more of a moving target

well yes

if you want to avoid that you'd have to maintain your own repo

Yes. That is the way latest works. Always in motion.

I'd like to network my mail server over High Frequency radio, does FreeBSD still support UUCP?

sfox: freebsd-uucp package

thanks

I think that was way faster than rm: rsync -a --delete /empty/ /usr/ports/ 0.30s user 3.84s system 5% cpu 1:18.47 total

oh, cool!

sfox: I hope for your sake nobody sends you a PGP encrypted email, or that your mail daemon isn't configured to support TLS or any form of encryption..

When having a PF rule in FreeBSD like "block in from no-route to any", should I remove the other line of mine related to that; nonrout = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4, 255.255.255.255/32 }" (and block in quick on $ext_if from $nonrout to any + block out quick on $ext_if from any to $nonrout) ? Does having "block in from no-route to any" do that all?

I think they do different things. RFC1918 addresses (private/not globally routable) may still be reachable from your host, and public addresses may still be unreachable from your host.

hi, i've got a freebsd installation that was forgotten for some time… can i freebsd-update -r it directly from 12.2 to 13.2, or do i need to take the/some intermediate steps too? (can't seem to find any mention of that in docs.freebsd.org/en/books/handbook/cutting-edge)

what's the version string for freebsd-update to upgrade to 14? 14-LATEST?

it's not supported

(and man page says that)

freebsd-update can only update to releases and CURRENT has no releases

so, to upgrade i download and mount the boot image for 14, extract kernel and base.txz over my mounted system and reboot?

yuripv: that person seems angry

phryk: or else, build

(usually, at this point i would advertise my PkgBase repo, however, that's defunct)

if i want to built-in a kernel module, do i put 'device linux' etc. in the kernconf ?

gzar: yeah. that's how i did it at least.

alright, i'll try

gzar: not sure which arch you are on but this is the generic conf: github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/GENERIC

Title: freebsd-src/GENERIC at main · freebsd/freebsd-src · GitHub

i know, i am modifying that one

do i include the `options COMPAT_LINUX` or can i just leave it out

also this: man.freebsd.org/cgi/man.cgi?query=config&sektion=5&format=html

Title: config(5)

thanks thats what i was looking for

gzar: it's already there in the generic one

yeah but idk if its necessary if i am causing the module to be built-in

(the question read to me like compiled in linux support is wanted, instead of the default of a loadable kernel module)

yes exactly

ah yes, sorry.

what benefit does that give? faster boot time?

i want to check what happens if i compile it in and then try again compiling with gcc. it should do something even if it panics i'll at least have a crash log of whats happening

oh ok

cause it was segfaulting, the linux compat

if i understand correctly, this will either work or panic with gdb trace output

but that was a userland process (?), it shouldn't matter if you have a loadable kernelmodule or have that compiled in

oh, well my hope it is it will work

if not then i'll just use clang for the time being

i could mix and match it by not compiling the linux compat module with gcc but the compile it separately with clang but that just seems unnecessarily complicated

it may have been a userland process nimaje but the problem disappeared when i rebooted into a kernel built with clang instead of gcc

As long as FreeBSD project allows use og GCC to build world, thing not working as a result should be reported as bugs

build world with gcc doesnt compile on 13.2

the linker complains about an executable stack

and i dont know where to put the flag to silence the linker, cause its a warning treated as an error i believe

Could be due to options used (/etc/{make,src}.conf.?

and gcc12 doesnt work at all due to -fformat-extensions flag not being recognized anymore

i had no options in src.conf. i only added them later when it wouldnt compile without -Wno-error=redundant-decls

clang seems to tolerate a lot more errors

i narowed down the segfault to __vdso_gettimeofday()

seems like programs calling a time function are the ones to crash

well, that looks like it's not so much a time problem as the whole __vdso thing

where exactly is the fault? do you have a backtrace?

i have a core and backtrace and sessioin output

but its with color so its kinda messy

Title: dpaste: bash_segfault_linux_compat_gcc.session.txt

can you disassemble what's at 0x7fffffffecf0 ?

you can disassemble a range of bytes if it doesn't correspond to a function

e.g. disass 0x7fffffffecf0,+512

hand on, i'll try

RhodiumToad: dpaste.com/4NJ8QGKZA

Title: dpaste: bash core paste 2

and the output of info reg

Title: dpaste: bash core paste 3

that should also be in the first mess i posted

rsi is 0x7fff0000000

hm

kernel was compiled with gcc, or just userland, or both?

just kernel

i could try getting debugging symbols into my linux chroot for bash or other programs

but im preparing a better session of the whole thing

so my guess is this is something to do with the kernel's construction of the shared vdso page

thats outside my knowledge, but i can provide the core file along with the binary with the symbols

what cpu is this, btw?

this is intel

intel core2quad q6600

huh

this paste is significantly better, included disassemblies in both syntaxes and followed frames around: dpaste.com/35M38XGL2

Title: dpaste: bash_gcc_linux_segfault_session

still stupid color codes got in but oh well

most of it is color-free

do you have the same system compiled by clang running?

yeah, using my clang compiled kernel right now

the gdb output is from the chroot actually

well, gdb from inside the devuan chroot linux compat

what's the output of procstat -v $$

er, procstat -v $$ | tail -1 will do

1966 0x7ffffffff000 0x800000000000 r-x 1 1 66 0 ----- ph

inside the chroot? or host

this is from host

host

hmm.

the segfault is for linux binaries only?

yes, and only inside chroot i think

when i tried to run a linux-java-runtime it works fine

outside a chroot

hmm.

the chroot is /compat/devuan, do you also have the usual files in /compat/linux ?

yeah i mean, /bin/bash should be there

i dont have compat/linux core files though

and i dont have gdb installed in that chroot either

running gdb on the core, is a symbol kern_timekeep_base visible anywhere?

gzar: do you have the files for your gdb-compiled kernel around?

let me check

i have the core files if that is what you mean RhodiumToad

no

I mean the actual kernel and module binaries

but i cleared my build dir

oh

oh, yeah i think i have it

did you build again since then? in particular, do you have debug files in /usr/lib/debug/boot/kernel* corresponding to the gcc-built one?

i think i didnt build, i just used an older kernel i had

compare the file times for the gcc-built kernel+modules with the files in /usr/lib/debug/boot/kernel

what I want to see is the output from doing kgdb linux64.ko and disass elf64_linux_vdso_fixup

my kernel.old matches with the files in that debug dir

on the gcc-built version of linux64.ko

ah i see, but idk how to identify which kernel is built with clang and which not

matches /usr/lib/debug/boot/kernel or /usr/lib/debug/boot/kernel.old ?

readelf -a |grep -i gnu gives me no helpfull result

kernel.old

try strings /boot/kernel.old/kernel | grep -i gcc

(or grep -i clang)

gcc version 9.5.0

that's the version you used?

yes

ok. so see if you can do kgdb linux64.ko and disass elf64_linux_vdso_fixup

so i have both the kernel and the .ko debug files

on /boot/kernel.old/linux64.ko that is

basically this function is the one responsible for storing the value that's causing the segfault.

yeah i can do it

but its just a bunch of add instructions

hm

Title: dpaste: 822ALW5L3

those are padding bytes

yeah

so what do i do next

did it say it was reading symbols from both /boot/kernel.old/... and /usr/lib/debug//boot/kernel.old/... ?

i did specifically do file /usr/lib/debug/boot/kernel

my debug/boot/kernel matches up with my kernel.old

because i just swapped the kernel dirs after my recent compile

warning: the debug information found in "/usr/lib/debug//boot/kernel.old/linux64.ko.debug" does not match "/boot/kernel.old/linux64.ko" (CRC mismatch).

right, you need to rename the dirs in /usr/lib/debug/boot to match the actual /boot

alright

alright, it found the right symbols

ok, i see the function

RhodiumToad: dpaste.com/B85FLVVH4

Title: dpaste: B85FLVVH4

want me to print the source code as well? i assume that should be unchanged tho

no need

what exact fbsd version, though?

FreeBSD blackbsd 13.2-RELEASE FreeBSD 13.2-RELEASE GENERIC amd64

Title: dpaste: /etc/src.conf

^-. that is the /etc/src.conf i compiled it with