rtprio: because I am modifying the src tree lol

I am not modifying /usr/src because I would require root and yeah

hola

is there a solution for amdgpu Cezanne drivers ?

ghostbsd

freebsd != ghostbsd

i heard otherwise

Guphtah_: please ask on ghostbsd channels for ghostbsd specific issues. they have a forum and telegram group.

oh izder456 is here too!!

I thought you were just in #openbsd

i had an issue with my freebsd sbc so i joined

alright err, building /usr/src works fine, but when you have a local copy it just... refuses to compile...

weird...

do I need to compile the includes first I wonder?

or something?

idk I will tinker with it later!!

wait which efi executable in /usr/obj/usr/src/amd64.amd64/stand/efi is stage 1...

I am going to need to read the makefile :c

polarian: you can build from stand/, but you shouldn't build lower than that without a higher understanding of how it all slots together

polarian: stand/ is all build with the standalone stuff, there are no 'system headers'. libsa assembles the headers (some of which are just stand.h in a trenchcoat, but some are safe and brought in)

so in practice you always need libsa first, but sometimes you have other prereqs within stand/

the whole stand/ build is relatively fast compared to all of buildworld

kevans: oh stand stands for standalone duh

im really fucking dumb :p

thx for the advice

i would argue that the consequences of '(stand)alone' aren't necessarily obvious enough to make a claim like that, if you don't work in this space regularly

im mostly kidding

fair

Its typical British behaviour to self deprecate at every moment

dunno why, culture ig :p

tbf my humor is gone this morning, for it is muddy outside and i'd like to work on my truck

this would be a non-issue if i had gotten a concrete pad installed when i wanted to

ouchh!!!

my condolences

it hasn't rained in London for weeks now :/

the landscape has turned brown, and water is running out :/

ok /stand compiled libsa and all works now, thx

just need to compile efibootmgr on the server host, sftp the loader over (once I figure out which .efi it is) and then try booting the modified loader

this is kinda fun!

btw you can use chain command like: chain /boot/test.efi

?

for stage 1?

isnt that for stage 2+

there's no staging in efiland, really

hmmm

we have loader.efi and then the kernel

oh wow...

so gptboot does it all?

he's right, though- it is a lot easier than efibootmgr

there is no gptboot

stand/efi/gptboot.efi

the firmware uses efibootmgr entries to figure out what it's doing, whether that's a specific loader or a disk

oh, that's a very special thing

lol

gptboot.efi isn't used by probably 95%+ of freebsd users with uefi deployed

in EFI land, the firmware loads file from ESP (based on platform default path or bootmgr variable)

which is it?

those are all the efi binaries in stand/efi

loader_lua.efi

why is the _lua there

that would have been my last guess...

/boot/loader.efi is linked to hte default flavor (lua) at install tiim

time

so you can script it with lua??!

yes, it has been scripted with lua since 12.0

i wrote a very healthy chunk of the lua scripts that drive it

Tobbi: yeah I know from my time within Linux how efi booting works, seen as Linux distros are pretty much entirely hostile to pcbios these days

UKI is all the craze in Linux right now

interesting...

too bad my systems are still pcbios :p

I am curious now what does gptboot.efi do?

it brings the gpt selection behavior to uefi

I assume it has something to do with the GPT partition table, my best guess would be it boots the freebsd-boot partition?

oh nvm

:p

bootme flags or whatnot

ahhhh

freebsd sure is interesting...

I wonder what all these other efi binaries do

i think netflix wanted it to simplify something

does 4th stand for 4th stage or something?

forthloader

scripted with ficl (forth) instead of lua

ohhh

that must be old...

simp is naive, no scripting at all

does simp stand for simple by chance? :p

boot1.efi is the previous 'first stage' thing we used in the past, when our idea of constructing an ESP was checking in a FAT partition (boot1.efifat) and dd'ing that over

yeah

damn... theres a lot of history in the src tree eh?

what does the loader.help.efi do within the simp variant?

it still has a notion of commands

similar to the OpenBSD loader then?

which is command driven

the C parts provide some commands, the scripted parts provide others and sometimes override the C commands

this is really interesting, is this all documented somewhere, or is this just because you both have worked on the src tree a ton and understand it already?

I know the handbook as a explanation of the loader

i don't know that these kinds of architectural bits are really documented

there are manuals around, but as usual, I would not be surprised if some details are missing

because we are all just people:)

well... I guess the answer to this problem then is find devs at confs, buy em a beer, and get them yapping!

although the OpenBSD guys need quite the few beers before it even starts to have any affect on them...

I really should try to get a talk into BSDCan next year so I can afford to attend and meet the NA BSD folks!

also tsoome the "chain" command, where do you use that?

directly on ok prompt

ah so after geli then

hows that helpful for debugging here then?

you can start test binary from good loader without risking breaking your setup

but...

geli is already decrypted...

depends on your habits and setup -- if boot device selection menu is easy to trigger, then setting BOOTXXX variable is just as good gonsidering the ESP is mounted

considering*

ah, right, your interest was about interaction with geli.

yes!

which to my knowledge, I just make a "FreeBSD-test" efi entry

yep. that will do

and point that to the test efi binary I dump into the same dir

although I dont really know what partition this is on...

I assume its on the zfs partition?

no, it needs to be in ESP then

firmware can not read zfs

oh right yes

its a fat partition

sorry I was confusing it with /boot/loader

which would be used for pcbios

I will figure it out, I did efistub Linux for like 5 years, so I know my way around efibootmgr... mostly...

thanks for the help t soome and k evans will test this later :)

polarian: oh, shit, hold on

hold on to what :p

loader.env is more robust if we can move devinit after it, but efibootmgr also lets you add boot args

ah so you tested it?

this can be fixed with just that

no

wait

so I can add the args to efibootmgr?

yes, if you want a quick PoC

yeah but do you have docs for it?

:p

i think this is --env, but don't quote me on that

docs for it seem missing from efibootmgr(8) and I'm on a phone at the moment

you don't want to rely on it anyways, consumer firmware upgrades at least love to wipe nvram

putting something critical for boot in there is risky

yeah I know the hell of nvram lol

fucking windows likes wiping it (if anyone here has ever had the displeasure of deploying dual boot setups)

for giggles, if you have efi shell provided by your firmware, you can also start your bootloader from uefi shell;) but I havent seen yet user friendly uefi shell prompt...

I dont even know how to use a uefi shell :p

its like dos command.com ;)

you think im old enough to have used dos? :p

.oO oops:P

also I just figured out what k evans nick meant, and realised I think I have read some of their posts before, on klara...

^^^ see told you im stupid, didnt put two and two together until now

ah, yes, that is also me

xD

I reset my /usr/ports using the ports-reset.sh script. I'm going to have to update my local branches too, but which commits should I use? Based on the email sent out, I know one has to be the hash where I diverged from `main`. What's the other hash that I need to use?

mns: how are your local branches structured? just changes on top of an otherwise upstream tree?

kevans: yeah, I just divereged from main at various points and have been working on those branches for two different bugs.

mns: find the point where you diverged and use the `git rebase --onto` sample from the announcement

mns: it can be `--onto main` if you already rebased `main`

kevans: thanks. I've already run the post-reset.sh script on 'main

kevans: thanks. I've already run the post-reset.sh script on 'main' so will use 'main' with the 'git merge-base' output

for me a 'simple' `git rebase -i freebsd/main` was all that is needed.

is it normal for `make install missing packages` on chromium to want to install python 3.10, 3.12, 3.13 and 3.14 ?

that seems like it could be a bug

mvanbaak: Yeah mine would have been simple too, if I didn't have any branches where I was working on anything.

I have 1 branch, but the work I do there does not really clash with main (except for the UIDs and GIDs files normally) so it's easy to keep in sync

only a bunch of ports I maintain, thats it

mns: git pull --rebase would have been fine, too

the script is mostly for people that don't want to trust us

kevans: git pull --rebase was simpler, thanks.

also, is there a howto on how to track down why this laptop powers down when it should be going to S3 ?

mns: yes, sorry. we were busy preparing for the worst cases and didn't drop a note for the easiest

mns: a lot of people do trust us and can just accept it

I often forget that it's been a quarter century since DOS was EOLed.

Only 25, hmm

kevans: no apologies needed. I've been in the industry long enough to know how things are when there is a critical on-going issue. I've been through that many times myself. Kudos to you and core@ and gitadm@ for the transparency.

Only that long? Was it in 2001?

Reinhilde: working with f/oss since 1988, in the industry since 1992. long enough.

is it a bad idea for web services to use public dns resolvers on servers? like 1.1.1.1

kerneldove: as with many things, "it depends." How many servers? Are the server targets publicly accessible records?

kerneldove: as wavefunction said, "it depends". If this is for work, not a bad idea to use public resolvers as backup resolvers rather than primary.

mns, I wasn't talking to you , but to wavefunction and dnp1

mns: thanks. some people were a little confused because it "just worked" anyways, but yeah- if we go with that as baseline, we won't draw the attention of those who really need to see the instructions

i'm much happier to waste a few minutes of your time reading our announcement and discarding it if someone else would have spent even longer trying to solve it

we don't do it often

mns backup for what? running unbound in full self resolver mode or?