11:01:29 <polarian> rtprio: because I am modifying the src tree lol
11:01:47 <polarian> I am not modifying /usr/src because I would require root and yeah
13:04:34 <Guphtah> hola
13:08:11 <Guphtah> is there a solution for amdgpu Cezanne drivers ?
13:14:02 <Guphtah> ghostbsd
14:26:43 <polarian> freebsd != ghostbsd
14:30:36 <Guphtah_> i heard otherwise
15:02:27 <izder456> Guphtah_: please ask on ghostbsd channels for ghostbsd specific issues. they have a forum and telegram group.
15:31:40 <polarian> oh izder456 is here too!!
15:31:44 <polarian> I thought you were just in #openbsd
15:32:41 <izder456> i had an issue with my freebsd sbc so i joined
15:33:17 <polarian> alright err, building /usr/src works fine, but when you have a local copy it just... refuses to compile...
15:33:19 <polarian> weird...
15:33:27 <polarian> do I need to compile the includes first I wonder?
15:33:31 <polarian> or something?
15:33:45 <polarian> idk I will tinker with it later!!
15:36:57 <polarian> wait which efi executable in /usr/obj/usr/src/amd64.amd64/stand/efi is stage 1...
15:37:01 <polarian> I am going to need to read the makefile :c
15:42:02 <kevans> polarian: you can build from stand/, but you shouldn't build lower than that without a higher understanding of how it all slots together
15:43:14 <kevans> 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)
15:43:36 <kevans> so in practice you always need libsa first, but sometimes you have other prereqs within stand/
15:43:55 <kevans> the whole stand/ build is relatively fast compared to all of buildworld
15:44:07 <polarian> kevans: oh stand stands for standalone duh
15:44:11 <polarian> im really fucking dumb :p
15:44:26 <polarian> thx for the advice
15:45:18 <kevans> 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
15:45:34 <polarian> im mostly kidding
15:45:38 <kevans> fair
15:45:51 <polarian> Its typical British behaviour to self deprecate at every moment
15:45:54 <polarian> dunno why, culture ig :p
15:47:40 <kevans> tbf my humor is gone this morning, for it is muddy outside and i'd like to work on my truck
15:47:52 <kevans> this would be a non-issue if i had gotten a concrete pad installed when i wanted to
15:49:31 <polarian> ouchh!!!
15:49:35 <polarian> my condolences
15:49:41 <polarian> it hasn't rained in London for weeks now :/
15:49:55 <polarian> the landscape has turned brown, and water is running out :/
15:50:22 <polarian> ok /stand compiled libsa and all works now, thx
15:50:52 <polarian> 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
15:51:08 <polarian> this is kinda fun!
15:53:54 <tsoome> btw you can use chain command like: chain /boot/test.efi
15:54:31 <polarian> ?
15:54:41 <polarian> for stage 1?
15:54:55 <polarian> isnt that for stage 2+
15:55:13 <kevans> there's no staging in efiland, really
15:55:19 <polarian> hmmm
15:55:21 <kevans> we have loader.efi and then the kernel
15:55:27 <polarian> oh wow...
15:55:39 <polarian> so gptboot does it all?
15:55:41 <kevans> he's right, though- it is a lot easier than efibootmgr
15:55:44 <kevans> there is no gptboot
15:56:18 <polarian> stand/efi/gptboot.efi
15:56:19 <kevans> the firmware uses efibootmgr entries to figure out what it's doing, whether that's a specific loader or a disk
15:56:37 <kevans> oh, that's a very special thing
15:56:42 <polarian> lol
15:56:56 <kevans> gptboot.efi isn't used by probably 95%+ of freebsd users with uefi deployed
15:57:05 <tsoome> in EFI land, the firmware loads file from ESP (based on platform default path or bootmgr variable)
15:57:12 <polarian> https://bpa.st/Y7UA
15:57:28 <polarian> which is it?
15:57:36 <polarian> those are all the efi binaries in stand/efi
15:57:40 <kevans> loader_lua.efi
15:57:46 <polarian> why is the _lua there
15:57:51 <polarian> that would have been my last guess...
15:57:59 <kevans> /boot/loader.efi is linked to hte default flavor (lua) at install tiim
15:58:00 <kevans> time
15:58:12 <polarian> so you can script it with lua??!
15:58:19 <kevans> yes, it has been scripted with lua since 12.0
15:58:38 <kevans> i wrote a very healthy chunk of the lua scripts that drive it
15:58:39 <polarian> 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
15:58:52 <polarian> UKI is all the craze in Linux right now
15:59:15 <polarian> interesting...
15:59:27 <polarian> too bad my systems are still pcbios :p
15:59:54 <polarian> I am curious now what does gptboot.efi do?
16:00:20 <kevans> it brings the gpt selection behavior to uefi
16:00:22 <polarian> I assume it has something to do with the GPT partition table, my best guess would be it boots the freebsd-boot partition?
16:00:30 <polarian> oh nvm
16:00:32 <polarian> :p
16:00:37 <kevans> bootme flags or whatnot
16:00:44 <polarian> ahhhh
16:00:55 <polarian> freebsd sure is interesting...
16:01:05 <polarian> I wonder what all these other efi binaries do
16:01:10 <kevans> i think netflix wanted it to simplify something
16:01:17 <polarian> does 4th stand for 4th stage or something?
16:01:22 <kevans> forthloader
16:01:29 <kevans> scripted with ficl (forth) instead of lua
16:01:33 <polarian> ohhh
16:01:44 <polarian> that must be old...
16:01:45 <kevans> simp is naive, no scripting at all
16:01:58 <polarian> does simp stand for simple by chance? :p
16:02:31 <kevans> 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
16:02:34 <kevans> yeah
16:02:59 <polarian> damn... theres a lot of history in the src tree eh?
16:03:13 <polarian> what does the loader.help.efi do within the simp variant?
16:04:09 <kevans> it still has a notion of commands
16:04:34 <polarian> similar to the OpenBSD loader then?
16:04:39 <polarian> which is command driven
16:04:40 <kevans> the C parts provide some commands, the scripted parts provide others and sometimes override the C commands
16:06:05 <polarian> 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?
16:06:17 <polarian> I know the handbook as a explanation of the loader
16:06:38 <kevans> i don't know that these kinds of architectural bits are really documented
16:06:51 <tsoome> there are manuals around, but as usual, I would not be surprised if some details are missing
16:07:15 <tsoome> because we are all just people:)
16:08:08 <polarian> well... I guess the answer to this problem then is find devs at confs, buy em a beer, and get them yapping!
16:08:40 <polarian> although the OpenBSD guys need quite the few beers before it even starts to have any affect on them...
16:09:42 <polarian> I really should try to get a talk into BSDCan next year so I can afford to attend and meet the NA BSD folks!
16:11:30 <polarian> also tsoome the "chain" command, where do you use that?
16:11:48 <tsoome> directly on ok prompt
16:12:09 <polarian> ah so after geli then
16:12:19 <polarian> hows that helpful for debugging here then?
16:13:27 <tsoome> you can start test binary from good loader without risking breaking your setup
16:14:37 <polarian> but...
16:14:40 <polarian> geli is already decrypted...
16:15:21 <tsoome> 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
16:15:29 <tsoome> considering*
16:15:51 <tsoome> ah, right, your interest was about interaction with geli.
16:15:56 <polarian> yes!
16:16:10 <polarian> which to my knowledge, I just make a "FreeBSD-test" efi entry
16:16:20 <tsoome> yep. that will do
16:16:22 <polarian> and point that to the test efi binary I dump into the same dir
16:16:28 <polarian> although I dont really know what partition this is on...
16:16:37 <polarian> I assume its on the zfs partition?
16:16:53 <tsoome> no, it needs to be in ESP then
16:17:08 <tsoome> firmware can not read zfs
16:17:09 <polarian> oh right yes
16:17:14 <polarian> its a fat partition
16:17:22 <polarian> sorry I was confusing it with /boot/loader
16:17:34 <polarian> which would be used for pcbios
16:18:47 <polarian> I will figure it out, I did efistub Linux for like 5 years, so I know my way around efibootmgr... mostly...
16:19:12 <polarian> thanks for the help t soome and k evans will test this later :)
16:28:01 <kevans> polarian: oh, shit, hold on
16:28:21 <polarian> hold on to what :p
16:28:28 <kevans> loader.env is more robust if we can move devinit after it, but efibootmgr also lets you add boot args
16:28:52 <polarian> ah so you tested it?
16:28:54 <kevans> this can be fixed with just that
16:28:58 <kevans> no
16:29:07 <polarian> wait
16:29:15 <polarian> so I can add the args to efibootmgr?
16:29:36 <kevans> yes, if you want a quick PoC
16:29:46 <polarian> yeah but do you have docs for it?
16:29:48 <polarian> :p
16:31:25 <kevans> i think this is --env, but don't quote me on that
16:31:43 <kevans> docs for it seem missing from efibootmgr(8) and I'm on a phone at the moment
16:32:50 <kevans> you don't want to rely on it anyways, consumer firmware upgrades at least love to wipe nvram
16:33:17 <kevans> putting something critical for boot in there is risky
16:34:48 <polarian> yeah I know the hell of nvram lol
16:35:02 <polarian> fucking windows likes wiping it (if anyone here has ever had the displeasure of deploying dual boot setups)
16:35:08 <tsoome> 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...
16:35:23 <polarian> I dont even know how to use a uefi shell :p
16:35:34 <tsoome> its like dos command.com ;)
16:36:18 <polarian> you think im old enough to have used dos? :p
16:36:33 <tsoome> .oO oops:P
16:36:52 <polarian> also I just figured out what k evans nick meant, and realised I think I have read some of their posts before, on klara...
16:37:03 <polarian> ^^^ see told you im stupid, didnt put two and two together until now
16:40:55 <kevans> ah, yes, that is also me
16:47:42 <polarian> xD
17:20:54 <mns> 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?
17:26:39 <kevans> mns: how are your local branches structured?  just changes on top of an otherwise upstream tree?
17:54:21 <mns> kevans: yeah, I just divereged from main at various points and have been working on those branches for two different bugs.
18:08:00 <kevans> mns: find the point where you diverged and use the `git rebase --onto` sample from the announcement
18:08:24 <kevans> mns: it can be `--onto main` if you already rebased `main`
18:28:31 <mns> kevans: thanks.  I've already run the post-reset.sh script on 'main
18:29:09 <mns> kevans: thanks.  I've already run the post-reset.sh script on 'main' so will use 'main' with the 'git merge-base' output
18:44:56 <mvanbaak> for me a 'simple' `git rebase -i freebsd/main` was all that is needed.
18:45:12 <rtprio> is it normal for `make install missing packages` on chromium to want to install python 3.10, 3.12, 3.13 and 3.14 ?
18:45:22 <rtprio> that seems like it could be a bug
18:54:08 <mns> mvanbaak: Yeah mine would have been simple too, if I didn't have any branches where I was working on anything.
18:56:03 <mvanbaak> 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
18:56:29 <mvanbaak> only a bunch of ports I maintain, thats it
19:00:12 <kevans> mns: git pull --rebase would have been fine, too
19:00:39 <kevans> the script is mostly for people that don't want to trust us
19:19:56 <mns> kevans: git pull --rebase was simpler, thanks.
19:33:41 <rtprio> also, is there a howto on how to track down why this laptop powers down when it should be going to S3 ?
19:44:19 <kevans> mns: yes, sorry. we were busy preparing for the worst cases and didn't drop a note for the easiest
19:44:34 <kevans> mns: a lot of people do trust us and can just accept it
20:30:55 <wavefunction> I often forget that it's been a quarter century since DOS was EOLed.
20:51:45 <dnp1> Only 25, hmm
21:16:33 <mns> 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.
21:20:49 <Reinhilde> Only that long? Was it in 2001?
21:37:57 <mns> Reinhilde: working with f/oss since 1988, in the industry since 1992.  long enough.
21:42:39 <kerneldove> is it a bad idea for web services to use public dns resolvers on servers? like 1.1.1.1
21:44:36 <wavefunction> kerneldove: as with many things, "it depends." How many servers? Are the server targets publicly accessible records?
21:48:00 <mns> 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.
21:51:35 <Reinhilde> mns, I wasn't talking to you , but to wavefunction and dnp1
21:54:36 <kevans> 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
21:56:06 <kevans> 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
21:56:39 <kevans> we don't do it often
22:20:28 <kerneldove> mns backup for what? running unbound in full self resolver mode or?