[Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 Jan Beich changed: What|Removed |Added CC|curr...@freebsd.org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 --- Comment #7 from Lê Quốc Đạt --- Comment on attachment 148901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148901 0001-HBSD-allow-to-specify-custom-keymap-to-kbdmux.patch 148901 --- Comment #8 from Lê Quốc Đạt --- Comment on attachment 148901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148901 0001-HBSD-allow-to-specify-custom-keymap-to-kbdmux.patch 148901 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 --- Comment #7 from Lê Quốc Đạt --- Comment on attachment 148901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148901 0001-HBSD-allow-to-specify-custom-keymap-to-kbdmux.patch 148901 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 Lê Quốc Đạt changed: What|Removed |Added CC||datloveyouvt1...@gmail.com --- Comment #6 from Lê Quốc Đạt --- Comment on attachment 148901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148901 0001-HBSD-allow-to-specify-custom-keymap-to-kbdmux.patch 148901 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #3 from Zhenlei Huang ---
It seems we do not have usage that bind a thread to local CPU, otherwise
`KASSERT(THREAD_CAN_MIGRATE(td), ("%p must be migratable", td))` will complain
(when kernel built with option INVARIANTS).
(In reply to Ed Maste from comment #1)
> but, what about just moving the KASSERT after the `if (PCPU_GET(cpuid) ==
> cpu)` test?
I think that is much simpler.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921 Mark Linimon changed: What|Removed |Added Flags|mfc-stable12?, | |mfc-stable11? | --- Comment #2 from Mark Linimon --- ^Triage: remove OBE flags. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 --- Comment #5 from Yuri Victorovich --- (In reply to Mark Millard from comment #4) > Being in a VirtualBox VM the /dev/ada0p2 may not indicate > much about the actual media involved. The physical medium is a traditional spinning HD with the UFS file system. The host OS is FreeBSD 13.2 amd64. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 --- Comment #4 from Mark Millard --- (In reply to Yuri Victorovich from comment #2) Being in a VirtualBox VM the /dev/ada0p2 may not indicate much about the actual media involved. Microsd card and spinning rust media are more likely than some other types of media to end up with larger than desirable delays. The environment running the VM (outside the VM) could be relevant as well. I was mostly after if the media was more vs. less likely to contribute to such a problem when the swap space is under heavy use. Other relevant things to know would include the actual RAM available to the FreeBSD instance, the number of hardware threads actually present for FreeBSD to run on, and probably more that I'm not managing to think of at the moment. Another would be if the system that was running the VM was also busy with other activities vs. being basically dedicated to running the one VM instance that was running the FreeBSD instance. But . . . It may be that, unless you end up showing repeatability, trying to make notes for such a range of issues is not worth the time and effort. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 --- Comment #3 from Yuri Victorovich --- (In reply to Mark Millard from comment #1) > Do you have anything specific for what controls getting [...]. This is a generic install. No specific options of any kind were set. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 --- Comment #2 from Yuri Victorovich --- (In reply to Mark Millard from comment #1) Swap is on /dev/ada0p2. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536
Mark Millard changed:
What|Removed |Added
CC||marklmi26-f...@yahoo.com
--- Comment #1 from Mark Millard ---
The actual message is from sys/vm/vm_pageout.c (looking in modern source):
case VM_OOM_MEM_PF:
reason = "a thread waited too long to allocate a page";
break;
("waited" instead of "waiting").
Do you have anything specific for what controls getting
VM_OOM_MEM_PF:
# sysctl -d vm.pfault_oom_wait vm.pfault_oom_attempts
vm.pfault_oom_wait: Number of seconds to wait for free pages before retrying
the page fault handler
vm.pfault_oom_attempts: Number of page allocation attempts in page fault
handler before it triggers OOM handling
The defaults are:
# sysctl vm.pfault_oom_wait vm.pfault_oom_attempts
vm.pfault_oom_wait: 10
vm.pfault_oom_attempts: 3
What sort of storage media was the swap space on? Spinning Rust?
Sometimes VM environments have accuracy problems with various forms
of time handling. So that might be another direction involved for
this issue.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 Yuri Victorovich changed: What|Removed |Added URL||https://people.freebsd.org/ ||~yuri/screenshot-clang-kill ||ed-on-FreeBSD-14.png Assignee|b...@freebsd.org|curr...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 254698] RC4 from RC3 shutdown/reboot regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 Andrey Fesenko changed: What|Removed |Added Status|New |Closed Resolution|--- |Not A Bug --- Comment #4 from Andrey Fesenko --- Sorry, broken CentOS host Package edk2.git-ovmf-x64, search old version, work fine -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254698] RC4 from RC3 shutdown/reboot regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 --- Comment #3 from Mark Millard --- (In reply to Andrey Fesenko from comment #2) I was only commenting on the reference to "installer panic", not on other aspects of the overall behavior. No panic is shown in the picture, just a debug-kernel report of a lock order reversal. (Those need not be a problem.) As for the overall behavior . . . You referenced "installer panic after final reboot". And the picture says "Rebooting..." so I would expect the process to not stop but to start booting after the shutdown: It does not look like a power down and your wording says it was a reboot. If a power down was actually requested instead of a "final reboot", you may want to add some notes to clarify how to interpret the report's intent. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254698] RC4 from RC3 shutdown/reboot regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 --- Comment #2 from Andrey Fesenko --- (In reply to Mark Millard from comment #1) PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 127494 root 20 0 2557332 1.0g 18732 S 100.0 53.8 1:25.97 qemu-kvm but process not ended, vnc console live PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 127494 root 20 0 2532744 1.0g 18732 S 100.3 53.8 2:50.26 qemu-kvm -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254698] RC4 from RC3 shutdown/reboot regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #1 from Mark Millard --- (In reply to Andrey Fesenko from comment #0) The isofs vs. devfs lock order reversal notice may well be one of the known-not-problematical ones that are reported by the debug kernel but are not handled as panics. Looks to me like the reboot was probably a normal, good one. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254698] RC4 from RC3 shutdown/reboot regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 Bug ID: 254698 Summary: RC4 from RC3 shutdown/reboot regression Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: and...@bsdnir.info CC: curr...@freebsd.org Hello my build box kvm-efi (centos edk2.git-ovmf-x64 0-20201222.1581.g98ff7e3c63) buider start endless freeze reboot and shutdown -p now (set hw.efi.poweroff=0 not fix) virtualbox windows host, reboot work fine shutdown -p require set hw.efi.poweroff=0 FreeBSD new uefi-edk2-bhyve g20210214,2 work fine, uefi-edk2-bhyve-0.2_1,1 shutdown -p require set hw.efi.poweroff=0 (not regression RC3) mail list https://lists.freebsd.org/pipermail/freebsd-current/2021-April/079339.html installer panic after final reboot kvm-efi FreeBSD-14.0-CURRENT-amd64-20210401-4084b1ab041-245766-disc1.iso https://64.media.tumblr.com/668d44ed911d93bc33dd300bc8388a13/e90c47870f5a6d6c-cb/s1280x1920/fef0fb97b77cd08faf1e0e534552c1c43ec54c87.png -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Nathan Whitehorn changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #15 from commit-h...@freebsd.org --- A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3ef46634cd5a6ba0e156d5da095bbee5f63ec1cd commit 3ef46634cd5a6ba0e156d5da095bbee5f63ec1cd Author: Nathan Whitehorn AuthorDate: 2021-03-23 13:19:42 + Commit: Nathan Whitehorn CommitDate: 2021-03-23 19:22:20 + Fix scripted installs on EFI systems after default mounting of the ESP. Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to extract a directory at that point post-mount when the system is installed. Normally, this is fine, since tar can happily set whatever properties it wants. For FAT32 file systems, however, like the ESP, tar will attempt to set mtime on the root directory, which FAT does not support, and tar will interpret this as a fatal error, breaking the install (see https://github.com/libarchive/libarchive/issues/1516). This issue would also break scripted installs on bare-metal POWER8, POWER9, and PS3 systems, as well as some ARM systems. This patch solves the problem in two ways: - If stdout is a TTY, use the distextract stage instead of tar, as in interactive installs. distextract solves this problem internally and provides a nicer UI to boot, but requires a TTY. - If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude boot/efi from tarball extraction and then add it by hand. This is a hack, and better solutions (as in the libarchive ticket above) will obsolete it, but it solves the most common case, leaving only unattended TTY-less installs on a few tier-2 platforms broken. In addition, fix a bug with fstab generation uncovered once the tar issue is fixed that umount(8) can depend on the ordering of lines in fstab in a way that mount(8) does not. The partition editor now writes out fstab in mount order, making sure umount (run at the end of scripted, but not interactive, installs) succeeds. PR: 254395 Approved by:re (gjb) Reviewed by:gjb, imp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D29380 (cherry picked from commit c2f16c595eb51c6e0cb6ece3f6f078d738019059) (cherry picked from commit 4601382e1362352f17a33e4ed38db5dcfe3f6be5) usr.sbin/bsdinstall/partedit/partedit.c | 39 + usr.sbin/bsdinstall/scripts/script | 30 ++--- 2 files changed, 61 insertions(+), 8 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #14 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4601382e1362352f17a33e4ed38db5dcfe3f6be5 commit 4601382e1362352f17a33e4ed38db5dcfe3f6be5 Author: Nathan Whitehorn AuthorDate: 2021-03-23 13:19:42 + Commit: Nathan Whitehorn CommitDate: 2021-03-23 19:21:33 + Fix scripted installs on EFI systems after default mounting of the ESP. Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to extract a directory at that point post-mount when the system is installed. Normally, this is fine, since tar can happily set whatever properties it wants. For FAT32 file systems, however, like the ESP, tar will attempt to set mtime on the root directory, which FAT does not support, and tar will interpret this as a fatal error, breaking the install (see https://github.com/libarchive/libarchive/issues/1516). This issue would also break scripted installs on bare-metal POWER8, POWER9, and PS3 systems, as well as some ARM systems. This patch solves the problem in two ways: - If stdout is a TTY, use the distextract stage instead of tar, as in interactive installs. distextract solves this problem internally and provides a nicer UI to boot, but requires a TTY. - If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude boot/efi from tarball extraction and then add it by hand. This is a hack, and better solutions (as in the libarchive ticket above) will obsolete it, but it solves the most common case, leaving only unattended TTY-less installs on a few tier-2 platforms broken. In addition, fix a bug with fstab generation uncovered once the tar issue is fixed that umount(8) can depend on the ordering of lines in fstab in a way that mount(8) does not. The partition editor now writes out fstab in mount order, making sure umount (run at the end of scripted, but not interactive, installs) succeeds. PR: 254395 Approved by:re (gjb) Reviewed by:gjb, imp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D29380 (cherry picked from commit c2f16c595eb51c6e0cb6ece3f6f078d738019059) usr.sbin/bsdinstall/partedit/partedit.c | 39 + usr.sbin/bsdinstall/scripts/script | 30 ++--- 2 files changed, 61 insertions(+), 8 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #13 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c2f16c595eb51c6e0cb6ece3f6f078d738019059 commit c2f16c595eb51c6e0cb6ece3f6f078d738019059 Author: Nathan Whitehorn AuthorDate: 2021-03-23 13:19:42 + Commit: Nathan Whitehorn CommitDate: 2021-03-23 13:29:54 + Fix scripted installs on EFI systems after default mounting of the ESP. Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to extract a directory at that point post-mount when the system is installed. Normally, this is fine, since tar can happily set whatever properties it wants. For FAT32 file systems, however, like the ESP, tar will attempt to set mtime on the root directory, which FAT does not support, and tar will interpret this as a fatal error, breaking the install (see https://github.com/libarchive/libarchive/issues/1516). This issue would also break scripted installs on bare-metal POWER8, POWER9, and PS3 systems, as well as some ARM systems. This patch solves the problem in two ways: - If stdout is a TTY, use the distextract stage instead of tar, as in interactive installs. distextract solves this problem internally and provides a nicer UI to boot, but requires a TTY. - If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude boot/efi from tarball extraction and then add it by hand. This is a hack, and better solutions (as in the libarchive ticket above) will obsolete it, but it solves the most common case, leaving only unattended TTY-less installs on a few tier-2 platforms broken. In addition, fix a bug with fstab generation uncovered once the tar issue is fixed that umount(8) can depend on the ordering of lines in fstab in a way that mount(8) does not. The partition editor now writes out fstab in mount order, making sure umount (run at the end of scripted, but not interactive, installs) succeeds. PR: 254395 Reviewed by:gjb, imp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D29380 usr.sbin/bsdinstall/partedit/partedit.c | 39 + usr.sbin/bsdinstall/scripts/script | 30 ++--- 2 files changed, 61 insertions(+), 8 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #12 from Nathan Whitehorn --- Related things: https://reviews.freebsd.org/D29380 <- patch in review here https://github.com/libarchive/libarchive/issues/1516 <- libarchive issue here -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #11 from Nathan Whitehorn --- (In reply to Warner Losh from comment #10) It's pretty tricky, since it touches code in a lot of places, has to be conditional on platform, and runs a risk of breaking interactive installs just because it is pretty invasive. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #10 from Warner Losh --- (In reply to Ryan Moeller from comment #8) Oh! I like this idea better, I think, but I don't know how hard it is to do. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #9 from Nathan Whitehorn --- (In reply to Ryan Moeller from comment #8) We could delay it, but it's harder and less-localized than the other solutions. It also completely breaks PowerPC and other systems with analagous but non-ESP boot partions. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #8 from Ryan Moeller --- Would it be possible to defer mounting the ESP until after the tarballs have been extracted? We don't actually have anything in /boot/efi in the base archive. My understanding is that it's just there to ensure the mountpoint exists. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #7 from Warner Losh --- #4 sounds good for 13.0. Of the hacks, it's the most localized and least hacky, imho. I'd prefer #5, honestly, longer term but I've not thought through all the implictions. We should loop in cem@ since he's been touching that code most recently. Or delphij@ as he has too... -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Nathan Whitehorn changed: What|Removed |Added Severity|Affects Only Me |Affects Some People CC||i...@freebsd.org Priority|--- |Normal --- Comment #6 from Nathan Whitehorn --- Thanks for the suggestion about the documentation -- I've updated the man page. The core problem here is that our tar can't extract archives to FAT32 with default options, since it treats inability to set modification time as a fatal error and FAT32 doesn't let you do that on the root directory. As such, any file in the release tarballs can't be extracted to FAT32. For interactive installations, the bsdinstall distextract tool, a CURSES-y frontend to libarchive, solves this by ignoring ctime/mtime errors. Some extra commentary on solutions, so it can be in one place. Possibilities are: 1. We drop /boot/efi from mtree. That will result in it not existing in base.txz, solving this issue, but will result in it not being in mtree. It will also leave in place an identical bug that will break scripted installation on bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform. 2. We add an option to tar to ignore failure in setting ctime/mtime, like the interactive installer uses. This has the difficulty that the patch is hacky and would have to go through upstream. 3. We go back to using distextract for scripted installations as well as interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7. This fixes this issue but will result in installation failures for scripted installs without a controlling tty. (It will also add nice progress bars to scripted installs). 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand afterward. This is incredibly hacky and otherwise essentially functionally equivalent to #1. Like #1, it will fix this issue and has no obvious functional downside, but leaves scripted installs bare-metal POWER8 and POWER9 broken. 5. We patch the file system driver to (pretend to) allow setting times on the mount point. I don't want to do this, since I don't want to solve this in the kernel at RC3 and I don't like it pretending to do things it can't do. Of these, 1, 3, and 4 are quite easy to implement, but all have some downside. My temptation is to do 4 for 13.0, since it will definitely work but is just lame, then either do #2 or a variant on #3 where distextract notices there is no tty and doesn't try to set up a dialog as a longer-term fix in HEAD. Any thoughts? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Andrey Fesenko changed: What|Removed |Added Blocks||231027 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 [Bug 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #5 from Andrey Fesenko --- (In reply to Nathan Whitehorn from comment #3) If possible, it is also worth mentioning in the release notes that you no longer need to specify the efi and boot partitions, but is it possible to make the efi partition smaller, since 260M is a lot for a virtual machine, where there will be only 1 system -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
--- Comment #4 from Andrey Fesenko ---
(In reply to Nathan Whitehorn from comment #1)
Installer fail, if set PARTITIONS="$DISKSLICE GPT { auto freebsd-ufs / }" fail
too
https://64.media.tumblr.com/2c95d2ddeed5cc2bd7ffb8fc68f34436/f8abb8c6d81ea645-e4/s1280x1920/6c4753c8bfdd3af75f597371189c4dcb1cbf0880.png
build packer
"qemu_binary": "/usr/libexec/qemu-kvm",
"-bios",
"/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd"
Check virtualbox builder BETA4 installer ok. RC2 fail, similar error
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #3 from Nathan Whitehorn --- Well, I found the issue and there's even a nice comment in the relevant code that an older, smarter version of me put in in 2018 describing exactly why this is going to break: # Unpack distributions bsdinstall checksum for set in $DISTRIBUTIONS; do f_dprintf "Extracting $BSDINSTALL_DISTDIR/$set" # XXX: this will fail if any mountpoints are FAT, due to inability to # set ctime/mtime on the root of FAT partitions. tar has no option to # ignore this. We probably need to switch back to distextract here # to properly support EFI. tar -xf "$BSDINSTALL_DISTDIR/$set" -C $BSDINSTALL_CHROOT done I'll try to get a patch in today. Apologies for the breakage, and thanks for the report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Ryan Moeller changed: What|Removed |Added CC||freql...@freebsd.org --- Comment #2 from Ryan Moeller --- This affects me as well. The install completely fails. I'm even doing EFI installs: PARTITIONS="zvol/pool/dataset/vol gpt" I've used this same script quite a lot and it has only started to fail recently. I noticed yesterday and started looking into it a bit before I got pulled into something else. The tarball that fails to be extracted is base.txz (it's the one that contains ./boot/efi). The output on the console shows this as well: DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[] DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[14.0-CURRENT] DEBUG: common.subr: Successfully loaded. DEBUG: f_debug_init: ARGV=[mount] GETOPTS_STDARGS=[dD:] DEBUG: f_debug_init: debug=[1] debugFile=[] DEBUG: Running installation step: mount DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[] DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[14.0-CURRENT] DEBUG: common.subr: Successfully loaded. DEBUG: f_debug_init: ARGV=[checksum] GETOPTS_STDARGS=[dD:] DEBUG: f_debug_init: debug=[1] debugFile=[] DEBUG: Running installation step: checksum DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/kernel.txz DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/kernel-dbg.txz DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/base.txz ERROR: bsdinstall script failed At this point the script exits, leaving the filesystems mounted even: /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 on /mnt (ufs, local, journaled soft-updates) /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 on /mnt/boot/efi (msdosfs, local) devfs on /mnt/dev (devfs) # cat /tmp/bsdinstall-tmp-fstab /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 /mnt/boot/efi msdosfs rw 2 2 /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 /mntufs rw 1 1 # cat /tmp/bsdinstall_etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 /boot/efi msdosfs rw 2 2 /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 / ufs rw 1 1 /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep3 none swapsw 0 0 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Nathan Whitehorn changed: What|Removed |Added CC||nwhiteh...@freebsd.org --- Comment #1 from Nathan Whitehorn --- You should not include the EFI partition in the PARTITIONS variable in general, but that won't cause this issue. Does the installer actually fail, resulting in a non-bootable system? Or do you just see this message in the output? Any more detail about your install script? What are you untarring? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 254395] bsdinstall: fail script install after BETA3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
Bug ID: 254395
Summary: bsdinstall: fail script install after BETA3
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
Status: New
Keywords: regression
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: and...@bsdnir.info
CC: curr...@freebsd.org
After BETA3 or RC1 (CURRENT add efi partition /boot/efi mount) script install
UEFI system fail checksum/extract base.txz
Old working `PARTITIONS="$DISKSLICE GPT { 260M efi , auto freebsd-ufs / }"`
if edit `PARTITIONS="$DISKSLICE GPT { 260M efi /boot/efi, auto freebsd-ufs /
}"` not fix
root /mnt and efi /mnt/boot/efi mount succesfull
bsdinstall_log
* DEBUG: f_variable_set_defaults: Initializing defaults...
* DEBUG: f_getvar: var=[debug] value=[1] r=0
* DEBUG: f_getvar: var=[editor] value=[/usr/bin/ee] r=0
* DEBUG: f_getvar: var=[ftpState] value=[auto] r=0
* DEBUG: f_getvar: var=[ftpUser] value=[ftp] r=0
* DEBUG: f_getvar: var=[hostname] value=[] r=0
* DEBUG: f_getvar: var=[MEDIA_TIMEOUT] value=[300] r=0
* DEBUG: f_getvar: var=[nfs_reserved_port_only] value=[NO] r=0
* DEBUG: f_getvar: var=[nfs_use_tcp] value=[NO] r=0
* DEBUG: f_getvar: var=[nfs_use_v3] value=[YES] r=0
* DEBUG: f_getvar: var=[PKG_TMPDIR] value=[/var/tmp] r=0
* DEBUG: f_getvar: var=[releaseName] value=[13.0-RC2] r=0
* DEBUG: f_variable_set_defaults: Defaults initialized.
* DEBUG: variable.subr: Successfully loaded.
* DEBUG: f_include_lang: file=[/usr/libexec/bsdconfig/include/messages.subr]
lang=[]
* DEBUG: dialog.subr: DIALOG_SELF_INITIALIZE=[1]
* DEBUG: f_dialog_init: ARGV=[/tmp/installerconfig] GETOPTS_STDARGS=[dD:SX]
* DEBUG: f_dialog_init: SECURE=[] USE_XDIALOG=[]
* DEBUG: f_dialog_init: dialog(1) API initialized.
* DEBUG: dialog.subr: Successfully loaded.
* DEBUG: f_include: file=[/usr/share/bsdconfig/variable.subr]
* DEBUG: Began Installation at Fri Mar 19 02:37:31 UTC 2021
* ./boot/efi/: Can't restore time
* tar: Error exit delayed from previous errors.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921 Kubilay Kocak changed: What|Removed |Added Keywords|patch |needs-patch Summary|[patch] [sched] Allow |scheduler: Allow |non-migratable threads to |non-migratable threads to |bind to their current CPU. |bind to their current CPU Status|New |Open Flags||mfc-stable11?, ||mfc-stable12? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 197921] [patch] [sched] Allow non-migratable threads to bind to their current CPU.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #1 from Ed Maste ---
+ }
+ else {
should be:
} else {
but, what about just moving the KASSERT after the `if (PCPU_GET(cpuid) == cpu)`
test?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #24 from Kubilay Kocak --- (In reply to Slava from comment #22) Alternatively, one can apply the commit that was merged to stable/12 in base r342278, and rebuild/reinstall the kernel -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #23 from Kubilay Kocak --- (In reply to Slava from comment #22) The fix has been committed and merged to the stable/12 branch, and will be part of the next (12.1) FreeBSD release cut from that branch. If you would not like to wait for that release, you may update to the stable/12 branch. For more information on tracking development branches, see: https://www.freebsd.org/doc/handbook/current-stable.html -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Slava changed: What|Removed |Added CC||sl...@planetslav.ca --- Comment #22 from Slava --- Hello, I'm having the same issue on Lenovo X1 Carbon gen1, Coreboot 4.7 TianoCore on Freebsd 12.0-RELEASE-p3. It was working since Freebsd 11.1 when I just set this up over a year ago and in 11.2. Stopped working after update to 12. [moose@beast /usr/home/moose]$ acpiconf -i 0 acpiconf: get battery info (0) failed: Device not configured [moose@beast /usr/home/moose]$ dmesg | grep -i acpi | grep -i bat ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) [moose@beast /usr/home/moose]$ uname -a FreeBSD beast 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64 Please let me know if you need any additional information and/or if I need to apply any patches manually. Thank you -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208275] Kernel panic when reading from /dev/cd0 with a damaged dvd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275 Oleksandr Tymoshenko changed: What|Removed |Added CC||go...@freebsd.org Status|New |Closed Resolution|--- |FIXED --- Comment #13 from Oleksandr Tymoshenko --- There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved. Thanks -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable12? |mfc-stable12+ Keywords|needs-qa| -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:
Author: avg
Date: Thu Dec 20 08:45:41 UTC 2018
New revision: 342278
URL: https://svnweb.freebsd.org/changeset/base/342278
Log:
MFC r341632: acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.
PR: 227191
Changes:
_U stable/12/
stable/12/sys/dev/acpica/acpi.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Assignee|a...@freebsd.org|a...@freebsd.org Status|Open|In Progress -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
--- Comment #20 from commit-h...@freebsd.org ---
A commit references this bug:
Author: avg
Date: Thu Dec 6 12:34:34 UTC 2018
New revision: 341632
URL: https://svnweb.freebsd.org/changeset/base/341632
Log:
acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.
Before r330957 we ignored any _STA evaluation failure (which was
performed by AcpiGetObjectInfo in ACPICA contrib code) for the purpose
of acpi_DeviceIsPresent and acpi_BatteryIsPresent. ACPICA 20180313
removed evaluation of _STA from AcpiGetObjectInfo. So, we added
evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent.
One important difference is that the new code ignored a failure only if
_STA did not exist (AE_NOT_FOUND). Any other kind of failure was
treated as a fatal failure. Apparently, on some systems we can get
AE_NOT_EXIST when evaluating _STA. And that error is not an evil twin
of AE_NOT_FOUND, despite a very similar name, but a distinct error
related to a missing handler for an ACPI operation region.
It's possible that for some people the problem was already fixed by
changes in ACPICA and/or in acpi_ec driver (or even in BIOS) that fixed
the AE_NOT_EXIST failure related to EC operation region.
This work is based on a great analysis by cem and an earlier patch by
Ali Abdallah .
PR: 227191
Reported by: 0mp
MFC after:2 weeks
Changes:
head/sys/dev/acpica/acpi.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #19 from Andriy Gapon --- I am curious if anyone who had this problem before still has it. Especially, I am curious if they had an error message like in comment#1 and if that message went way. In addition to the prior analysis I'd like to add the following summary. - before base r330957 we ignored any _STA evaluation failure (which was performed in ACPICA contrib code) for the purpose of acpi_DeviceIsPresent and acpi_BatteryIsPresent - ACPICA 20180313 stopped evaluating _STA altogether - so, we added evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent - one important difference is that now we ignore a failure only if _STA does not exist (AE_NOT_FOUND) - any other kind of failure is treated as a failure - apparently, on some systems we can get AE_NOT_EXIST when evaluating _STA - that error is not an evil twin of AE_NOT_FOUND, despite a very similar name, but a distinct error related to a missing handler for embedded controller (EC) address space - it's possible that for some people the problem was fixed by some changes in ACPICA and/or acpi_ec that fixed the AE_NOT_EXIST failure Still, I would like to re-iterate my proposal that we restore full pre-r330957 behaviour by ignoring any _STA error. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #18 from Matías Pizarro --- I was still having this problem on 13-CURRENT r340703 ( https://svnweb.freebsd.org/base?view=revision&revision=340703 ). But that was nearly 6 days ago, I have not tested further down the 13-CURRENT development branch and, as you said, there's been quite a few ACPI-related commits since then -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #17 from Mark Johnston --- (In reply to Matías Pizarro from comment #16) There have been several ACPICA updates since the bug was filed, but 13-CURRENT and 12.0 should be in sync. Which revision of 13-CURRENT did you test? Can anyone confirm that this is still an issue, either on -CURRENT on 12? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #16 from Matías Pizarro --- Hi all, FYI, I had the same issue with 13-CURRENT but it now works fine in today';s stable/12 | 12-PRERELEASE which I understand should be the same as 12-RC2. Thanks for your work on this, All the best, -- matías -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2333 ||14 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kubilay Kocak changed: What|Removed |Added Component|kern|bin Flags|mfc-stable11? |mfc-stable11+ --- Comment #5 from Kubilay Kocak --- Thanks! For bonus linking points: base r335642 (current: 12.0) base r335863 (mfc: stable/11) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 --- Comment #4 from Kyle Evans --- (In reply to Kubilay Kocak from comment #3) Hi, Sorry, I should have been informative. =) The commit for this that rewrote the offending parser predated stable/12, r335642; it was merged to stable/11 in r335863, so all supported branches have the fix. Thanks, Kyle Evans -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable10- | --- Comment #3 from Kubilay Kocak --- Hi Kyle, what were the revision(s) for the merge(s), and did this go/need to go to stable/12? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kyle Evans changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Kubilay Kocak changed: What|Removed |Added Summary|Cannot check battery status |Cannot check battery status |after upgrading to |after upgrading to |12-CURRENT after r330957|12-CURRENT after r330957 |(ACPI problems) |(ACPI _STA method removed) CC||curr...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Nicolas Hainaux changed: What|Removed |Added CC||nh.te...@gmail.com --- Comment #32 from Nicolas Hainaux --- I plainly agree with James T. Koerting that, for the reasons he clearly stated, this should not be kept as an open bug. As an ezjail user, I'd rather suggest to keep the per-jail configuration via jail_* variables until there is a reliable solution to drop it. Even until 13.0 or 14.0 if this is necessary. I do not want to replace ezjail by unreliable or "fat" tools and hope the authors of jail(8) will find a solution and/or take the config file management functionality proposed by erdgeist into consideration. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kyle Evans changed: What|Removed |Added Assignee|b...@freebsd.org|kev...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kyle Evans changed: What|Removed |Added Flags||mfc-stable10-, ||mfc-stable11? Status|New |In Progress CC||kev...@freebsd.org --- Comment #2 from Kyle Evans --- Hi, Sorry for the radio silence on this. I committed a new version of the env line sanitizer (written by ian@) in r335642 which also fixed this, and later revisions to config(8) fixed this same kind of bug in hints. I'll be MFC'ing the rewrite and all of my other env work (deduplication, fixing the order of precedence) likely this weekend. Thanks, Kyle Evans -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259 Conrad Meyer changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |c...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259 --- Comment #3 from rozhuk...@gmail.com --- Why close() does not wakes thread that sleep on accept()? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259 --- Comment #2 from rozhuk...@gmail.com --- I do not understand why shutdown() does not generates POLLHUP/EV_EOF (EV_ERROR then add shutdowned socket) for poll() and kqueue(). -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227259] accept() does not wakeup on shutdown()/close()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259 rozhuk...@gmail.com changed: What|Removed |Added CC||freebsd-current@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259 rozhuk...@gmail.com changed: What|Removed |Added Summary|accept() does not wakeup on |accept()/poll() and |shutdown()/close() |shutdown()/close() - not ||work as in FreeBSD10, may ||broke many apps -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 --- Comment #6 from Charlie Li --- Also could someone remove current@ again? I accidentally used a cached page to comment and didn't pay attention to the CC list. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 w.schwarzenf...@utanet.at changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |w.schwarzenf...@utanet.at -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC||freebsd-current@FreeBSD.org --- Comment #5 from Charlie Li --- In that case I do have WITH_ZONEINFO_LEAPSECONDS_SUPPORT set in src.conf. This setting also breaks databases/postgresql-server but it's a known quantity there. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Conrad Meyer changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |c...@freebsd.org --- Comment #3 from Conrad Meyer --- Please do not CC huge mailing lists on bugs. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC||freebsd-current@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 jtkoert...@gmail.com changed: What|Removed |Added CC||jtkoert...@gmail.com --- Comment #31 from jtkoert...@gmail.com --- (In reply to Thomas Steen Rasmussen / Tykling from comment #25) I must admit it looks like exactly this. If you take a look at the first versions of qjail, you can see, that the 'Author' Joe Barbish just stole the main code from ezjail and even forgot to remove all occurances of the pattern 'ezjail' in the code he redistributed under his own name (https://sourceforge.net/projects/qjail/files/qjail-1.0.tar.bz2/download) - of course you can find tons of other portions of the original ezjail code (https://lists.freebsd.org/pipermail/freebsd-jail/2013-March/002120.html), but that is just funny: [xxx qjail-1.0.tar]# grep -R 'ezjail' * qjail.conf.sample:# This is the default location where ezjail archives its jails to Stealing code and than making such an effort to ruin the original authors work? Shame on you, script kiddie! As the most relevant people already stated here: There is no reason to remove that bits, that will in return doing harm to ezjail users, without removing any risks or problems from the base. period. So the responsible FreeBSD people should close this 'bug' as there is no evident reason for this, except the personal intention of Joe Barbish. People like him shouldn't get to much attention and at least no support from a community of real coders. I'm doing this job since the late eighties and might be a little blue, but claiming others code/work as your own is nothing an opensource community should accept or tolerate. Keeping this as an open 'bug' implies that. Not a good sign. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #29 from Joe Barbish --- Today I submitted PR# 219421. This handbook patch removes all ezjail documentation from the handbook jail chapter and adds an political correct entry which is fair to all the jail management utilities in the port system as seen below. 14.4.2. High-Level Administrative Tools in the FreeBSD Ports Collection Manually creating and managing jails can quickly become tedious and error-prone. The ports collection contains some utilities designed to simplify jail management. Their listing here doesn't imply an recommendation or endorsement. Nothing more than a list of the different names of jail utilities in the ports sysutils category that you may want to review. bsdploy, cbsd, ezjail, iocage, iocell, jail-primer, jailadmin, qjail, warden The maintainer of ezjail has been provided a simple patch that removes ezjail's reliance on the conversion code in the /etc/rc.d/jail script thus clearing the way for this PR to move forward. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #28 from Miroslav Lachman <000.f...@quip.cz> --- (In reply to Jonathan Anderson from comment #27) I think the opposite way. Or we end up with the same problems as with ezjail, portupgrade, portmaster etc. now. Some features in base are stalled or very complicated just to not break 3rd party tools with no active maintainer. "because they are in Handbook" It would be better to document jails with base tools and just some list of 3rd party tools with brief info about them and link to homepage of those projects. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Jonathan Anderson changed: What|Removed |Added CC||jonat...@freebsd.org --- Comment #27 from Jonathan Anderson --- (In reply to Miroslav Lachman from comment #26) > ezjail is not the only one tool to manage jails and should not be used > to take FreeBSD base as hostage. There are many alternatives and migration > path is very trivial. > > It's time to move on. ezjail may not be the only jail management utility, but it's the only one in the Handbook. Before we "move on" from ezjail, perhaps the alternatives should be be documented in the same place? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #26 from Miroslav Lachman <000.f...@quip.cz> --- (In reply to Thomas Steen Rasmussen / Tykling from comment #25) Are you serious? Then why Joe provided the idea how to make ezjail survive this code removal? Did you read the comment from Jamie? Did you compare rc.d/jail with legacy support and without it? The legacy support is a mess compared to new style and some functionalities are missing. As I already stated - ezjail is not the only one tool to manage jails and should not be used to take FreeBSD base as hostage. There are many alternatives and migration path is very trivial. It's time to move on. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Thomas Steen Rasmussen / Tykling changed: What|Removed |Added CC||tho...@gibfest.dk --- Comment #25 from Thomas Steen Rasmussen / Tykling --- I believe the only reason the original poster insists on removing this now is to deliberately break ezjail, so people will switch to his qjail tool rather than stay with ezjail. Obviously this kind of behaviour does not belong here. _Please_ keep the compatibility code in place until something else has been sorted. To solve ezjails problem of jail.conf being difficult to manage from sh scripts erdgeist (ezjail author) offered to extend jail(8) with config file management capabilities earlier in this thread. I do suggest we take him up on the offer. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Jamie Gritton changed: What|Removed |Added CC||ja...@freebsd.org --- Comment #24 from Jamie Gritton --- The easiest "fix" is certainly to remove the warning that the old method is going away. I wouldn't quite call it "mistaken", but I'll (almost) agree there's no overriding need to take the bits out of rc.d/jail that translate the old shell variables. Almost, because there are some confusing multiple paths on the kernel side that I'd would like to have deprecated, namely the security.jail.xxx_allowed and similar sysctls that used to be the only way to (globally) affect a lot of jail behavior, and are replaced by per-jail parameters but still live on as default values. But I can't get rid of those because they're part of the old shell-based setup. I remember some talk in the last year or two about a config file library that would allow (among other things) those DOS-like files that shell scripts seem to like. What's the latest on that? Jail.conf in particular had some sticking points as I recall. Something like that could be enough for ezjail, though I also wouldn't mind of ezjail just started using the current jail.conf format. Yes, it's harder for a shell script to use generally, but it would be possible to keep track of a shell-machine-readable version with a "hands off" comment at the top of it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849
--- Comment #23 from Miroslav Lachman <000.f...@quip.cz> ---
(In reply to Warner Losh from comment #22)
I think it turns in to bikeshed now. Are we talking about rc.conf variables to
configure jails or about this as dependency for ezjail?
No matter if you have 1 or 5 or 20 jails. The configuration in jail.conf is as
simple as in rc.conf, maybe even easier and more flexible.
## rc.conf style
jail_enable="YES"
jail_list="alpha"
jail_exec_start="/bin/sh /etc/rc"
jail_exec_stop="/bin/sh /etc/rc.shutdown"
jail_devfs_enable="YES"
jail_devfs_ruleset="devfsrules_jail"
jail_flags="-l -U root"
jail_alpha_rootdir="/vol0/jail/alpha"
jail_alpha_hostname="alpha.example.com"
jail_alpha_ip="10.11.12.13"
## jail.conf style
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
exec.jail_user = "root";
path= "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
# A typical jail.
alpha {
host.hostname = "alpha.example.com";
ip4.addr = 10.11.12.13;
}
But if we are talking about jails management utility, then we have none in base
but a lot in ports / packages that does not depend on rc.conf style.
We migrated all our jails on all machines from rc.conf to jail.conf the first
time I have seen the warning after machine upgrade. It was really easy.
I agree removing some feature on dot release can be a problem but I really
don't understand why we should maintain two different styles for configuring
jails in base.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #22 from Warner Losh --- Julian is saying that the code was deprecated by mistake. The functionality is useful and should remain, despite the warning. He's saying that even though we warned people the code was going away, it appears clear (to him at least) that we should retain this interface because it lowers the barrier to entry for jails when you have just a few. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #21 from Miroslav Lachman <000.f...@quip.cz> --- (In reply to Julian Elischer from comment #20) Why? To miss the opportunity to remove deprecated code for the next major release again? Then why we even put warnings to outdated code, ports and so on. If somebody that heavily depends on the old rc.d/jails behaviour then it should be moved to the ports... and maintained by somebody. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #20 from Julian Elischer --- previous comment shoudl have read "I strongly request that the bug be closed again". -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Julian Elischer changed: What|Removed |Added CC||jul...@freebsd.org --- Comment #19 from Julian Elischer --- I really really disagree that this bug should be acted upon there are so many people out there who do a small numebr of simple jails in this way. I think the bug shoudl just be closed. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Ngie Cooper changed: What|Removed |Added Status|Closed |Open Flags||mfc-stable9-, ||mfc-stable10-, ||mfc-stable11- CC||n...@freebsd.org Resolution|Works As Intended |--- Version|11.0-RELEASE|CURRENT --- Comment #18 from Ngie Cooper --- (In reply to Brooks Davis from comment #17) The concern is still somewhat valid for 12.0-CURRENT. Reopening, but making it abundantly clear that this change will never, EVER, be MFCed. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Brooks Davis changed: What|Removed |Added Resolution|--- |Works As Intended CC||bro...@freebsd.org Status|New |Closed --- Comment #17 from Brooks Davis --- (In reply to Joe Barbish from comment #16) As a project we DO NOT remove documented features from branches after the .0 release. This sometimes mean we continue shipping a feature we had intended to remove as is the case for the jail_* variables. It happens, we move remove it later and move on (I've removed code with decade "remove this soon" comments. On top of existing policy, removing this compatibility has little value that I can see so we would cause harm to users for no real purpose. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #16 from Joe Barbish --- This is my objection to waiting for 12.0 before doing this. When 10.0 came out the removal of the rc.conf method was scheduled to happen at 11.0. Now 3+ years later 11.0 is out and the rc.conf method is still supported. Now your talking about waiting for 12.0 to remove the the rc.conf method. In 3-4 years this same problem will still not be fixed and again we will be talking about waiting for 13.0 to do it. What you really talking about is holding up os deployment based on a 3rd-party tool. That's just plain crazy. I purpose this solution. I believe that the /etc/rc.d/jail script is the single place where the current 11.0 system issues that warning message and processes the rc.conf method from. The removing of the rc.conf method will mean changing only that script. Someone else should verify this. Inspecting the current version of the ezjail-admin script shows the start/stop commands launches a custom script /usr/local/etc/ezjail. After a bunch of grinding it finally launches /etc/rc.d/jail which does the actual start/stop work. This /etc/rc.d/jail script is part of the base os release. Change the custom /usr/local/etc/ezjail script to launch /usr/local/etc/ezjail-jail instead of /etc/rc.d/jail. This is a one line change. Then populate the ezjail-jail script with the contents of the 11.0 /etc/rc.d/jail script. Make these changes to the port source and the corresponding changes to the port makefiles and bingo you have given ezjail the ability to internally use the rc.conf method for ever forward. Now with this single show stopper fixed the removal of the rc.conf method can proceed to be scheduled for 11.1. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #15 from Mathieu Arnold --- (In reply to Joe Barbish from comment #9) > I see no benefit to dropping rc.conf jail support on a major release over a > minor release. I both cases you are going to suffer the same consequences of > NOT heeding the warning you have been getting for the past 3+ years. You > should be taking this early warning to develop a migration to something else > to limit your production down time. Stalling dropping rc.conf jail support > is not a solution. You will have to face this sooner or later. There can be no dropping of features in minor releases. In the FreeBSD world, we call that POLA, for Principle of Least Astonishment. If the jail_ variables are droppped, it will be for 12.0, or 13.0, but not on 11.1, or 10.4, or whatever. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #14 from rai...@ultra-secure.de --- I think the PTB (powers that be) ultimately decided that it's not in the interest of the project to have a tool and (and possibly an API) in base to create jails a la ezjail. At least, that's my educated guess. IIRC, iX-Systems uses (and sponsors) iocage (previously "warden"). Doubtlessly, other vendors/integrator have their own tools for managing jails - some may be in-house. Maybe there was a tendency not to create too much overlapping functionality in the base-system. It would be interesting to know if any of these vendors would be affected. As such, maybe somebody can bring this up at the next dev/vendor-summit (which I assume to be at BSDCAN). -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 erdge...@erdgeist.org changed: What|Removed |Added CC||erdge...@erdgeist.org --- Comment #13 from erdge...@erdgeist.org --- (In reply to Ngie Cooper from comment #12) Actually, I can not really see a benefit at all in removing that converter in base. It is not like the OS hands users of jail.conf like files a tool to properly create or modify them. Jamie's rewrite of jail(8) just broke editing jail configs for shell scripts. No big deal, as long as the OS keeps a compatibility until there ARE tools. However, once you start taking these converters away from the base, it needs to be reimplemented in several ports, possibly leading to errors with each implementation. If there would be a simple jail-admin tool allowing me operate on those complex structures from a script, or if there would be something like a jail.d with management scopes, where I'd be sure that configs are not manually touched, I would happily give up config in shell variables. I also volunteered in getting stuff done, by adding code to jail(8) to extend the parser with config file management functionality, but Jamie used to be not as reponsive as I would've loved. If there's others wanting to review and possibly commit changes to the tool, I'd say that we go for it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #12 from Ngie Cooper --- For the sake of maintaining POLA, I recommend not breaking it on a dot-release and instead throw the switch on ^/head. I am very much in agreement there with grembo@. I think it would be a great idea to patch ezjail if possible, mark it BROKEN otherwise. If marked BROKEN, this will either force folks to transition from ezjail to another solution, and/or the author to update ezjail to use jail.conf. We should document qjail before doing that though so folks have a way to migrate to an alternate solution, if need be. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #11 from Conrad Meyer --- (In reply to Joe Barbish from comment #9) > I see no benefit to dropping rc.conf jail support on a major release over a > minor release. Breakage is expected in major releases; not in point releases. It makes sense to hold off until a new major release. There is no compelling reason this work needs to land before that. It's simply removing functionality that worked in 11.0. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #10 from Michael Gmelin --- (In reply to Joe Barbish from comment #9) I tried to give you feedback from real world installations and real world upgrade procedures, as you claimed ezjail isn't relevant any more. Even though I agree that the compatibility should be dropped, I don't see the urgency in this matter and don't get why it can't wait for a major release - like, what is the downside of keeping compatibility until 12-RELEASE. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #9 from Joe Barbish --- I see no benefit to dropping rc.conf jail support on a major release over a minor release. I both cases you are going to suffer the same consequences of NOT heeding the warning you have been getting for the past 3+ years. You should be taking this early warning to develop a migration to something else to limit your production down time. Stalling dropping rc.conf jail support is not a solution. You will have to face this sooner or later. If you feel this is too much for your environment, you could patch your copy of ezjail replacing rc.conf jail support with jail.conf support and post a PR. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #8 from Michael Gmelin --- (In reply to Joe Barbish from comment #7) As maintainer of sysutils/qjail you might look at this like it. I just know that we run hundreds of jails using ezjail and breaking that in anything but a major release would cause us major pain. I agree that he best way would be to fix ezjail of course, but if the author doesn't feel like it, breaking it on a minor release will cause a lot of headache for users for no good reason. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #7 from Joe Barbish --- In reply to comment # 3 which states "But I believe the number of ezjail-jails is significant." This is un-true, since 10.0 was published many ezjail users have been moving to qjail because qjail uses jail.conf and its a fork of ezjail so the users are familiar with its operation "Also, as you can see, until now (11.0) it's the 3rd-party tool recommended by the FreeBSD project itself (if you take the mentioning in the handbook as an endorsement)." This statement is also un-true. The FreeBSD project itself never publicly stated any position of 3rd-party tools. The inclusion of ezjail in the handbook is a current departure from the previous long held guild lines that no how-to-use details of 3rd-party tools would be contained in the handbook. A simple statement listing all the 3rd-party tools that may serve a certain function was allowable. The how-to-use details belong in the the 3rd-party tools manual pages. My comment. With RELEASE 10.0 published 1/4/2014, jail.conf became the direction jails are headed. Any one who uses the rc.conf jail method even today gets the warning message telling them to convert to the jail.conf method. This warming has been in existence for 3+ years now. This warning message even shows up when ezjail starts its jails. Its not like the ezjail maintainer doesn't know about this. ezjail has had 2 updates since 1/4/2014 when RELEASE 10.0 was published, PR# 357253, committed 6/10/14, an upgrade from 3.3 to 3.4, and PR# 402477 committed 11/27/2015, an upgrade from 3.4 to 3.4.2. The internal design of ezjail still has not been changed to the jail.conf method. 3+ years has been more than enough time for ezjail to be upgraded to the jail.conf method if the maintainer so desired. Based on the replies, I see no reason to not remove the rc.conf jail definition method from the rc.d script set now. Further more this task should be made a priority so it gets accomplished for inclusion in 11.1. At the same time the handbook ezjail section should be removed from the handbook being replaced with a simple informational statement listing all the 3rd-party jail tools, thus giving all of them fair and equal footing in the handbook. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Michael Gmelin changed: What|Removed |Added CC||gre...@freebsd.org --- Comment #6 from Michael Gmelin --- Even though is not the project's responsibility and the fact that it's quite rusty, ezjail remains popular and breaking people's jails on a dot release sounds like a bad plan. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Chris Hutchinson changed: What|Removed |Added CC||portmas...@bsdforge.com --- Comment #5 from Chris Hutchinson --- (In reply to Miroslav Lachman from comment #4) > Or maybe there should not be 3rd party tools used in Handbook. There should > be documented steps using tools in base and link to freshports to many 3rd > party jail tools. Let the users choose. Can I simply add a plus one here? I couldn't agree more on this. It seems very odd to me to read "FreeBSD" documentation. Only to have it explain how to use it through the use of 3rd party software. Isn't it supposed to teach new users how to use the features _provided by FreeBSD? I see no reason not to touch lightly on 3rd party alternatives. But, honestly. Making the article primarily about 3rd party software is just wrong. > > This is very similar problem to portmaster / portupgrade tools - they are > (were) used in Handbook but are not maintained well. They are lacking behind > ports framework features and then some features are not easily implemented > because ports team does not want to break things for these tools... Good example, Miroslav, and thanks! :-) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #4 from Miroslav Lachman <000.f...@quip.cz> --- There is nothing special on jails created by ezjail so the configuration can be converted very easily. I have my own solution for jails with very similar structure and nullfs mount as ezjail and conversion from rc.conf to jails.conf takes few minutes. I don't think ezjail is "recommended", it is documented and nobody has time to document any other tool. But that's another story. It would be nice if somebody write chapter for another jail tools but as I am not using any of them I cannot help with this. Or maybe there should not be 3rd party tools used in Handbook. There should be documented steps using tools in base and link to freshports to many 3rd party jail tools. Let the users choose. This is very similar problem to portmaster / portupgrade tools - they are (were) used in Handbook but are not maintained well. They are lacking behind ports framework features and then some features are not easily implemented because ports team does not want to break things for these tools... -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #3 from rai...@ultra-secure.de --- Fair enough. But I believe the number of ezjail-jails is significant. Also, as you can see, until now (11.0) it's the 3rd-party tool recommended by the FreeBSD project itself (if you take the mentioning in the handbook as an endorsement). It's not a show-stopper for me - I'm just pointing it out. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Miroslav Lachman <000.f...@quip.cz> changed: What|Removed |Added CC||000.f...@quip.cz --- Comment #2 from Miroslav Lachman <000.f...@quip.cz> --- I don't think anything in FreeBSD base should be driven / staled by lack o development in some external tools. Especially in case of jails - ezjail is not the only one or the best one. Ezjail is just one of many and there are much better tools with more features and compatible with jail.conf (modern way of maintaining jails) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 rai...@ultra-secure.de changed: What|Removed |Added CC||rai...@ultra-secure.de --- Comment #1 from rai...@ultra-secure.de --- My gut feeling is that this will break ezjail. This chapter: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html would then have to be rewritten for iocage, qjail, cbsd, iocell Not sure if iocage has some sort of migration-strategy for ezjail-jails. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Bug ID: 218849 Summary: Remove rc.conf jail configuration via jail_* variables Product: Base System Version: 11.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: conf Assignee: freebsd-b...@freebsd.org Reporter: qja...@a1poweruser.com CC: curr...@freebsd.org In RELEASE 10.0 the following message first appeared and is issued for all jails configured in the rc.conf file. /etc/rc.d/jail: WARNING: Per-jail configuration via jail_* variables is obsolete. Please consider migrating to /etc/jail.conf. Four new RELEASES have been published since jail.conf became the intended method to use and the rc.conf jail configuration via jail_* variables method is still allowed. I believe this is an oversight, its something that has fallen between the cracks and all but forgotten about. Four RELEASES is more than enough time for jail users and/or jail tools to make the move to the jail.conf method. It’s now time to remove the rc.conf jail configuration via jail_* variables method from the /etc/rc.d script set making jail.conf the only supported method. Hopefully RELEASE 11.1 will see this implemented. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
