01:33:38 <mrelcee> i was in here crabbing about freebsd-update to 14.2-betas, RCs and RELEASE all left me with a system stuck at single user..
01:33:49 <mrelcee> well pkgbase worked great
01:34:06 <jauntyd> :)
01:34:50 <polarian> fuck sake, 14.2-RELEASE has taken my laptop out :((
01:34:55 <mrelcee> kinda strange watching pkg grabbing OS files.
01:35:00 <ek> mrelcee: I'm guessing that's the reason FBSD is moving to pkgBase.
01:35:45 <ek> The documentation will certainly need to be update for this, though. And fast.
01:35:55 <ek> *updated
01:35:55 <mrelcee> polarian:  do you have beadmn installed?    revert to the snapshot
01:36:14 <polarian> after reboot, during boot just after decrypting the root the screen resizes as I assume it hands over to the kernel as init is done, anyways this results in what looks like a blackscreen until I realise all the text is in about 3-4 pixels at the top of my screen
01:36:16 <mrelcee> yeah docs were a bit leap of faith.
01:37:01 <polarian> mrelcee: freebsd-update can fallback but I cant get into the system to do so
01:37:35 <ek> polarian: If you using freebsd-update, it should've automatically created a snapshot prior to the update. Use that to rollback.
01:37:46 <polarian> ek: see above :)
01:38:00 <polarian> lets see if I have a 14.1 media lying about
01:38:15 <mrelcee> is your system ufs or zfs on root?
01:38:18 <polarian> zrs
01:38:20 <polarian> zfs*
01:39:07 <mrelcee> should be a option in the boot menu to pick a boot target/snapshot and you can revert to the snapshot freebsd-update makes
01:39:17 <polarian> ooo that might be useful
01:39:18 <polarian> let me see
01:39:47 <polarian> oh shit im an idiot
01:39:51 <polarian> you can literally boot kernel.old
01:39:57 <ek> Yeah. Should be super easy to rollback.
01:40:15 <mrelcee> thats why you havent read about Michigan Man Hulking out 4 times in one month when it took my server down. :)
01:40:52 <polarian> well its almost as if the devs anticipate kernel updates going wrong
01:40:58 <polarian> thanks freebsd bootloader <3
01:41:01 <mrelcee> was annoying needing to drag a display over to it...
01:41:26 <polarian> ugh now I need to go complain to the ML
01:41:38 <polarian> which ML to scream about kernel problems?
01:42:05 <polarian> I hate how freebsd has 101 different ML and I never know which is the right one
01:42:16 <mrelcee> poilarian: this system has gone through 10.1 to present. most of the betas since 11.3, and this is the first time freebsd-update has ever crapped the bed on me
01:42:34 <polarian> haha... so you have experience
01:42:56 <mrelcee> I've...been around!\
01:43:00 <polarian> my laptop was installed on 14.0, 14.0 --> 14.1 went smoothly, but 14.1 --> 14.2 has issues
01:43:10 <polarian> anyways what ML to report issues?
01:43:26 <polarian> or is this something which should be bugzilla'd
01:44:30 <polarian> ah shit the revert didnt work
01:44:42 <polarian> freebsd-update rollback didnt rollback the kernel
01:46:56 <mrelcee> make sure you pick the right one.  it can be tricky
01:51:45 <ek> polarian: You can report it on the ML or Bugzilla. Either is fine. You could use "freebsd-bugs@, freebsd-pkgbase@, freebsd-questions@, freebsd-reproducibility@, or freebsd-testing@ for the report. Any of them will likely point you in the right direction.
01:52:05 <ek> mrelcee: Same goes for you. I believe we spoke about this a day or two ago and you ran into similar issues?
01:52:18 <polarian> ek: you see what I mean
01:52:22 <polarian> why so many mailimg lists
01:52:34 <polarian> OpenBSD has bugs@ and misc@, the rest are pretty dead
01:52:53 <ek> polarian: Well, they get pretty specific, but if you post to one and it isn't correct they'll tell you where to post it.
01:53:23 <ek> Generally, I would use bugs.freebsd.org since they can just move to where ever they need to.
01:53:27 <polarian> ahhh shittttt
01:53:38 <polarian> zroot cant be found after reverting
02:02:40 <ek> polarian: You should be able to tell it where to find the bootloader in zroot.
02:03:07 <polarian> fuck it im just rolling back to the snapshot
02:03:17 <polarian> I did like 10-20 mins of work after it which I will forgo
02:03:25 <ek> Also, are you using any of the i915 drivers, by chance?
02:03:35 <polarian> errrr yes?
02:03:59 <polarian> lol by chance has it been reported?
02:04:26 <ek> mrelcee: Were you not using the same? I saw something recently where people were saying that was a problem. You just had to rebuild it after the upgrade But, something unexpected, for sure.
02:05:10 <ek> polarian: Not sure about the reports. I think I saw it on forums.freebsd.org yesterday or the day before.
02:05:26 <HER> repost: i upgraded to 14.1 -> 14.2 on 2 different intelgpu machines. one worked fine and the other gets stuck when loading i915kms. by stuck i mean if i leave it enabled on boot, it gets stuck on the "Loading kernel modules:" phase. And if i kldload i915kms it attempts to load some _bin and then gets stuck
02:05:28 <ek> I'm not aware of any "official" reports.
02:05:57 <ek> HER: That sounds about right.
02:06:18 <polarian> thank god, I typed some bs and my system booted with default kernel
02:06:25 <polarian> lets hope the rollback didnt remove data
02:06:54 <HER> i had to rollback on the broken machine
02:07:07 <HER> sucks but it was nice the rollback worked
02:07:38 <ek> polarian: Which rollback do you mean? A beadm snapshot rollback or like a VM snapshot rollback?
02:07:56 <HER> i meant freebsd-update rollback
02:07:59 <ek> HER: Also, same question to you. Which rollback did you use?
02:08:06 <ek> HER: Gotcha'. Thanks!
02:08:42 <HER> and pkg upgrade -f
02:10:05 <polarian> ek: freebsd-update rollback, twice the first time didnt work and the default kernel was still 14.2, this worked but then no zroot was being detected, so I booted kernel.old and that could see zroot so rebooted, booted default kernel with the autosnapshot from freebsd-update... that worked, so I zfs rollback to the autosnapshot and it works now
02:10:14 <polarian> and I appear to have no data loss
02:10:28 <ek> Hrm. I'm wondering if this solution would help with the upgrade (not just a fresh install?): https://forums.freebsd.org/threads/boot-hangs-after-loading-i915kms.95904/
02:10:43 <ek> But, it definitely seems like there's an issue. Hopefully, resolved soon.
02:11:33 <ek> polarian: A freebsd-update rollback would never lose any data (unless something failed, of course.) It will always be the snapshot taken just before the upgrade took place. It's the beauty of ZFS!
02:11:52 <polarian> ek: well idk it didnt work so I manually restored the snapshot
02:12:03 <polarian> but the snapshot restores the entire system no?
02:12:15 <polarian> I didnt reboot immediatrly after install, I was working on some code
02:12:28 <polarian> I see no noticable code loss
02:12:42 <polarian> so I am not sure if my home dir is included in the snapshot or not
02:12:47 <polarian> whats the scope of "default"?
02:13:25 <ek> polarian: It should be a recursive snapshot of zroot when using freebsd-update. So, yes, restores the entire "system" (nothing outside of /boot.)
02:13:32 <polarian> ah yes I forgot zfs mounts /home/<user> separstely
02:13:46 <polarian> I am not used to zfs on desktop :)
02:14:32 <ek> Yep. Any of the "system" changes would be reverted. Anything outside of that will still be included in the mounting and whatnot, but wouldn't be changed at all. Right where you left it.
02:14:37 <polarian> tbh I barely used zfs... even after almost a year its still a headache
02:14:49 <polarian> must take years for people to feel fluent and confident in xfs
02:14:50 <polarian> zfs*
02:15:51 <ek> What!? ZFS is one of the easiest FS's to use ever! Granted, it can really get involved and things go really deep. But, basic maintenance and recovery is so quick and simple!
02:17:02 <ek> Look how easily it saved your booty and you didn't even know what you were doing. It's that good.
02:17:05 <polarian> ek: well I can scrub, snapshot that stuff
02:17:13 <polarian> but when things go wrong I am a little clueless :P
02:17:21 <polarian> not to mention the shit ton of properties you can modify with set
02:17:23 <ek> polarian: Yep. Run a scrub whenever you want.
02:17:47 <polarian> now to avoid me making myself look bad, during the boot process when the screen resizes
02:17:54 <polarian> what is this... I am not a boot engineer :P
02:18:01 <polarian> I assume this is the loading of i915
02:18:08 <ek> polarian: Don't even worry about the properties and modifications to datasets and such. Just use it as default.
02:18:15 <polarian> and the handover from the init (as its just after decrypting the root partition) to the kernel
02:18:23 <polarian> wait no the kernel is booted
02:18:45 <polarian> ek: I know :P I am just saying zfs is much bigger
02:19:21 <ek> It's probably the kernel module just having fits (I don't know the reason.) You can choose to unload it, rebuild it, and reload it. See if that works.
02:19:35 <ek> Is it still doing the same thing after the rollback?
02:19:38 <polarian> ek: my point is how to explain it
02:19:47 <polarian> no
02:19:51 <ek> Okay. Good.
02:19:53 <polarian> 14.1 is fine... after I manually rolled back
02:20:01 <polarian> freebsd-update rollback fucked it up somehow
02:20:17 <polarian> or maybe I fucked it up
02:20:47 <ek> If you're talking about reporting the issue, just explain what you're seeing. You don't need to go into crazy detail about anything. What they need from you, if anything, they'll ask for.
02:21:27 <polarian> anyways I am trying to figure out how to explain it, during the booting of freebsd just after disk init (if you are using geli, the disk being decrypted) the screen resizes and starts with running rc init
02:21:33 <polarian> services, wifi etc
02:21:42 <ek> I'd definitely mention you're using the i915*, though, as it seems to be a culprit for many. Other than that, if you have logs or something, great! If not, it is what it is.
02:21:53 <polarian> so I assume that switch is where the graphics driver is loaded...?
02:22:06 <ek> Yes. Likely.
02:22:17 <polarian> imma sound like an idiot in this bug report :(
02:22:23 <polarian> I know none of the correct terms
02:22:48 <polarian> hey ho, lets be optimistic, at least it isn't the openbsd mailing list I have to report to :(
02:23:02 <ek> polarian: "If you disable that graphics driver and try the upgrade again, does it work? If not, try pulling *log* *log* *log* etc..." will likely be their question.
02:23:37 <polarian> https://lists.freebsd.org/archives/freebsd-bugs/2024-December/023460.html
02:23:39 <polarian> hmmm
02:24:32 <polarian> it could also be libreboot which is the problem
02:24:40 <ek> There's no such thing as a bad bug report. Any feedback is good feedback. This isn't Linux where you'll get flamed for being "stupid" or something. If they can fix or make things easier, even if it's for beginners, they appreciate the info.
02:24:51 <polarian> I have coursework to do I really dont have time to debug kernel issues
02:25:33 <ek> Understood. That's kind of the expectation of a -RELEASE. :)
02:25:48 <polarian> dmesg.today and dmesg.yesterday only contain logs from 14.1 hmmm
02:25:56 <polarian> does .today --> .yesterday every boot or something?
02:26:20 <polarian> oo might be something in messages
02:28:43 <polarian> ahhh....
02:29:01 <polarian> I was right, drm is loaded (along with the driver) right after disk decryption
02:29:06 <ek> dmesg and messages should actually have info from current boots. They're likely parts of the /var ZFS dataset/vdev/whatever you have setup.
02:29:09 <polarian> so I think its safe to say i915 might be the issue
02:30:00 <ek> polarian: That's my guess based on other reports. You could disable it, retry the upgrade, and then rebuild/re-enable it and see if it works.
02:30:07 <ek> ... provided you have the time at some point.
02:30:07 <polarian> welp I see all 14.1 boots, not a single 14.2, rollback rollbacked logs?
02:30:17 <polarian> but logs have their own volume
02:30:56 <polarian> ek: well I just have to remove it from rc.conf
02:31:15 <polarian> well not even remove, just uncomment it
02:31:54 <ek> polarian: Right. Just disabling however you're including it in the boot procedure should be sufficient.
02:32:16 <polarian> welp I got coursework, no time to piss about right now
02:32:36 <ek> 14.2-R might come right up. However, re-enabling it in 14.2-R might still be a problem (based on what I'm seeing in reports.)
02:32:52 <polarian> -R meaning?
02:33:07 <ek> Not sure if they're rebuilding from ports, using the binary packages, or just re-using the binary stuff they had from 14.1. Hard to say. It's still a really new issue.
02:33:19 <ek> polarian: -RELEASE? Is that not what you're upgrading to?
02:33:39 <ek> Sorry. Should have been more specific.
02:33:52 <polarian> ohhh
02:33:58 <polarian> -R means RELEASE
02:34:03 <polarian> duh... I am stupid
02:34:03 <ek> -S = STABLE, -R = RELEASE, -C = CURRENT, etc...
02:34:09 <polarian> yeah I realised now
02:34:11 <polarian> lol
02:34:29 <ek> Nah. Not stupid. Confusion happens.
02:34:42 <polarian> anyways I will look into it tomorrow, thanks for the help though :)
02:34:47 <polarian> and for curing my stupdiity...
02:34:57 <polarian> its 2:34am and I got to get some of this coursework done before I pass out :P
02:35:09 <ek> Haha. Any time. Hopefully, everything goes well. G'night!
02:35:14 <polarian> gn
02:35:51 <polarian> wait just as I said that
02:36:36 <polarian> ek: https://lists.freebsd.org/archives/freebsd-questions/2024-December/006045.html
02:36:42 <polarian> haha... I am not the only one
02:37:25 <ek> Most certainly not! Hrm. I'll have to test this myself when I get a chance.
02:38:12 <ek> Obviously sc(4) shouldn't be used anymore in favor of vt(4)
02:38:33 <ek> polarian: Are you using any special settings for vt()?
02:39:10 <ek> ... or, you know, be responsible and check it all out later. :)
02:39:13 <polarian> ek: actually no I realised its not the same
02:39:24 <polarian> theirs is failing in early boot
02:39:31 <polarian> I dont think it ever enters the freebsd bootloader
02:39:55 <polarian> ugh fuck I got excited there :(
02:40:08 <ek> polarian: Yeah. I would think a sc() / vt() issue would happen pretty early. I'm guessing you're just seeing the same i915 driver issues others are seeing.
02:40:17 <polarian> yes probably
02:40:25 <polarian> I saw i915 in the dmesg
02:40:30 <polarian> and thought "score this might be the same thing"
02:40:34 <polarian> buttt no :(
02:40:55 <ek> I think once they sort out their vt() issue, they're going to also see a i915 issue. Haha
02:41:05 <polarian> yikes...
02:41:11 <polarian> thats going to be a hell of a night for them
02:41:37 <ek> Well, with any luck, they'll both be sorted out soon and contributed.
02:41:52 <ek> s/contributed/committed/
02:42:08 <polarian> ehhh for now 14.1 works :)
02:42:15 <polarian> the joys of freebsd, you aren't forced to update quickly
02:42:27 <polarian> 14.1 still has what? 6 months left until its dropped?
02:42:38 <ek> I'm happy with it at the moment.
02:42:44 <ek> It has a while, yes.
02:43:05 <ek> You should probably get to that coursework while you still have the chance. :)
02:43:52 <polarian> EOL on March 31, 2025
02:45:20 <ek> Yeppers!
02:45:34 <polarian> 15.0 in 1 yr \o/
02:46:02 <ek> I'm looking forward to the 15 release, for sure.
02:46:07 <polarian> I still haven't done the october update for libreboot as well...
02:46:41 <ek> You might wanna get your updates.
02:46:59 <polarian> I like to compile it from source... I am fussy like that
02:47:38 <ek> Better safe than sorry. I compile anything I *REALLY* need to function as expected.
02:47:42 <polarian> and it means getting my spare laptop out, which I have bubble wrapped up from my trip to Germany... and then I have to get my flasher out take apart laptop and yeah
02:47:56 <polarian> I *could* internal flash. but I see that as ruining the fun
02:47:58 <ek> But, I also mix ports and packages. So, there's that.
02:48:13 <polarian> im insane so yeah :)
02:48:30 <polarian> I have wanted to get into porting... and also building some ports
02:48:33 <polarian> just... no time :(
02:49:24 <ek> I'm a port maintainer also. It does take a little time to learn, but it's pretty easy (mostly.) Once you understand it, it's a lot of fun! I would highly suggest it.
02:50:58 <polarian> I used to package for Linux, not very well, but I get the jist of the process, its just learning the different tooling :)
02:51:10 <polarian> https://people.freebsd.org/~rodrigo/fosdem25/ <--- anyone going to fosdem bsd track next year?
02:51:32 <polarian> devroom whatever you wanna call it
02:54:34 <l00py> 15.0 is when pkgbase lands?
03:13:12 <kevans> lands may be a misnomer; it's been developed in-tree for years now, but hopefully we switch to it in 15.0, yeah
03:16:38 <ek> Yep. pkgBase has been available for a while now. I use it all the time.
03:17:33 <ek> But, it's a lot more steps than freebsd-update (and not officially documented (as far as I know.)) So, hopefully, that's rectified soon.
05:19:43 <mrelcee> l00py I used pkgbase for the first time tonight installing 14.2
05:20:00 <mrelcee> documentation is just... meh
05:20:11 <mrelcee> enough, though
09:52:39 <jgh> any known issues with FreeBSD VM networking under Fedora 41 ?   40 was ok, but now both my fbsd 13 and 14 are failing (as does a fresh 14.2 qcow2)
10:40:39 <mzar> jgh: maybe you should run Fedora under FreeBSD then
10:40:51 <mzar> it should work
10:49:57 <Hecate> Fedora/kfreebsd
13:09:55 * Alver wonders if he woke up in 1998 again
13:13:09 <polarian> Security question: So as you would do in a VM, you usually would create a non-root user and give it doas/sudo/whatever access and only privilege escalate when needed, is this recommended to do in jails as well or???
13:16:00 <Alver> Everywhere, yes.
13:16:21 <Alver> But the consequences of not doing it in jails should be lower than in a VM, so...
13:20:28 <polarian> thought so
13:20:40 <polarian> *common sense tbh*
13:20:52 <polarian> Whats best for virtual interfaces, veth?
13:20:57 <polarian> for jails that is
13:24:39 <polarian> well jails have vnet jails, but I mean in general, what would be used if you needed a virtual interface which acts as a phy but sits on top of it
13:27:08 <polarian> ah I think what I am trying to describe is epair...
13:30:44 <Alver> A "standard" jail will share its IP stack with the host. A vnet jail will not. Choices :)
13:31:15 <Alver> I have a few of both on the same host. Sketchy stuff gets its own vnet, trusted stuff does not
13:31:39 <polarian> hmmm vnet by default wouldn't be a big deal... gives you more control with pf
13:31:50 <Alver> It does indeed. Also more overhead to manage, of course
13:32:05 <polarian> hmmm true...
13:32:23 <Alver> (although jails shouldn't have too many changes to pf anyway, once it's running
13:32:27 <polarian> I guess its the balance between security and ease of use
13:32:37 <polarian> you dont want too much security that your device is a pain in the arse to use
13:33:00 <Alver> I don't really notice it much, really; just the setup takes a bit more time
13:33:18 <Alver> And if the host is internet facing, there's the IP allocation thing to consider
13:33:32 <polarian> would epair be the standard interface you would use for virtual ethernet?
13:33:55 <polarian> as described in the man pages, its an virtual ethernet-like virtual device which is virtually connected to the physical port
13:34:03 <polarian> the analogy given ^
13:34:54 <Alver> I'm not going to pretend I'm that much of a low-level BSDer. But the vnet jails I created (using Bastille) all use epairs it seems, yes
13:37:40 <polarian> lol, good enough :P
13:37:42 <polarian> thanks for the help
13:37:49 * Alver has had to do some stupid shit too to make the vnets work on Hetzner
14:24:48 <babz> so... rebuilding drm-kmod fixed the issue for me
18:14:14 <l00py> trying to install 14.2 on a box with 4 nics. put cable in nic "1". ifconfig says no carrier though. any ideas?
18:15:19 <l00py> config is on bge0
18:17:14 <lts> 0 vs 1?
18:17:40 <l00py> nah on the ports it's labelled 1-4 but ifconfig shows them as bge0-3
18:17:53 <l00py> dell poweredge r720 turdbox
18:18:36 <Tenkawa> never assume the os sees them the same.... still test them all
18:19:07 <l00py> ya you're right my bad brb
18:19:49 <Tenkawa> Fortunately x86 isn't as picky but I've been bit by this a lot in the arm world with u-boot and device tree mismatches
18:21:16 <l00py> nic 3 is bge0 "nice"
18:21:31 <l00py> will that be stable across reboots atleast?
18:22:17 <Tenkawa> Heh that "is" a good q
18:22:52 <lts> :-D
18:22:56 <Tenkawa> I would "think" so but I haven't worked on enough multicard boxes in years
18:23:01 <l00py> i'll go try 3 reboots
18:23:08 <Tenkawa> mine are all multi nic single  card
18:23:22 <Tenkawa> (sbcs)
18:30:58 <l00py> ya mine too. 4 nics on 1 card
18:32:28 <l00py> 1 reboot good, 2 more to go
18:35:32 <l00py> 2 down
18:36:07 <l00py> now what i'm wondering is if other boxes with the same exact hardware specs will also recognize nic 3 as bge0. that'll be fun to test
18:36:22 <Tenkawa> Yeah I'm thinking it "should" hold as long as you don't move cards or add another nic...
18:36:32 <l00py> yep
18:36:41 <Tenkawa> not sure where it will "align" heheh
18:36:51 <l00py> we're gonna find out hehe
18:37:26 <l00py> any opinion on if i should let the OS handle cpu ratcheting (speedstep) or leave it to the bios?
18:37:52 <Tenkawa> I had to let the bios (I have a laptop that has some oddness)
18:38:07 <l00py> this is a server
18:39:08 <Tenkawa> oh.. I just had a thought on your nics... I can't remember "how" but I think there is a way to do this for the wired similar to wifi to bind a specific one...
18:39:33 <Tenkawa> wlans_rtwn0="wlan0" in rc.conf
18:39:56 <Tenkawa> that made sure rtwn0 always ended up as wlan0
18:40:19 <Tenkawa> but I'm not sure if there's the equiv for that wired driver
18:40:52 <Tenkawa> I have 2 wifi cards in this box
18:42:08 <l00py> ok 3 reboots all good
18:42:16 <Tenkawa> excellent
18:42:29 <l00py> i guess there's no way to bind all 4 nics to 1 alias and have it just use whatever has a cable plugged in?
18:43:00 <Tenkawa> I'll defer that to someone with a bit more setup experience here
18:54:01 <jauntyd> l00py: you can use a tap device to bind them all together
18:54:10 <jauntyd> it's a virtual device
18:55:06 <jauntyd> man tap ;)
18:56:00 <mzar> l00py> i guess there's no way to bind all 4 nics to 1 alias and have it just use whatever has a cable plugged in? - lagg(4) failover
18:56:13 <jauntyd> lagg yes sorry
18:56:39 <jauntyd> ty mzar
18:56:57 <mzar> FreeBSD netwoking stacky is pretty decent
18:57:47 <l00py> i'll read on lagg ty
18:58:09 <l00py> any opinion on using OS to manage cpu ratcheing vs bios? (dell poweredge r720 fwiw)
18:59:00 <mzar> ratcheing ?
19:01:04 <mzar> you are likely asking about powerd(8)
19:01:39 <mzar> but for r720 it has to be first allowed in BIOS
19:02:13 <l00py> ya i changed bios to performance per watt (OS) mode
19:02:17 <l00py> powerd can now load
19:02:26 <l00py> but which is better? let bios manage or OS?
19:03:38 <mzar> I am always using powerd, BIOS is probably better if you run OS like DOS
19:04:27 <mzar> there is another power deaemon in ports, so people say it's better
19:04:35 <mzar> s/so/some
19:06:47 <l00py> i'll just use powerd tyvm
19:07:24 <mzar> sysctl dev.cpu | grep freq will tell you more
19:14:08 <mzar> to monitor CPU temp for intel CPUs load coretemp.ko with kldload(8) and to check issue command: sysctl dev.cpu | grep temp
19:14:29 <mzar> there is another module for AMD processors
19:21:40 <l00py> do i care to monitor those or just let powerd work with the profile i give it? adaptive high iirc
19:23:35 <mzar> I provided it in case you want to check
19:24:06 <mzar> don't bother with this if you have conditioning in server room
19:26:12 <mzar> l00py: are you evaluating FreeBSD or switched to it for any purpose ?
19:45:26 <l00py> using it for everything i can
19:45:36 <l00py> i just have a cold house hehe
19:45:43 <l00py> ty though i made notes on those
19:46:29 <l00py> mzar got linux servers at work i'm converting over to freebsd
19:46:40 <l00py> have all freebsd at home
19:47:33 <l00py> i did a fresh 14.2 install, got network, but can't get dns to resolve. i used my home router ip as dns server. my laptop (linux atm) is set up to use home router ip as dns server and it can resolve fine. any tips to debug why it's not working?
19:50:36 <mzar> check resolv.conf, check connectivity and finally you can use tcpdump(1)
19:56:08 <l00py> resolve.conf has 127.0.0.1, i selected local_unbound in install
19:56:31 <l00py> btw the ufs setup in bsdinstall still has mbr as the default instead of gpt even tho gpt is what's preferred so why's that?
20:05:20 <Tenkawa> thats odd... mine setup as gpt
20:05:51 <Tenkawa> and I installed just 2 days ago using  FreeBSD-14.2-RELEASE-amd64-dvd1.iso
20:06:18 <Tenkawa>  gpart show
20:06:18 <Tenkawa> =>       40  976773088  nda0  GPT  (466G)
20:06:18 <Tenkawa>          40     532480     1  efi  (260M)
20:06:18 <Tenkawa>      532520       1024     2  freebsd-boot  (512K)
20:06:21 <Tenkawa> ..
20:09:52 <l00py> was it the default selection in the partitioning menu tho?
20:09:57 <Tenkawa> yes
20:10:05 <Tenkawa> I took all defaults
20:10:06 <l00py> i'm using disc1 and mbr was default selection
20:10:44 <l00py> for ufs
20:11:01 <Tenkawa> is your "machine" uefi capabb;e?
20:11:07 <Tenkawa> er capable
20:11:50 <Tenkawa> (or enabled in bios)
20:12:08 <Tenkawa> It could still be turned on legancy/mbr
20:12:18 <Tenkawa> er legacy
20:12:41 <Tenkawa> Some bios are that bad broken
20:18:30 <l00py> i think uefi is an option but i'm in bios mode
20:21:13 <brutex> how can i recompile kernel with realtek lan drivers my freebsd 14.2 doesn not recognize LAN it's a realtek 2.5GHz i want to recompile it with realtek lan support?
20:21:26 <brutex> and then to restart the network service
20:23:40 <Tenkawa> l00py: unless I am wrong.. I think if your bios is set to mbr mode the install default to mbr... don't quote me though
20:24:41 <Tenkawa> brutex: what bus? (pci/usb?) and do you have the major:minor if usb?
20:28:11 <brutex> Tenkawa: it's a integrated LAN into motherboard
20:28:59 <Tenkawa> Ok that would be a pci then... what type of motherboard?
20:29:18 <brutex> PCI
20:29:47 <Tenkawa> no.. vendor & model
20:31:05 <Tenkawa> without that no way to tell what driver (realtek has numerous drivers and models of devices.... only certain ones work in freebsd... )
20:32:43 <mzar> you can boot from GPT in BIOS mode almost all the OSes
20:32:54 <brutex> Tenkawa:Realtek RTL8125 Gaming 2.5GbE Family Ethernet Controller	PCI  Connection Speed	1 Gbps MTU	1500 bytes this is - Intel Alder Point-S PCH - CNVi: WiFi Controller	PCI wifi adapter with antena which also cannto be found
20:33:36 <mzar> Gaming 2.5GbE Family Ethernet Controller - that's interesting
20:34:12 <Tenkawa> mzar: of course... but many bios's support hybrid booting... which could be why it defaulted his partition table to default to mbr instead of uefi like mine
20:34:31 <Tenkawa> or it could be turned completely off
20:34:52 <mzar> I never trust the installer, just do it by hands
20:35:16 <Tenkawa> Nod.. I doublecheck the installer but its been good so far
20:37:07 <Tenkawa> brutex: man if_re
20:37:24 <Tenkawa> you need to enable that driver for the ethernet card
20:38:24 <Tenkawa> hmm.. I dont see 8125 in its manpage though
20:39:57 <Tenkawa> mzar
20:39:59 <mzar> there is port net/realtek-re-kmod
20:40:00 <Tenkawa> oops
20:40:11 <Tenkawa> yeah I was about to ask you about net/realtek-re-kmod.
20:40:24 <mzar> it will support Gaming Family
20:40:29 <Tenkawa> Ok good
20:40:50 <mzar> brutex: welcome to FreeBSD family
20:41:30 <Tenkawa> mzar: specialty hardware in general.... I got an HP thats annoying like this for Linux too...
20:42:50 <brutex> Tenkawa: i don't understand you how can i enable i-net
20:42:51 <mzar> brutex: please issue command "pkg install net/realtek-re-kmod" and follow
20:43:03 <brutex> Tenkawa: i need if_rl_load="YES in rc.conf?
20:43:28 <mzar> nope
20:43:42 <brutex> mzar: without net i cannot run pkg
20:43:53 <brutex> then?
20:44:13 <mzar> read the pkg message again
20:44:17 <brutex> what is point of meaning
20:44:29 <mzar> or read it here https://www.freshports.org/net/realtek-re-kmod/
20:45:11 <brutex> ok
20:47:03 <mzar> 21:43 < brutex> mzar: without net i cannot run pkg - that's chicken - egg problem, you have to bring this package somehow and install it
20:47:45 <Tenkawa> download it to a msdos formatted flash drive
20:48:45 <Tenkawa> you can then mount that on the machine and install it .. or is this your only os?
20:48:58 <brutex> ok
20:49:00 <brutex> thank you
21:00:42 <l00py> if installer has a prob it should be fixed not just ignored tho no? i mean we want the noob onramp to be smooth otherwise linux will keep eating the cake and linux sucks
21:01:00 <l00py> not saying it has a prob, just in principle
21:02:38 <Tenkawa> l00py: which problem?
21:05:31 <l00py> just said there isn't 1 and that it's in principle
21:06:13 <Tenkawa> Ah ok
21:11:53 <l00py> kldstat didn't show cryptodev, then i ran kldload cryptodev and it showed it. so does that mean it's supported or is it possible to load a kernel module that has no benefit?
21:12:11 <l00py> i guess what i mean is how do i know if my hardware supports that kernel module?
21:16:23 <brutex> without inet how can i use pkg
21:16:42 <brutex> to install realtek-re-kmod
21:16:43 <brutex> pkg install net/realtek-re-kmod
21:20:55 <mms> it's problem with DRM mod
21:21:50 <mms> ah, sorry
21:37:12 <brutex> then how can i enable inet
21:37:32 <brutex> to recompile kernel with rlt drivers?
21:43:05 <brutex> make buildkernel installkernel KERNFAST=1 && reboot ?
22:05:23 <l00py> is there even any point to loading the cryptodev kernel module anymore?
22:16:35 <mzar> brutex: pkg add name.of.the.file
22:24:10 <mzar> brutex left, but file for him is here https://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/realtek-re-kmod-1100.00_1.pkg
22:49:43 <l00py> in a scripted bsdinstall with ufs, is SCRIPTEDPART="mfid0" not enough? bsdinstall prompted me if i wanted to use mfid0 or mfid1 but why prompt me when i already set the env var in the preamble?