In my /var/log/messages I see this: Jan 19 14:17:45 caladan kernel: , 40005.

followed by: Jan 19 14:17:45 caladan kernel: .

and then the system (freebsd-13.1-RELEASE-p3) shutsdown

rtprio: I have a few boxes where I'm working towards (native UEFI) HTTP boot, but the last few years, everything has been squished down into large boxes that run lots of jails

so mainly I run jails

not much netbooting

was following your post, and ipxe

i remember doing this with pxe, not uefi back a number of years ago; but of course didn't have it in a repo and none of my notes survived

so ipxe yes its very neat

on some systems I need to ipxe off a USB drive or via DHCP, I have that set up here

it's nice to skip the tftp part, which was a pain

but since ISC DHCPD went out of support I switched to kea (easy) but haven't set up the ipxe bits

what I really like is that ipxe announces itself as a different client so the config is super easy

i'm trying to do it in bhyve until i can burn a spare system for the netboot.

rtprio: I have all the bits here, I just haven't used it for a couple years

feel free to AMA, I can PM any configs I have

i get the freebsd efi loader but it stops there and i can't tell what it's stuck on

and with pxe i do remember setting up the mfsroot but i'll be damned if i can find any useful docs on that now

rtprio: docs.skunkwerks.at/s/CcaZ2X0Uu#

Title: HTTP booting FreeBSD - HedgeDoc

Title: dpaste/MXUO (Plain Text)

rtprio: down the bottom it has a bhyve boot

I'm busy atm but feel free to bug me in a couple hours with questions

will the loader just know to fetch everything? only /ipxe.efi is hit on my httpd logs .

and the BHYVE_UEFI_CODE-devel port i think was deleted

yeah the UEFI code port is moved/gone/changed sysutils/bhyve-firmware now I think?

hello

is there any ruleset numbering convention?

"CPPFLAGS is supposed to be for flags for the C Pre-processor; CXXFLAGS is for C++ compiler flags."

I assume that's just a syntax thing and semantically it still turns out the same?

_xor: what do you mean?

If you're compiling C, obviously CXXFLAGS won't be used, for example

yes. c++ may use all, but it is good to regard compilation stages with them

you may be come up with more variable other than CPPFLAGS in terms of compilation stages...

* you may come up

_xor: note i didn mean you create new variable. there are already conventions.

what version is have now in freebsd?

ASHER: it depends on what freebsd you talk about

i have now version 13

is have more version?

I meant more along the lines of how does it affect the flags for the compilers out there when compiling C++ code. Is CPPFLAGS vs. CXXFLAGS a historical artifact? Is one preferred over the other? If you pick lets say 10 random compilers, and everything else being equal, would the results be the same or could those be interpreted differently?

ASHER: freebsd.org/releng

Title: Release Engineering Information | The FreeBSD Project

i cant make upgrade Fetching metadata signature for 13.2-RELEASE from update2.freebsd.org... failed

ASHER: CURRENT aren't meant to do binary update

what is mean?

ASHER: CURRENT is not "version is have now" like you said

now i a have FreeBSD 13.1-RELEASE-p3 GENERIC

_xor well when make was first written in the late 70s (?) there was no C++

ASHER: freebsd-version -kru

I don't know bsdmake very well, but GNU make can print all its default rules (gmake -p)

and aha, true, that's a future version

ASHER: You're on the latest version.

yes

ASHER: please visit the link previously provided

13.1-RELEASE-p5

but i try to do upgrade and is falid

there's nothing to upgrade to right now

make itself does not know anything about CPPFLAGS/CFLAGS/CXXFLAGS, it's the glue in *.mk files that cares about them; as it stands, /usr/src/share/mk and /usr/share/mk do NOT process CPPFLAGS at all

yuripv ugh afair both Solaris and GNU make always used these default variables

maybe not SunOS

make doesn't care about them, various rules files provided with them could

You can see FreeBSD make's implicit rules with "make -dg1" (do it in a directory with no makefile)

CPPFLAGS isn't used by FreeBSD's make.

The portable implicit rules are listed here pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

Title: make

(also no mention of CPPFLAGS, but not of CXXFLAGS either since POSIX doesn't specify any C++ stuff)

great for 1970s nostalgics

can buid Fortran but not C++

ASHER: try upgrade on February 10

ASHER: sorry March 27

I should really learn make some day, it's really quite nice.

What little I do know has let me make makefiles so much smaller.

it's all a nightmare

why so?

writing makefiles for a large project is difficult, particularly if you want to have parallelism

ok what i can to do with a bug i try run cpan -f -i re::engine::RE2 and i get error bsd.to/W7B3

Title: dpaste/W7B3 (Plain Text)

generally large projects use recursive make which is hard to parallelize efficiently (the main thing about make is that by seeing all dependencies it can optimize job execution)

so we now have CMake which is all singing and dancing and 100x more compilcated than make

aha, true... i haven't been compiling big things

mostly just little things like tinyfugue and fbmuck

ASHER: i forgot how i did. very familar error message though lol

how i can fix it?

someone please help?

sorry i have no access to my vm not.

ASHER: have you also tried the FreeBSD Forum?

no

The version in dgl's git repo built fine for me on 13.1

Title: GitHub - dgl/re-engine-RE2: re: :RE2 - RE2 regexp engine interface for Perl

yes but is make error

is no have explain install re2 in 13.1

paulf: we also have mason and ninja and whatnot

meena they look quite nice but don't have the time to learn them

I'm easy to learn.

but difficult to master ;)

Why would I use kld_list to load a kernel module in rc.conf over loading it in my loader.conf file?

I ask because the FreeBSD manual recommended to put kld_list="i915kms" in rc.conf for my gpu.

AReal486: when you install the KMS package, there is a message after install suggesting where/how to config, I'd suggest following that.

zykotick9 maybe that's where I remember seeing the recommendation when installing the kms package. Any reason for the two ways to load modules?

how to display the post-install messages later?

AReal486: I have no knowledge for the multiple options... dunno

wwt: I believe "pkg info -D -x foo" might work

AReal486: mostly, because it's faster. rc.conf loads then all at the same time, loader.conf loads then sequentially.

ASHER: there's a limit to the amount of memory that can be addressed by the loader, which is rather small - so if you're loading lots of things it can cause problems.

about what you talk?

about this? cpan -f -i re::engine::RE2 and i get error bsd.to/W7B3

Title: dpaste/W7B3 (Plain Text)

Sorry, no - wrong person :/

That was supposed to have been to AReal486 but they apparently left?

man pkg does not explain -D and -x. -D is mentioned only in the examples section. who said that freebsd is well documented?

man pkg-info, wwt

subcommands have their own man pages

ah, ok. thx ;)

:D

or "pkg help info"

Tbh I find man pages hard to read

I like man pages a lot, but I know they cannot be the only thing around. Beginner guides are very important, so I like the FreeBSD Handbook a lot.

They become easier to deal with in Emacs man-mode.

I consider it a true tragedy that the Volume 2 of the manual no longer exists

i.e. the USD, PSD, etc

Yeah the handbook is much easier to read

these things docs.freebsd.org/44doc

Title: 4.4BSD Documents

wish they were kept up to date

but Legal Issues

cracauer: Yeah true Emacs' man mode is great

I believe only NetBSD includes the volume 2 man pages in base now, iirc. FreeBSD did when I began using it but they were removed sometime in the last couple years

indeed, they were out of date

but still useful...

nowhere else will you find details on commands like fsck and trek

The thing is with man pages you have to search alot and it's annoying that the examples section is right at the bottom, I usually navigate man pages by searching

Hmm, regex usually seems to work

i guess it depends on the page...

xtile: yeah

using "less -I" helps to make searches case-insensitive

man pages make good reference documents when you already understand things and just need to look something up but man pages are not good at tutorial documents.

Agreed.

That's where the handbook is a really needed reference. And other tutorial documents.

The original Unix 7th edition manual always had the 2a and 2b volumes for tutorials .w.

I also use emacs and so emacs man mode with the hyperlink'd See Also section is nice.

rwp: yes I think that is what's needed more, tutorial documents, the handbook is great for that lile you said

like*

The handbook could use a refresh for parts of it too. Everything ages and it is easy to not do anything about the documentation until it is actually broken.

If it isn't broken then it is easy to just let it age.

I am a relatively newbie myself with FreeBSD and so I am reading a lot of the documentation for the first time. And finding some parts wanting.

The man pages tell you what you can do but not why you should do it

rwp: always good to make bug reports or at least notes on that

before you become no longer a newb, and forget

forget what was hard...

And man pages document ever possible option. Some like rsync have a godzillian options. But mostly only rsync -av src dst is most typical.

yeah. It is hard to write documentation for people at a different level than you are.

I'm starting to love portgrep. Just wanted to say it.

what does it do? Just showing where a port is located?

wwt: do also note that pkg(7) also exists, although it's only used for bootstrapping pkg(8)

Ok, this is getting annoying now. em2 on my gateway seems to randomly become unresponsive. The system shows it as being up, but it stops responding to ping.

No messages specific to it in /var/log/messages either.

It comes back online when I do `service netif restart em2`.

_xor: I think em0, like all iflib drivers, have some debugging that you can try your hand at

Is em0 on a dual- or quad-port NIC?

It's em2, and I don't remember off-hand. I'm pretty sure em2 is a standalone NIC. em0 & em1 might be on-board or a dual-port, will look in a bit.

If there's a dual-port NIC with the two first NICs, it could very well be that the NIC for em2 is just dying if the others aren't doing it.

The only thing I'm noticing is that dhclient seems to log a host is down message to /var/log/messages around the time when em2 goes offline (I think). Not sure if dhclient is somehow messing with it, but it shouldn't be I don't think.

Could be. I do have a quad-port NIC laying around somewhere. Might be worth trying it, though it's odd since this setup has worked fine for a few years now.

Granted I'm just guessing - but I would think any software issues would also apply to em0 and em1 respectively.

You could up the verbosity of dhclient and log everything from it to try and find something.