- User Since
- May 1 2016, 5:02 PM (205 w, 1 d)
Sep 5 2019
I tried the change, on a system:
FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #662 r351837M/351846: Thu Sep 5 04:17:23 PDT 2019 firstname.lastname@example.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300045 1300045
Nov 9 2018
Thanks. This is not urgent -- I've been kinda sitting on it for years. And please consider this a proof of concept to illustrate the nature of the problem and a possible solution: I am not hung up on any part of the implementation.
Nov 4 2018
A real-world example: the "uname -a" strings from my home "build machine" as of this morning:
s1.0:FreeBSD freebeast.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #847 r340058M/340097: Sat Nov 3 04:02:51 PDT 2018 email@example.com:/common/S1/obj/usr/src/sys/GENERIC amd64
Oct 31 2018
Works for me as-is in 13.0-CURRENT @r339912M & 12.0-BETA2 @r339910M. 11.2-STABLE @r339881M needed the original .Dd line in the man page patch tweaked a bit to match expectations, but the text of that change and the code changes work as-is.
Oct 28 2018
I've updated the diff a bit in response to some suggestions -- thanks for those!
Oct 25 2018
Given the changes, this morning, I:
Oct 24 2018
I tested this, as my laptop had panicked after updating from r339583 to r339639. I first updated sources to r339681, then applied the patch (via 'svn patch'); did the normal update, rebooted, and the em0 NIC worked just fine -- certainly no panic.
Oct 22 2018
Sep 4 2018
Looks good to me, and the patch applied against head @r338438 cleanly.
Aug 31 2018
Overall, quite good: thank you. Above are mostly nits. I note, though that when I tried applying the patch to src/sbin/ipfw/ipfw.8 @338406, I got one rejection:
Aug 15 2018
OK; I tested on my laptop (while failed to boot using the Lua loader at r337834), and after applying the patch, issuing "make clean" in src/stand, and rebuilding/installing, the laptop booted OK. Prior to applying the patch, /boot/loader was 516096 bytes; the loader built after applying the patch is 421888 bytes.
I was remiss in failing to note that the change in question reduced the size of the loader from 516096 to 421888 bytes.
Tested on my "build machine" (BIOS & MBR); no observed difference in behavior (from before the patch), so "does no harm" as far as I can tell so far.
Aug 14 2018
I'll vote "no objection." (The issue doesn't really affect the bulk of my use,)
Aug 4 2018
The above change allowed a kernel to load on my laptop[[ https://wiki.freebsd.org/Laptops/Dell_Precision_M4800?highlight=(\bCategoryLaptop\b)| Dell Precision M4800 ]] after updating from r337232 -> r337285; without the change, the kernel was unloadable ("Can't load kernel") and I didn't even get a loader menu (e.g., to facilitate loading a different kernel).
Apr 1 2018
I like the idea -- particularly including the year. As for "logging in UTC," I found an approach that does fairly well (though it is a bit of a configuration hack): Just run the machines in UTC, but augment /etc/rc.conf (or similar) with (e.g.):
Jan 6 2018
I tested this earlier today: having built head/amd64 @r327616, first verified that output counters were rarely being updated, then I "cloned" that slice, used "svn patch" to apply the patch, rebuilt the kernel, and rebooted. (All of this worked without incident or drama.) Once rebooted, I used "scp" to copy a large file from the laptop to a machine on a different network here at home; I was pleased to note that the traffic counters on the laptop showed a very close correspondence with the counters on the router (where the NICs are em(4), and "just work").
Dec 12 2017
FWIW, I've had occasion to use man a few times on serial consoles (among other environments). IIRC, the main reason I switched the PAGER for myself was because (at the time), when more reached the end of the data, it would exit; that made searching backwards from the end rather challenging.
I've had 'PAGER=less' since before 2009/09/24 22:42:36 (earliest revision of ~/.cshrc I have) -- quite possibly since before my first experience with FreeBSD per se (which would have been 1998), as I used BSDi and SunOS before that.
Oct 24 2017
Apr 11 2017
At work, I built a version of our environment based on head/amd64 @314568, then built another after applying this set of patches. I have been running this pair of images on several (matched pairs) of our "appliances" since about 2017-04-10 03:00:00 UTC -- almost 36 hrs. as of this writing. So far, there's been no apparent difference in behavior for our workload (that I have been able to detect).
Dec 16 2016
I tried it (by unpacking the tarball referenced in the message to the ports list as security/openvpn-test, then running
portmaster -o security/openvpn-test openvpn-2.3.14
on my laptop running FreeBSD/amd64 stable/11@r310109.
Aug 30 2016
Aug 29 2016
May 1 2016
I was going to just upload the typescripts for the "ifconfig -v wlan0 list chan," but I don't see how to "To add files, drag and drop them into the comment text area." -- it makes no sense.
Applied (via "svn patch") on top of:
FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #405 r298876M/298876:1100106: Sun May 1 05:15:48 PDT 2016 firstname.lastname@example.org:/common/S4/obj/usr/src/sys/CANARY amd64