00:07:25 <jb1277976> Guys i want to install freebsd on this ACER but it has a QCA9377 but all over the forums it says its not supported yet. was wondering if somebody can confirm. I'm wondering if stable will have it
00:08:54 <jb1277976> some of the fourms are from like 2019 and such
00:11:00 <jb1277976> https://forums.freebsd.org/threads/atheros-qca9377.87939/
00:11:01 <VimDiesel> Title: Atheros QCA9377 | The FreeBSD Forums
00:12:49 <debdrup> bz@ has been working on a solution for that, but I'm not sure about the state of it.
00:27:23 <jb1277976> Thanks
00:59:33 <voy4g3r2> hi everyone, i am looking to try and compile lua-language-server and it is unfortunate there is no /usr/ports entry for this and all documentation assumes linux/mac/windows, no *bsd. My question is: is there a "standard" template for setting up a compile to a BSD structure.. like /usr/local /usr/local/etc ...
01:27:03 <V_PauAmma_V> voy4g3r2, are you looking for hier(7), the "hier" manual page?
01:28:28 <V_PauAmma_V> (Specifically, the "local" paragraph under "/usr".)
01:28:57 <voy4g3r2> V_PauAmma_V: that is possible, i am so use to building things in slackware, debian and other linux.. but i am not sure what i am suppose to look for, in freebsd
01:29:29 <voy4g3r2> the hier thing, looks like what i am looking for :)
01:30:35 <CrtxReavr> Don't panic, but pay attention: https://arstechnica.com/security/2023/11/hackers-can-steal-ssh-cryptographic-keys-in-new-cutting-edge-attack/
01:30:36 <VimDiesel> Title: In a first, cryptographic keys protecting SSH connections stolen in new attack | Ars Technica
02:20:10 <siort> I'm having crashes with graphics/drm-515-kmod on a amd raven2 gpu on 14.0-RELEASE
02:20:50 <siort> It seems okay with graphics/drm-510-kmod
02:22:15 <siort> also it began crashing when i updated from 5.15.118 to 5.15.118_1
03:14:11 <BillyJoeBob> So, anyone have any ideas on how to redirect audio for OBS? It works fine to capture the audio output on something like Firefox, but when playing Unreal Tournament 99, I hear nothing.
06:03:03 <luna__> FreeBSD 14 is now released
06:53:40 <meena> yay!
06:56:43 <meena> CrtxReavr: "it affects only keys using the RSA cryptographic algorithm" phew
06:58:36 <meena> i wonder if siort reported by of their graphics/drm-515-kmod crashes…
07:00:43 <meena> wat "Of the roughly 1 billion RSA signatures, about one in a million exposed the private key of the host."
08:12:25 <sopparus> hallo
08:12:29 <sopparus> im upgrading a jail to 14.0
08:12:46 <sopparus> etc-update or mergemaster or whatever is not helping me at all, I have to manually fix every file
08:12:52 <sopparus> Merge conflict markers remain in: /etc/ssh/moduli for example
08:31:49 <parv> I had not run any jail of much significance. But damn, seems like installing from scratch could be less tedious (save the critical files; set up a new jail; update the files in new jail). Then again, as I mentioned at the start ...
08:42:17 <meena> sopparus: can you show what a conflicting file looks like?
08:43:54 <sopparus> i have allready fixed it by hand now, but im soon doing another jail
08:44:11 <sopparus> i have never altered /etc/ssh/moduli myself
08:44:44 <sopparus> it seems like in /etc/ssh/moduli it removed every line and inserted new ones
08:45:19 <sopparus> in other rc scripts, some if code where replaced by other if code, which should be merged automaticly just fine
08:48:43 <parv> sopparus, What is the FreeBSD version that you are upgrading from?
08:48:51 <sopparus> 13.2
08:49:09 <sopparus> the host machine went fine as usual, its just the jail
08:49:19 <parv> Thanks
08:49:38 <sopparus> using  freebsd-update -j myjail -r 14.0-RELEASE upgrade
08:54:45 <parv> https://www.freebsd.org/releases/ does not list "14.0-RELEASE" ...
08:54:46 <VimDiesel> Title: Release Information | The FreeBSD Project
08:55:23 <parv> ... or, does using that strings causes the install of some *RC version?
08:56:13 <babz> https://www.freebsd.org/releases/14.0R/schedule/
08:56:14 <VimDiesel> Title: FreeBSD 14.0 Release Process | The FreeBSD Project
08:57:06 <parv> babz, Yes, just found that too! Am late to the party.
08:59:13 <nimaje> yeah, that says the release should be today, not that it actually happened yet
09:03:31 <meena> there's no release without the announcement
09:06:25 <dch> diizzy: do you have a ryzen system now? just reading latest threads on hackers
09:06:40 <nimaje> afaik the release waits till all pkg repos are build and not sure what else has to happen before the announcement is sent
09:06:42 <dch> looking at a ryzen 7950x
09:47:44 <sopparus> meena: for example in rc.conf https://dumpinen.com/lib7892wJMt
09:49:03 <sopparus> also https://dumpinen.com/-qpWMXO-vKa
09:49:42 <sopparus> those are automerged on host machine
10:01:05 <babz> sopparus: what's the output of
10:01:05 <babz> ls -l/var/db/etcupdate/
10:01:05 <babz> grep /etc/mtree/BSD.debug.dist /var/db/etcupdate/*.files
10:01:33 <sopparus> in the jail?
10:01:48 <babz> yeah
10:04:12 <sopparus> babz: https://dumpinen.com/T3w9ekBikbd
10:05:06 <babz> yeah, you dont have the files from the previous release
10:05:46 <babz> so every change results a two conflicting filecreations
10:08:19 <babz> how did you install the jail ? how did you upgrade it ?
10:13:55 <sopparus> hm i see
10:13:58 <sopparus> I used freebsd-update -j myjail -r 14.0-RELEASE upgrade
10:14:13 <sopparus> cant remember exactly how I installed it, but it was not ezjail and I followed the handbook
10:16:11 <rafe> sopparus: while it is not at all helpful with your current situation, I will note that bastille is a pleasure to work with for jail management
10:27:31 <meena> I wonder if anyone is working on adding PkgBase support to bastille or pot
10:41:33 <sopparus> hmm seems stuff got a litle broke in the jail
10:41:37 <sopparus> [#] wg setconf wg0 /dev/stdin
10:41:38 <sopparus> ld-elf.so.1: Shared object "libnv.so.0" not found, required by "wg"
10:43:07 <babz> you packages are still built against you old base libs
10:44:01 <sopparus> yeah noticed, the reason they didnt update was becouse pressing y just quits
10:44:25 <sopparus> https://dumpinen.com/g5lWe6lvJ2f
10:44:26 <babz> with pkg-static ?
10:44:31 <sopparus> will try
10:44:42 <sopparus> same
11:04:32 <meena> sopparus: libnv.so.0 strikes me as a base lib. you sure that upgrade went thru fine?
11:10:25 <babz> i have /lib/libnv.so.1 in 14.0
11:26:28 <nimaje> sopparus: pkg just stopping seems strange what is the exit status?  echo "$?"  after the command; maybe try  pkg-static install -f pkg
13:33:14 <babz> rafe: how do you update thin containers and their templates with bastille
14:53:22 <CrtxReavr> meena, it's a solid bet that 1:1,000,000 ratio will decrease as more people poke at it.
15:00:12 <dch> sopparus: you will need to run `pkg bootstrap -fy` within the jail, so it picks up the right abi.
15:21:25 <meena> CrtxReavr: and more vendors fix their devices…
15:22:52 <meena> I am wondering tho, if this type of leakage is exclusive to RSA… (I've been using… not RSA for quite some time)
16:35:53 <polyex> 14 when
16:36:02 <scoobybejesus> babz, let's say your thin jails are on 13.1-RELEASE. you do bastille update 13.1-RELEASE for the base jail to be updated. then you can update the pkg database and the packages in the jail.  if you need to upgrade from 13.1 to 13.2, you'll first bastille bootstrap 13.2-RELEASE to create a new base jail, and then shut down the jail, change the fstab to point to the 13.2 base jail, then start it up again and update packages
16:37:29 <babz> well, it's very weird
16:37:40 <babz> it successfully updates the template
16:37:44 <babz> bu dont rename it
16:38:34 <babz> so you have i2 13.1-RELEASE containing a 13.2-RELEASE
16:39:14 <babz> and it never updates the thin containers so you have recover every one of them individually
16:40:22 <babz> so now i'm wondering how is it supposed to help in upgrading vs doing everything manually ?
16:51:22 <scoobybejesus> i used to do it that way (i used to update the base jail from 12.1 - 12.2, for example), but after that you can't upgrade it anymore, and it is named incorrectly.
16:52:15 <scoobybejesus> it's best to only do bastille update 13.1-RELEASE, never bastille upgrade 13.1-RELEASE 13.2-RELEASE.  only do that style upgrading on a normal thick jail
16:52:49 <babz> wtf
16:53:25 <scoobybejesus> because you go into the thin jail's fstab to point to the 13.2-RELEASE, and you're done
16:53:35 <scoobybejesus> well, then you upgrade pkg and packages, and then you're done
16:53:47 <scoobybejesus> and you can zfs destroy the old release when you're done with it
16:53:54 <scoobybejesus> old release base jail
16:55:31 <polyex> 14
17:03:34 <scoobybejesus> babz: something like this: https://bsd.to/JprL   does that make sense?
17:03:36 <VimDiesel> Title: dpaste/JprL (Plain Text)
17:11:10 <babz> well, step 4 fails
17:34:39 <rwp> I see that sudo-1.9.15p1 has now finished building in the auto-builders and is now available for installation today.  Don't take it!
17:34:48 <rwp> The changelog says it still has the tty bug.  It's -p2 or later that we need to fix the recent sudo tty bug introduced in the 1.9.15 version.
17:36:42 <rafe> hmm, now I am having my own jail problems
17:36:57 <rafe> is there a preferred way to merge /etc changes when updating a jail?
17:37:12 <rafe> bastille does nothing
17:38:21 <rwp> I am so far doing my own thing with jails but isn't etcupdate the preferred tool now, replacing mergemaster?
17:39:17 <rafe> yes, I haven't needed to use it yet because I'm not building from source, but I guess I must dig in now
17:40:48 <rwp> I thought that it was when working from source that mergemaster, er..., etcupdate was needed.  No?  I have mostly worked using freebsd-update and it invoked whatever it does internally and I just follow it.
17:43:34 <rwp> I wish the FreeBSD Handbook were organized somewhat differently.  I always find it difficult to quickly locate the sections I want.  It's fine of course.  I am just complaining.
17:43:40 <rwp> https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
17:43:41 <VimDiesel> Title: Chapter 26. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal
17:44:15 <rwp> That's the authoritative documentation and where I got my information on etcupdate for this.
17:45:02 <Demosthenex> odd, i'm doing "df -m /usr" and getting "du: fts_read: No such file or directory" and it aborts.
17:45:42 <rwp> And this is where my complaints about the Handbook happen.  https://docs.freebsd.org/en/books/handbook/jails/#jail-upgrading
17:45:43 <VimDiesel> Title: Chapter 17. Jails and Containers | FreeBSD Documentation Portal
17:45:45 <rafe> rwp: I said I have *not* been building from source
17:46:04 <rwp> It's there but it just does not seem complete to me.  One must really stretch to connect the dots.
17:46:41 <rwp> rafe, Oh!  Not.  Sorry!  My bad.  In that case freebsd-update can update jails and walk through the etc update side of things.  That's what I have been using.
17:47:11 <rafe> yeah, unfortunately I'm not sure that's the case with a bastille-managed thin jail
17:47:12 <rwp> Demosthenex, Not that I can help but...  On what type of file system is that?
17:47:14 <rafe> since it's a composite
17:47:29 <rafe> I'll check the handbook, though!
17:48:11 <rwp> Ah!  So with bastille-managed it is built up layers thin-jail.  Gotcha.  In that case I think a new composition of layers would be needed to be built up.
17:48:36 <rwp> That's more like what I do.  I create a new jail all fresh from the current version and then apply my configuration on top of it.
17:49:19 <babz> yup, i had to ruin etcupdate from the host
17:49:35 <babz> otherwise, the jail you not let me log in
17:49:47 <rafe> babz, it's because a pam module was dropped
17:49:57 <babz> (I think that's the deprecated pam module)
17:50:12 <rafe> yep
17:50:16 <rwp> Demosthenex, Also upon which OS version are you running?  "freebsd-version -kru"  And I would verify you are using /usr/bin/du and not something layered on.
17:52:52 <Demosthenex> rwp: 13.2 i think, let me check
17:52:59 <Demosthenex> nothing but zfs here.
17:53:13 <rwp> Demosthenex, If it were me I would run "truss -o df-m_usr.out df -m /usr" and then see if there is a clue in the system call trace up until it aborts.
17:54:13 <rwp> Demosthenex, I am also running 13.2-RELEASE with ZFS and am not having any problem at this time.  Try also "zpool status" to verify the integrity of your zfs pool.
17:54:29 <Demosthenex> status says both pools ok, that was my first check
17:55:31 <rwp> Good!  And "df -h /" is okay too?  Does "zfs list /usr" work or also have problems?  "zfs list" itself?  Sounds like a very strange problem.
17:56:27 <scoobybejesus> babz, which step 4?  sorry, i had to step away
17:56:28 <Demosthenex> nothing but df -m
17:57:33 <babz> scoobybejesus: bastille start
17:58:04 <scoobybejesus> very odd.
17:58:24 <babz> well, I fail to see how it's supposed to work
17:58:39 <babz> you have to update some config files
17:59:01 <scoobybejesus> it is just choosing a new base jail.
18:00:28 <scoobybejesus> https://gist.github.com/cedwards/1e00c3d0aa6fbb14bc5b16fca8df0c35
18:00:29 <VimDiesel> Title: Bastille upgrade / downgrade procedures · GitHub
18:02:35 <rafe> babz, anything special in your invocation of etcupdate? I can run it against /usr/src with different work and destination directories for my jails w/o issue?
18:02:49 <rafe> did you build it as a tarball first?
18:03:35 <babz> yup that's what I did
18:03:41 <babz> and it works
18:04:03 <rafe> sorry, did you build it as a tarball first?
18:04:04 <Demosthenex> rwp: you know, i think it was failing across jails in /usr/local/bastile... du -smx /usr worked ok
18:09:24 <rwp> Demosthenex, Wow!  *Everyone* is working on their jails today.  It's quite the convergence of activity!  Glad you have debugged to the root cause. :-)
18:26:42 <Demosthenex> rwp: hehe
18:26:47 <polyex> 14
18:27:47 <Zyxer> I'm not 14 why are you saying that?
18:35:41 <unixman_home> polyex, keep an eye on https://lists.freebsd.org/archives/freebsd-announce/2023-November/ for the release announcement.
18:35:43 <VimDiesel> Title: freebsd-announce⊙Fo
18:36:58 <unixman_home> polyex, I have not seen anything telling us that FreeBSD 14.0 will not be announced today. I've been checking. ;)
18:37:49 <rwp> polyex, But 14 is still "upcoming", right?  Though it is good to get ahead of things and test, test, test.
18:38:30 <rafe> I mean, I'm sure people are being disabused of this notion, but it's on the servers
18:38:35 <rafe> you can update now
18:39:03 <unixman_home> rwp, supposedly 14.0 will be announced as ready to go today. See the chart here: https://www.freebsd.org/releases/14.0R/schedule/
18:39:04 <VimDiesel> Title: FreeBSD 14.0 Release Process | The FreeBSD Project
18:39:51 <unixman_home> rafe, good point. The builds started on Nov 10th, so I am not surprised it is already "out there".
18:40:32 <rwp> If it is on the schedule then it is on the schedule!  I stand newly informed.  Though other testing what is still a candidate until it is announced I am going to be patient myself.
18:40:44 <rwp> *other than testing...
18:41:04 * unixman_home will put 14.0 in a lab for a while though. It will not go into production for at least 4 to 6 months.
18:42:05 <nimaje> the pkg repos seem like they are prepared too, so I'm not sure what is blocking the announcment currently
18:43:13 <rwp> It's fun to see everyone excited like it is almost but not quite time to open presents. :-)
18:43:24 <unixman_home> :D Right?
18:43:29 <ZedHedTed> tell that to 12yo me lo
18:43:34 <ZedHedTed> l
18:47:07 <rwp> Maybe the wait is to wait until time 1700000000 rolls around?  It's very close now.  Time now 1699987613.
18:47:48 <Zyxer> It'll be my first freebsd upgrade
18:53:48 <mns> rwp: its already past the release candidate stage, this is the actual release today.  The builds were started on the 10th.  Unless some show-stopper bug came to light, 14.0 according to announcements so far, will come out today.
18:59:15 <mns> nimaje: maybe the hold is because they're waiting for the website update or the writeup to be out with the anouncement ? just throwing it out there.
18:59:18 <rwp> If being scheduled is enough then why make an announcement?  Because it's not released until the announcement. :-)
19:01:50 <jb1277976> first freebsd upgrade does it usually take this long or is it my intenret connection ?
19:01:55 <jb1277976> aw there it goes
19:03:54 <nimaje> the schedule can be updated, I think the initial schedule had the release at the end of october, but as the schedule wasn't changed today, I guess it is unlikely that it will and it is just waiting for the announcement
19:04:38 <jb1277976> freebsd-update upgrade -r 14.0-RELEASE is working its going thought a lot of numbers right now
19:05:12 <mns> yeah there will be a ton of patch-sets and what not to go through
19:05:27 <kevans> yeah f-u is kinda slow for larger upgrades
19:05:30 <jb1277976> im at 8580
19:06:47 <jb1277976> 10720 patches
19:09:49 <hernan> https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-RELEASE-amd64-memstick.img
19:10:25 <jb1277976> It's easier to do a reinstall right ?
19:10:50 <hernan> no, just wait
19:12:03 <jb1277976>  its saying /etc/group has merge conflict and i have to edit for the system to be functional. any ideas what to do ?
19:12:10 <hernan> remember next time you can take a zfs snapshot before upgrading.. and if something doesnt work for any reason, you can go back to the snapshot
19:12:36 <hernan> jb1277976: just resolve the merge conflict and keep your changes..
19:12:51 <jb1277976> just save it and go ?
19:13:04 <hernan> no
19:13:13 <hernan> resolve the conflict
19:13:24 <hernan> it probably has  some partially similar lines
19:13:31 <jb1277976> oh
19:13:46 <hernan> you might want to keep your old lines and delete the new ones
19:24:11 <jb1277976> Why would they insert lines in those files?
19:26:49 <Zyxer> You probably should have copied them to another dir and then edit them. Many files/configs are looked for in different places, and some that come with installation are meant to be copied to a another of those directories.
19:27:13 <Zyxer> Wait no I am dumb now
19:27:24 <Zyxer> /etc/group you said
19:27:42 <Zyxer> I dunno. forget what I said
19:28:23 <jb1277976> Yes /etc/group and /etc/passwd
19:31:21 <Zyxer> wat? Maybe ads a group that you already have added manually? This is weird
19:32:18 <jb1277976> Oh well it's done. Not at computer
19:33:01 <rafe> the stock file will not have groups that were added
19:33:58 <rafe> for example, when you install programs
19:38:52 <Zyxer> I meant like dialer, video, input, audio
19:39:08 <Zyxer> But ok, not added groups
19:41:27 <rwp> Just nothing that freebsd-update on zfs automatically creates a snapshot for you like "zroot/ROOT/default@2023-11-09-11:54:26-0" was my last one.
19:42:21 <rwp> Those are automatically useful for Boot Environments so even if things go very wrong one can boot using the Boot Environment and select the previous one and then rescue.
19:43:46 <rwp> Meanwhile...  Having local changes such as users and groups is *normal* and just need to be merged during update time.  Don't panic!  Just merge the files.  That's normal update operation.
19:51:31 <jb1277976> I had to take the lines out though like >>>≥> $Freebsd etc.. was in there I removed them then everything worked
19:55:17 <rwp> Those ">>" and "<<" lines are conflict markers and are there to highlight the lines that need the local sysadmin to resolve.  In other words...  Yes.  That's what you are supposed to do.
19:55:49 <rwp> Previous versions included $FreeBSD$ version control tags.  Since the move to git those are deprecated and have been removed from the current release.
19:57:04 <rwp> Those were seen as useful back in the old days but now with distributed version control they are a hindrance because they will always be changed lines and so having them now is counter productive.  They have been removed.  Though many people will miss them as they were a nice visual indication of the parent of the file.
19:57:42 <rwp> I am surprised you still have them upgrading from 13 to 14 since I am on 13 and I already had them go away in the upgrade from 12 to 13.
19:58:07 <rwp> Which makes me think you are upgrading from 12 to 14 and so now seeing that removal happen now.
20:09:38 <jb1277976> Thanks
21:20:06 <dch> jb1277976: this merge conflict is usually (for 12/13 -> 14) the change on root for shell /bin/sh
21:21:50 <dch> and the $FreeBSD stuff as well
21:22:09 <dch> I also had a few entries in /etc/group that changed
21:48:02 <jb1277976> Thanks
21:49:20 <jb1277976> anyone seen this before http://termbin.com/01oy after a make quicksearch ?
21:52:30 <jb1277976> X isn't working now since the update to 14.0 let me get the log file
21:53:47 <jb1277976> i guess X dosen't like modsesetting anymore
21:56:42 <babz> is the driver loaded ?
21:57:38 <jb1277976> babz: i think so its been working for the past week. i did the update to 14.0 and now its not working
21:57:46 <jb1277976> let me see what kldstat says
21:58:13 <babz> the default loader config now has
21:58:14 <babz> module_blacklist="drm drm2 radeonkms i915kms amdgpu"
21:58:34 <jb1277976> http://termbin.com/ykpn
21:58:53 <jb1277976> babz:  do i put that in rc.conf ?
21:59:00 <nimaje> jb1277976: did you update your packages after updating freebsd?
21:59:07 <jb1277976> nope my first update
21:59:21 <jb1277976> so pkg update ?
22:00:50 <nimaje> yes, kernel modules build for the 13.2 kernel will not work on 14.0 for example
22:01:07 <jb1277976> ok
22:01:45 <jb1277976> nimaje: it says all packages are up to date
22:04:18 <nimaje> hm, should have said that it will reinstall a bunch of stuff because of changed abi
22:09:37 <jb1277976> babz: after i blacklist all that what do i do now ?
22:10:04 <babz> what no
22:12:32 <nimaje> seems like you messed up somewhere while upgrading, freebsd-update should have told you to reboot and run it again and at one time to reinstall your packages for the new abi
22:12:46 <jb1277976> ok
22:13:38 <hernan> jb1277976: pkg-static upgrade -f
22:13:44 <hernan> to upgrade all the packages
22:14:52 <jb1277976> hernan: before i did that i ran freebsd-update fetch and it said i had a paritally upgrade pending and it wants me to run install then fetch -F or something
22:15:49 <jb1277976> Thanks everyone for helping me
22:16:41 <rwp> I am not aware of freebsd-update with a -F option but there is a pkg upgrade -f option which you will want to run.
22:17:09 <nimaje> no, first finish the os update
22:17:47 <babz> -F Force freebsd-update fetch to proceed in the case of an unfinished upgrade.
22:18:54 <rwp> Right.  I think the order is close to this: freebse-update -r 14.0-RELEASE upgrade, freebsd-update install, reboot, freebsd-update install, pkg upgrade -f
22:19:22 <nimaje> run  freebsd-update install  again and read what it says at the end about the next step
22:22:43 <rwp> Though I think, not sure this always works but I think, one can pkg upgrade -f before the reboot.  I snagged myself last time because I had changed my root shell to bash from ports and the reboot before the pkg upgrade meant that I booted without a working bash executable.  Oops.  Used the Boot Environment to rescue myself.
22:23:02 <hernan> jb1277976: run freebsd-update to update the OS.. from minor/major versions... ie from 14.0 to 14.1 (minor)  or, from 13.2 to 14.0 (major)
22:23:25 <hernan> jb1277976: and packages are the software that run in the OS.
22:23:58 <hernan> jb1277976: after you do a major OS upgrade, you should probably upgrade  (as in reinstall) all the pkgs
22:24:26 <hernan> what rwp said
22:27:39 <jb1277976> Thanks
22:28:03 <rwp> Now I ensure that I have the toor login also enabled so that I have a backup login shell only in base just in case.  I actually use toor with bash and root with the default.  And then I always use toor which keeps me reminded of my locally modified setup.
22:29:44 <jb1277976> freebsd-version finally says 14.0-RELEASE
22:29:48 <jb1277976> now let me upgrade the packages
22:31:14 <jb1277976> 1397 packages upgrading
22:31:45 <hernan> jb1277976: as rwp said, "freebsd-update install"  should be run twice... once, then reboot, then run again "freebsd-update install" and read the messages in case it says you need to reboot and run "freebsd-update install" again
22:32:22 <rafe> also, update your boot block
22:32:29 <rwp> It's always safe to reboot and run install again.  If there is nothing to do it will also say that upon the re-run too.
22:32:55 <rwp> Bootcode: https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-bootcode
22:32:57 <VimDiesel> Title: Chapter 26. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal
22:33:38 <rwp> Also if /usr/local/bin/pkg the port becomes totally broken by a major upgrade (dynamic libraries in base changed) then run "pkg-static upgrade -f" using the statically linked program to fix it.
22:36:04 <rwp> Maybe just "pkg-static bootstrap -f" to fix just pkg and then a normal "pkg upgrade -f" afterward.
22:56:17 <jbo> when I have a poudriere jail with src=/path/to/freebsd/src do I just update the source at that path and then run poudriere jail -u to update it or do I have to build the source manually first?
23:16:09 <jb1277976> rwp: im using gpt/ufs when i chose the install. was wondering to upgrade the bootvode show i use the man gpt one ? im looking at https://man.freebsd.org/cgi/man.cgi?query=gpart&sektion=8&format=html#end
23:16:10 <VimDiesel> Title: gpart(8)
23:18:42 <RhodiumToad> uefi boot or legacy boot?
23:18:55 <beowuff> How old is your system?
23:19:02 <beowuff> Personally, I only do UEFI these days.
23:19:47 <RhodiumToad> for uefi, it's just a matter of copying loader.efi onto the ESP in place of the loader.efi or bootx64.efi that's already there
23:21:40 <jb1277976> I think mbr cause it's an old system I forgot
23:21:53 <jb1277976> I'm used to gpt
23:21:54 <RhodiumToad> what's the output of gpart show
23:22:12 <jb1277976> Let me go upstairs
23:25:42 <jb1277976> http://termbin.com/t7p7j
23:26:10 <RhodiumToad> so that's GPT (nor MBR) and it's uefi-only
23:26:16 <jb1277976> ok
23:26:44 <RhodiumToad> so all you need is to mount the efi partition and copy loader.efi onto it
23:26:57 <jb1277976> there a guide for that ?
23:28:38 <RhodiumToad> dunno offhand
23:28:52 <RhodiumToad> did the installer put a line in fstab for the ESP?
23:29:06 <beowuff> If I remember right, you just dd the file onto the efi partition.
23:29:09 <RhodiumToad> no!
23:29:27 <beowuff> No?
23:29:48 <RhodiumToad> the efi image file is only for bootable images, not for actual installed systems - it's too small
23:31:00 <jb1277976> Let me look at my fstab
23:32:26 <jb1277976>  http://termbin.com/sg31
23:32:55 <RhodiumToad> ok, so /boot/efi is already mounted? what files are in it?
23:33:35 <RhodiumToad> should be  /boot/efi/efi/boot/bootx64.efi at least, possibly also /boot/efi/efi/freebsd/loader.efi
23:33:50 <jb1277976> yep exactly
23:33:53 <RhodiumToad> details will depend on whether you're using any kind of efi boot manager
23:34:09 <jb1277976> what you posted is what i have
23:34:34 <RhodiumToad> if both those files exist and are the same size and content, then just copy /boot/loader.efi over both of them
23:34:58 <RhodiumToad> if you have just the bootx64.efi, then copy over that one
23:36:59 <jb1277976> http://termbin.com/p18t
23:37:20 <jb1277976> look the same
23:37:44 <jb1277976> i will do this after the package upgrade
23:38:22 <RhodiumToad> those look larger than i would expect?
23:38:35 <RhodiumToad> what fbsd version?
23:38:43 <jb1277976> 14.0
23:39:04 <RhodiumToad> from Feb 24  2022 ?
23:39:25 <jb1277976> those probably carried from 13.2 when i upgraded today
23:43:25 <RhodiumToad> interesting, 13.x loader.efi is indeed much bigger than the 14.x one
23:46:48 <jb1277976> so overwrite loader.efi and bootx64.efi with the /boot/loader.efi ?
23:48:06 <RhodiumToad> yes
23:48:32 <jb1277976> ok
23:49:05 <jb1277976> a reinstall would have been easiser lol seriously though
23:49:30 <jb1277976> but you don't learn anything that way so i can see why people would go this route
23:52:10 <babz> I think I've read xen dom should work in uefi mode now
23:52:39 <babz> (I have not tested it yet)