Re: WITHOUT_CASPER ghost?
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 was to finish removal after 14 branched and it just hasn't happened yet. Understood. I do wonder if the tool would also benefit from learning about __REQUIRED_OPTIONS. By required do you mean WITHOUT_AUTO_OBJ, WITHOUT_UNIFIED_OBJDIR, WITHOUT_INSTALLLIB which I manually skip/mask my build option testing? If so, what syntax would use __REQUIRED_OPTIONS and what branches support it? Michael
WITHOUT_CASPER ghost?
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) make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: WITHOUT_CAPSICUM option ignored: it is no longer supported make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: WITHOUT_CASPER option ignored: it is no longer supported --- .depend --- echo mdconfig: /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libc.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libutil.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libgeom.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libbsdxml.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libsbuf.a >> depend --- mdconfig.o --- cc -target x86_64-unknown-freebsd14.0 --sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp -B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DNDEBUG -MD -MF.depend.mdconfig.o -MTmdconfig.o -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter /usr/lib/clang/16/include -Qunused-arguments -c /b/stable/14/src/sbin/mdconfig/mdconfig.c -o mdconfig.o --- all_subdir_sbin/md5 --- 4 warnings generated. --- md5 --- cc -target x86_64-unknown-freebsd14.0 --sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp -B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DHAVE_CAPSICUM -DWITH_CASPER -DNDEBUG -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter /usr/lib/clang/16/include -Qunused-arguments -Wl,-znorelro -static -o md5 md5.o -lmd -lcasper -lnv -lcap_fileargs -lnv ld: error: unable to find library -lcasper ld: error: unable to find library -lcap_fileargs cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [md5] Error code 1 make[4]: stopped in /b/stable/14/src/sbin/md5 1 error I am tracking the build options here: https://callfortesting.org/results/bos-ci/ My apologies if this is a false positive. Michael
WITHOUT_CAPSICUM|CASPER option ignored: it is no longer supported
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 reimplemented? Thank you! Michael
Boot failure on a ThinkPad T14/Ryzen 7 Pro 6850U
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: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707 In short, stock kernels, non-verbose stop at: ... psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 A verbose boot stops at: ... pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1 A kernel built with options ACPI_DEBUG with these boot parameters: set debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" set debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" Stops at: ... exregion-059 ExSystemMemorySpaceHan: System-Memory (width 8) R/W 0 Address=70F3 ... nsxfeval-0386 EvaluateObject : Null handle with relative pathname [_PRW] nsxfeval-0386 EvaluateObject... Related suggestion: Should 'options ACPI_DEBUG' be built into the snapshot kernels along with WITNESS etc? Any additional suggestions? Thank you! Michael
smartpqi0 "panic: Segment size is not aligned" Related panic on savecore?
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 from 6 to 2? (probe1:smartpqi0:0:583:0): Down reving Protocol Version from 6 to 2? (probe0:smartpqi0:0:584:0): Down reving Protocol Version from 6 to 2? ... (probe0:smartpqi0:0:1088:2): Down reving Protocol Version from 6 to 5? pass0 at smartpqi0 bus 0 scbus0 target 64 lun 0 pass0: Fixed Enclosure Services SPC-3 SCSI device (quiets down) dd'ing the 2022-11-23 Release Engineering VM raw snapshot to a device boots fine via USB and performs a growfs but booting to the HBA results in a panic when savecore it run, reporting: panic: Segment size is not aligned Workaround: Set savecore_enable="NO" in rc.conf before booting. Reproduction: service savecore onestart Cleanup: fsck / in single user mode and disable savecore as needed. Possibly related? Open (note savecore): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240145 Resolved with the same "Segment size is not aligned" panic: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259541 https://reviews.freebsd.org/D30182 Should I update that second PR? Have any suggestions for verifying the issue? All the best, Michael
Re: bhyve core dump related to llvm 14
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 last "good" commit on main as cb2ae6163174 sysvsem: Fix a typo After this commit, there are a half-dozen commits related to merging the llvm project release/14.x Chuck and I put our heads together to find a way to reproduce this issue and came up with this: Attache a 1gb disk image as emulation type "nvme" to a VM of any recent version, and run this command: nvmecontrol io-passthru -o 0x2 -l 4096 -4 0x20 -r nvme0ns1 This fails gracefully on 13.0R and 13.1R, but panics the bhyve process with a 14-CURRENT host after the LLVM 14 import. I have detailed reproduction steps and the debug output in this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265749 Michael
Re: FreeBSD 13.0 Build Option Sweep (13.0-ALPHA2 Update)
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: https://callfortesting.org/results/bos-FreeBSD-13A1/ Notably: WITHOUT_CRYPT WITHOUT_OPENSSL (Regression: Worked in May 2020) PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252841 WITHOUT_INSTALLLIB PR with a possible fix but it requires a decision by someone familiar with the repercussions: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252757 WITHOUT_TESTS_SUPPORT PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252843 I am happy to test patches! All the best, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 Build Option Sweep
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 and is a candidate for significant attention or possibly removal. Thank you Kyle for addressing the single greatest challenge I have described, with this review: https://reviews.freebsd.org/D28263 I have closed the PR. All the best, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 13.0 Build Option Sweep
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 in make-related failures after hours of compilation and, on the darkest days, concurrent deletion bugs which would give a different error every time you run a build. Fortunately, with the help of people like Ed Maste, Bryan Drewery, Bjoern Zeeb, Kyle Evans, and others, we have been gradually knocking broken build options off of the lists generated by the tools/tools/build_option_survey that PHK wrote long ago. An annotated list of working and failing build options in FreeBSD 13.0-ALPHA1 can be found here: https://callfortesting.org/results/bos-FreeBSD-13A1/ 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 and is a candidate for significant attention or possibly removal. If you are wondering, as of 13.0-ALPHA1, the following KERNCONF and generated /usr/src.conf are the minimum to build FreeBSD and build it in a bhyve VM from a UFS-formatted disk image: cpu HAMMER ident LESSBSD makeoptions MODULES_OVERRIDE="virtio" options SCHED_ULE device pci device loop device ether device uart device atpic device ahci device scbus options GEOM_PART_GPT options FFS sh /usr/src/tools/tools/build_option_survey/listallopts.sh \ | grep -v WITH_ | sed 's/$/=YES/' | \ grep -v WITHOUT_AUTO_OBJ | \ grep -v WITHOUT_UNIFIED_OBJDIR | \ grep -v WITHOUT_CRYPT | \ grep -v WITHOUT_DYNAMICROOT | \ grep -v WITHOUT_LIBCPLUSPLUS | \ grep -v WITHOUT_INSTALLLIB | \ grep -v WITHOUT_LIBTHR | \ grep -v WITHOUT_LIBPTHREAD | \ grep -v WITHOUT_BOOT | \ grep -v WITHOUT_LOADER_LUA | \ grep -v WITHOUT_LOCALES | \ grep -v WITHOUT_ZONEINFO | \ grep -v WITHOUT_VI \ > /etc/src.conf Explanation/Status: WITHOUT_AUTO_OBJ and WITHOUT_UNIFIED_OBJDIR belong in src-env.conf and kindly instantly warn you of this and terminate the build. WITHOUT_DYNAMICROOT and WITHOUT_LIBCPLUSPLUS are fixed in CURRENT. WITHOUT_INSTALLLIB and WITHOUT_LIBCPLUSPLUS should be easy to fix and candidate syntax is in the PRs linked in the above link. WITHOUT_CRYPT has regressed in recent months. WITHOUT_LIBTHR and WITHOUT_LIBPTHREAD are challenges. WITHOUT_BOOT onward are optional to build but are needed to boot the VM, see a console, set the time zone, and optionally edit files. The resulting kernel is 5M in size and the world and kernel are 90M. Basic networking adds another 1M. The build times on an EPYC 7402p are: buildworld 1m43.34s Warm ARC: 1m33.73s buildkernel 9.35s installworld 18.75s installkernel 0.32s Total: 3m23.44s Boot time: About three seconds I sincerely hope that all build options worked at some point and, given how much progress has been made, FreeBSD 13.0 can also support all options, or at a minimum, abort the build early as appropriate as the src-env.conf ones do. Think of the Developers! Spare them continued frustration with these. We can do this. I am happy to test any patches on multiple platforms. I am also happy to send individuals my minimum VM script and fortunately, it is out-of-date with every build option fix. All the best, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RISC-V root device question -> Panic
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 the panic output included below under QEMU and leaves nothing in /var/crash What expectations should I set for RISC-V STABLE and CURRENT? All the best, Michael t[0] == 0xffc0006c9d98 t[1] == 0x40c5 t[2] == 0x40c65000 t[3] == 0x0001 t[4] == 0x t[5] == 0x0001 t[6] == 0x0001 s[0] == 0xffd0b1600248 s[1] == 0x40e49000 s[2] == 0xf000 s[3] == 0x00ff s[4] == 0x4100 s[5] == 0x0001 s[6] == 0xffc000aff988 s[7] == 0x410a1000 s[8] == 0x0280 s[9] == 0x s[10] == 0x1000 s[11] == 0xff73 a[0] == 0x a[1] == 0xffd00297d560 a[2] == 0x a[3] == 0x0021 a[4] == 0x a[5] == 0x0021 a[6] == 0x003f a[7] == 0xffc000aff900 sepc == 0xffc0004ce414 sstatus == 0x0120 panic: Fatal page fault at 0xffc0004ce414: 0x65 cpuid = 1 time = 1607915275 KDB: stack backtrace: #0 0xffc00023f2d4 at kdb_backtrace+0x50 Uptime: 2d1h40m41s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RISC-V root device question
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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RISC-V root device question
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 simpler since you won't need to recompile anything. Adding the following argument should suffice: -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" Note that you can set arbitrary kernel environment variables this way ^^ My string: qemu-system-riscv64 -machine virt -m 2048M -smp 2 -nographic -kernel /vms/riscv/kernel -bios /usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" -drive file=$1,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev tap,ifname=tap0,script=no,id=net0 Reports: -append=vfs.root.mountfrom=ufs:/dev/vtbd0p3: invalid option I have tried it both there after ...elf and at the end of the string. Is this perhaps the wrong position? Finally, we do have support for loader.efi on RISC-V, although I have not yet documented how to use it on the wiki page. If you would like to try this method, please follow up with me and I can provide instructions. I am happy to if it is ready for public consumption. Otherwise, you can expect to see weekly RISC-V snapshots appear in the next week or two, and I will ensure that the wiki page is up to date with how to run them. Thank you and keep up the good work! Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RISC-V root device question
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> prompt works every time but none of these do not help in loader.conf (tested individually): cam.boot_delay="10" vfs.root.mountfrom="ufs:/dev/vtbd0p3" vfs.root.mountfrom="ufs:/dev/gpt/rootfs" rootdev="/dev/vtbd0p3" rootdev="vtbd0p3" currdev="vtbd0p3" Or these in the fstab: /dev/gpt/rootfs / ufs rw,noatime 1 1 /dev/vtbd0p3 / ufs rw,noatime 1 1 Are there any other options? Perhaps building the device name into the kernel? Thank you! Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd-update
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 '--debug' is very informative. Perhaps run a typescript for each run to capture this? All, is the debug output something that should be logged? Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT
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 not know what they are supposed to mean and I'd like to ask whether someone could shed some light on this. I am seeing this on the the latest snapshot when attempting to run option_survey.sh which creates an md-attached disk image. Anyone else seeing this? Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] bsdinstall and zfsboot enhancements
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() and friends in libc, which I am open to revisiting. >> lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and >> will not allow root login on a "fake" TTY that getttynam() does not >> know. This module is enabled by default for the "login" service. >> >> So it is probably better to patch libc rather than init. > > OK, here's a revised patch. This one is shorter and works by introducing > an "auto" flag (ideas for names appreciated) that means "on" if the line > is an active console and "off" otherwise. Note that the behavior is now: > - ttys marked "off" stay off > - ttys marked "on" stay on > - ttys marked "auto" are enabled iff they are console devices > - ttys not present in /etc/ttys stay off > > This behavior change is much easier to implement when doing it in libc > for various structural reasons and allows the terminal type, etc. to be > specified in the usual way. > >>> The behavior changes are as follows: >>> If the "console" device in /etc/ttys in marked "on", instead of opening >>> /dev/console, init will loop through the active kernel console devices, >>> and for each will: >>> 1. If the kernel console device is in /etc/ttys and marked "on", it >>> already has a terminal and will be ignored. >>> 2. If marked "off", that is an explicit statement that a console is not >>> wanted and so it will be ignored. >>> 3. If not present in /etc/ttys, init will run getty with whatever >>> parameters "console" has. >> This seems to make sense. >> >>> (3) is the main behavioral change. No changes in behavior will occur if >>> /etc/ttys is not modified. If we turn on "console" by default, it will >>> usually have no effect instead of trying to run multiple gettys, which >>> is new. If we then also comment out the ttyu0 line, instead of marking >>> it "off", the result will be the conditional presence of a login prompt >>> on the first serial port depending on whether it is an active console >>> device for the kernel. I believe this is the behavior we are going for. >> The terminal type for the console entry should probably be changed to >> something other than "unknown" to reduce annoyance. >> >>> Comments and test results would be appreciated. >> As a preparatory patch, you could remove se_index and session_index from >> init. They are only used to warn about a changed slot number in utmp(5) >> which is irrelevant with utmpx. This noise warning would also appear >> in most cases when changing from a "fake" console entry to a real line >> in /etc/ttys. Also, if you do decide to fake ttys entries in init rather >> than libc, the patch to init will be simpler. >> > > With the new patch, this is indeed the case: no changes to init are > necessary at all. This does not change any behavior unless explicitly > requested in /etc/ttys, so unless there are any objections in the next > couple days, I will commit it. > -Nathan Hello all, Not sure if everyone knows that Nathan posted a patched 11-current ISO: http://people.freebsd.org/~nwhitehorn/auto-console.iso I have fetched and booted to this with my "iso" mode in my scripts and IT WORKS. Install from ISO and boot as normal. Only glitch which I haven't seen for some time: The resulting guest console is shortened by one line with this persistent string at the bottom: /boot/kernel/kernel text=0xf45a98 data= syms= ... This persists after VM reboot, goes away with bhyveload and returns for the next VM boot. Okay, a second glitch upon second boot. The root prompt reads: login: Jan 6 console getty[792]: open /dev/ttyv2: No such file or directory This passes with ENTER and I can log in a normal, with the same string pinned to the bottom. Getting there! Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] bsdinstall and zfsboot enhancements
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 eye! My scripts have been throwing in autoboot_delay="5" to short the time between load an potential kernel panic. No fun when the countdown was the longest part for the whole process. :) Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] bsdinstall and zfsboot enhancements
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] bsdinstall and zfsboot enhancements
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 work/stick for LiveCD mode. Can anyone verify this? Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
