On 2/23/24 9:13 AM, Brooks Davis wrote:
Things are in a somewhat messy state. CASPER and CAPSICUM were moved to
a new __REQUIRED_OPTIONS list, but the various bits still exist and
there's even one use of MK_CASPER=no in Makefile.inc1. The commit
message (c24c117b9644) suggests that the intent
All,
The WITHOUT_CASPER build option was deprecated in main and 14-stable
branches but is still showing up and will trip up the build option survey:
sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER
WITHOUT_CASPER
--- all_subdir_sbin/mdconfig ---
===> sbin/mdconfig (all)
In exercising the build options on 14.0-BETA4, WITHOUT_CAPSICUM and
WITHOUT_CASPER appear to be in an ambiguous state: They are present but
ignored. Fortunately src.conf(5) now reports "This option has no effect."
Will these be removed prior to the final release? Are they staying to be
Hello all!
I confess that this issue exists on 13.1 and 13.2 in addition to the
14-CURRENT snapshot from last week but hopefully there is more to try.
This Pr covers the fundamental issue and I have been updating it a I try
suggestions:
The HPE P408i-a SR Gen10 3.00/smartpqi(4) on an HP DL325 EYPC system
worked well under 13.* and a SATA SSD but is providing odd behavior
under the 14-CURRENT 2022-11-23 RE snapshot.
The dmesg is blown with this incrementing error:
...
(probe0:smartpqi0:0:582:0): Down reving Protocol Version
On 7/21/22 8:31 AM, Chuck Tuffli wrote:
I have a virtual machine used to test the NVMe emulation in bhyve. All
of the tests in the VM pass running under FreeBSD 13.1-R, but the same
VM running under -current causes bhyve(8) to dump core because of a
segmentation fault.
git bisect identified the
Hello all,
I have re-run every option that failed under 13.0-ALPHA1 build under
12.2, on 13.0-ALPHA2 under 13.0-ALPHA2.
HUGE thanks to everyone who has helped resolve failing build options!
I have linked a list of annotated remaining failures plus an archive of
the full build here:
On 1/20/21 5:47 PM, Michael Dexter wrote:
Two have been fixed and PRs exist for the majority of them with some
possible fixes for those who know the code best to consider. One broken
option is a recent regression while one pair,
WITHOUT_LIBTHR/WITHOUT_LIBPTHREAD is quite stale
Hello all,
I have been experimenting with FreeBSD build options on and off since
FreeBSD 4.8/5.0 for use with minimum jails and later virtual machines.
If you have ever tried to build "without all" and working your way back
up, you have probably found this to be a very frustrating adventure
Mitchell,
On 12/7/20 1:56 PM, Mitchell Horne wrote:
You can also override it using the QEMU commandline, which is simpler
since you won't need to recompile anything. Adding the following
argument should suffice:
This works great but riscv 12-STABLE using last week's snapshot revision
throws
On 12/7/20 2:40 PM, Mitchell Horne wrote:
My bad, the extra '=' is a typo. It should be:
-append "vfs.root.mountfrom=ufs:/dev/vtbd0p3"
That worked perfectly and I added it to the wiki page:
https://wiki.freebsd.org/riscv
All the best,
Michael
On 12/7/20 1:56 PM, Mitchell Horne wrote:
As you suggest, it is possible to overwrite the default root device in
the kernel config, by adding a line such as:
options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\"
Thank you for the syntax!
You can also override it using the QEMU commandline, which is
All,
The FreeBSD wiki page on RISC-V reads:
If you get mountroot prompt, then indicate to the kernel the location of
rootfs:
mountroot> ufs:/dev/vtbd0
This indeed appears to be remain the case on CURRENT as of last week.
Specifying a device and partition, or disklabel at the mountroot>
On 7/17/20 4:37 AM, Cristian Cardoso wrote:
I would like to know if by chance in freeBSD there is some kind of log
when the command freebsd-update fetch / install is executed?
I looked in the documentation and found nothing about it.
There does not appear to be a log but running it with
On 3/24/18 2:35 AM, O. Hartmann wrote:
Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images,
created via
the classical manual way, no makefs), my recent CURRENT system dumps the
console full of these error messages:
g_handleattr: md0 bio_length 24 len 31 -> EFAULT
I do
On 1/5/14 1:04 PM, Nathan Whitehorn wrote:
On 12/01/13 07:34, Jilles Tjoelker wrote:
On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
This took much longer than I'd anticipated, but the patch to init is
attached. I chose not to make the changes to init rather than
getttyent()
On 11/11/13 1:01 PM, Teske, Devin wrote:
It doesn't touch the timeout code - should be whatever FreeBSD loader
forth scripts tell it to do.
Ah, must have been something Michael did. I noticed this whilst getting
demos from him on his laptop.
Please clarify. What specifically?
Michael
On 11/12/13 12:22 PM, dte...@freebsd.org wrote:
When the boot menu comes up, it counts down to from 5, 4, 3, ...
Instead of 9, 8, 7, ...
Sounds like autoboot_delay is modified... in the installed distro?
Did you script that or do it by hand? in loader.conf? in the VM?
Just curious.
Good
Hello all,
I have been experimenting with various BSD and GNU/Linux boot media
under bhyve and noticed that we may want to accommodate the LiveCD
mode of the installer, which in turn requires the correct console.
Currently, one is prompted for VT100 for installation but this does not
appear to
19 matches
Mail list logo
