[Bug 253429] Failed invocation of /usr/sbin/service when going multi-user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253429 Bug ID: 253429 Summary: Failed invocation of /usr/sbin/service when going multi-user Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: s...@freebsd.org A few weeks ago I noticed that cron is no longer started on my system after a reboot. This is caused by /usr being on a separate ZFS file system that has not been mounted at the time when the rc script tries to start cron, despite it having a REQUIRE: FILESYSTEMS condition: # PROVIDE: cron # REQUIRE: LOGIN FILESYSTEMS # BEFORE: securelevel # KEYWORD: shutdown According to "service -e", cron is one of the last few services to be started: $ service -e /etc/rc.d/rctl /etc/rc.d/hostid /etc/rc.d/zpool /etc/rc.d/zvol /etc/rc.d/hostid_save /usr/local/etc/rc.d/microcode_update /etc/rc.d/zfsbe /etc/rc.d/zfs ... /etc/rc.d/cron /usr/local/etc/rc.d/sa-spamd /usr/local/etc/rc.d/dovecot /usr/local/etc/rc.d/postfix /etc/rc.d/bgfsck But in fact, starting cron is the first action when going multi-user and before local file systems (beyond / and /dev) have been mounted: ... ugen0.6: at usbus0 ukbd0 on uhub3 ukbd0: on usbus0 kbd2 at ukbd0 hidraw1 on uhub3 hidraw1: on usbus0 /etc/rc.d/cron: service: not found /etc/rc: WARNING: run_rc_command: cannot run /usr/sbin/cron Setting hostuuid: 1e0028e0-008c-4300-13a1-f46d04d87842. Setting hostid: 0x3c3b54d6. Starting file system checks: Mounting local filesystems:. The log shows, that the /usr/sbin/service command is not available, yet. The same is of course true for /usr/sbin/cron. Before mounting the essential file systems, commands like service are not available and I understand that this is a contradiction to file systems being mounted when going multi-user as directed by the output of "service -e". I'm not aware on any local modifications of my start-up scripts, but I guess that having a separate /usr partition is not common, anymore. Moving the "service" command to /sbin might fix this issue (to be verified). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253429] Failed invocation of /usr/sbin/service when going multi-user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253429 --- Comment #1 from Andriy Gapon --- You can try to use rcorder /etc/rc.d/* /usr/local/etc/rc.d/* to investigate why your system tries to start cron so early. Here, it is started much later, after LOGIN. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253313] lib/msun: hypotl(3) mishandles subnormal numbers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=25120662284466ecef976df8f86e97bafdedf991 commit 25120662284466ecef976df8f86e97bafdedf991 Author: Dimitry Andric AuthorDate: 2021-02-11 11:01:10 + Commit: Dimitry Andric CommitDate: 2021-02-11 11:01:10 + Fix lib/msun/test builds on platforms without 80-bit long doubles After d3338f3355a612cf385632291f46c5777bba8d18, the lib/msun test case 'hypotl_near_underflow' would fail to compile on platforms where long doubles weren't 80 bit, like on x86. Disable this particular test on such platforms for now. PR: 253313 MFC after: 1 week X-MFC-With: d3338f3355a612cf385632291f46c5777bba8d18 contrib/netbsd-tests/lib/libm/t_hypot.c | 4 1 file changed, 4 insertions(+) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253435] Jail do not create tunnel (wireguard) interface alias.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435 Bug ID: 253435 Summary: Jail do not create tunnel (wireguard) interface alias. Product: Base System Version: 12.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: robert.david.pub...@gmail.com When adding wireguard tunnel interface alias address to the jail I need to specify it without the interface name and create the address staticly before jail startup. Examples that does not work: 1) no wgnet0 address created jail.conf: ip4.addr = "wgnet0|192.168.0.10"; 2) wgnet0 address created using ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias jail.conf: ip4.addr = "wgnet0|192.168.0.10"; Example that works: when I create the alias and remove the interface name from ip4.addr wgnet0 address created using ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias jail.conf: ip4.addr = "192.168.0.10"; Seems like the last one works by accident, because it assigns to the correct interface if the address is defined. I don't know if this affects only wireguard or generic tunnel interface. But the solution would be make the first example working by using different ifconfig arguments in the jail starting procedure. Eg: ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253435] Jail does not create tunnel (wireguard) interface alias.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435 Robert David changed: What|Removed |Added Summary|Jail do not create tunnel |Jail does not create tunnel |(wireguard) interface |(wireguard) interface |alias. |alias. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dc57f212526d25e8ef036e768b816a7fdae5707b commit dc57f212526d25e8ef036e768b816a7fdae5707b Author: Kyle Evans AuthorDate: 2021-02-11 15:11:24 + Commit: Kyle Evans CommitDate: 2021-02-11 15:12:17 + grep: fix -A handling in conjunction with -m match limitation The basic issue here is that grep, when given -m 1, would stop all line processing once it hit the match count and exit immediately. The problem with exiting immediately is that -A processing only happens when subsequent lines are processed and do not match. The fix here is relatively easy; when bsdgrep matches a line, it resets the 'tail' of the matching context to the value supplied to -A and dumps anything that's been queued up for -B. After the current line has been printed and tail is reset, we check our mcount and do what's needed. Therefore, at the time that we decide we're doing nothing, we know that 'tail' of the context is correct and we can simply continue on if there's still more to pick up. With this change, we still bail out immediately if there's been no -A flag. If -A was supplied, we signal that we should continue on. However, subsequent lines will not even bothere to try and process the line. We have reached the match count, so even if the next line would match then we must process it if it hadn't. Thus, the loop in procfile() can short-circuit and just process the line as a non-match until procmatches() indicates that it's safe to stop. A test has been added to reflect both that we should be picking up the next line and that the next line should be considered a non-match even if it should have been. PR: 253350 Approved by:re (gjb) (cherry picked from commit 3e2d96ac974db823255a6f40b90eeffa6e38d022) (cherry picked from commit 08f25b50dbd332e5c5c9380fd90c516e9af1ab36) contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 + usr.bin/grep/util.c | 21 - 2 files changed, 37 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253209] grep -v -f some-empty-file -- does the wrong thing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f28ccd8d95954134cec93db482fb0bd4ce93f36e commit f28ccd8d95954134cec93db482fb0bd4ce93f36e Author: Kyle Evans AuthorDate: 2021-02-11 15:10:44 + Commit: Kyle Evans CommitDate: 2021-02-11 15:12:10 + grep: fix null pattern and empty pattern file behavior The null pattern semantics were terrible because I tried to match gnugrep, but I got it wrong. Let's unwind that: - The null pattern should match every line if neither -w nor -x. - The null pattern should match empty lines if -x. - The null pattern should not match any lines if -w. The first two will stop processing (shortcut) even if additional patterns are specified. In any other case, we will continue processing other patterns. If no other patterns are specified beside a null pattern, then we match if neither -w nor -x or set and do not match if either of those are specified. The justification for -w is that it should match on a whole word, but the null pattern does not have a whole word to match on. Empty pattern files should never match anything, and more importantly, -v should cause everything to be written. PR: 253209 Approved by:re (gjb) (cherry picked from commit f823c6dc730b0dd08b54a53be1d8fd587eee7021) (cherry picked from commit 574d0dfae5011a766aa967f1d1675ddf7b535936) contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 22 +++--- usr.bin/grep/grep.c | 11 - usr.bin/grep/util.c | 35 + 3 files changed, 35 insertions(+), 33 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ad488c9793fd5040f8267620f370f319df31af2d commit ad488c9793fd5040f8267620f370f319df31af2d Author: Kyle Evans AuthorDate: 2021-02-08 18:31:17 + Commit: Kyle Evans CommitDate: 2021-02-11 15:20:26 + grep: fix -A handling in conjunction with -m match limitation The basic issue here is that grep, when given -m 1, would stop all line processing once it hit the match count and exit immediately. The problem with exiting immediately is that -A processing only happens when subsequent lines are processed and do not match. The fix here is relatively easy; when bsdgrep matches a line, it resets the 'tail' of the matching context to the value supplied to -A and dumps anything that's been queued up for -B. After the current line has been printed and tail is reset, we check our mcount and do what's needed. Therefore, at the time that we decide we're doing nothing, we know that 'tail' of the context is correct and we can simply continue on if there's still more to pick up. With this change, we still bail out immediately if there's been no -A flag. If -A was supplied, we signal that we should continue on. However, subsequent lines will not even bothere to try and process the line. We have reached the match count, so even if the next line would match then we must process it if it hadn't. Thus, the loop in procfile() can short-circuit and just process the line as a non-match until procmatches() indicates that it's safe to stop. A test has been added to reflect both that we should be picking up the next line and that the next line should be considered a non-match even if it should have been. PR: 253350 (cherry picked from commit 3e2d96ac974db823255a6f40b90eeffa6e38d022) contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 + usr.bin/grep/util.c | 21 - 2 files changed, 37 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253209] grep -v -f some-empty-file -- does the wrong thing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=92ddb6090b0c5091a64855a514676a452c10750c commit 92ddb6090b0c5091a64855a514676a452c10750c Author: Kyle Evans AuthorDate: 2021-02-04 21:26:45 + Commit: Kyle Evans CommitDate: 2021-02-11 15:19:26 + grep: fix null pattern and empty pattern file behavior The null pattern semantics were terrible because I tried to match gnugrep, but I got it wrong. Let's unwind that: - The null pattern should match every line if neither -w nor -x. - The null pattern should match empty lines if -x. - The null pattern should not match any lines if -w. The first two will stop processing (shortcut) even if additional patterns are specified. In any other case, we will continue processing other patterns. If no other patterns are specified beside a null pattern, then we match if neither -w nor -x or set and do not match if either of those are specified. The justification for -w is that it should match on a whole word, but the null pattern deos not have a whole word to match on. Empty pattern files should never match anything, and more importantly, -v should cause everything to be written. PR: 253209 (cherry picked from commit f823c6dc730b0dd08b54a53be1d8fd587eee7021) contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 22 +++--- usr.bin/grep/grep.c | 11 - usr.bin/grep/util.c | 35 + 3 files changed, 35 insertions(+), 33 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253209] grep -v -f some-empty-file -- does the wrong thing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209 Kyle Evans changed: What|Removed |Added Flags||mfc-stable13+, ||mfc-stable12+, ||mfc-stable11- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #6 from Kyle Evans --- This should be in -BETA2. Thanks for the report! -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350 Kyle Evans changed: What|Removed |Added Status|In Progress |Closed Flags|mfc-stable13?, |mfc-stable13+, |mfc-stable12? |mfc-stable12+ Resolution|--- |FIXED --- Comment #6 from Kyle Evans --- This should be in -BETA2. Thanks for the report! -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 --- Comment #13 from Yuri Pankov --- Just for the record, I'm not seeing any issues on P51, "Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz". -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 --- Comment #14 from Sreehari S --- (In reply to Yuri Pankov from comment #13) Maybe it only effects intel U processors? That's the only thing I can think of that the effected people's machines have in common that you don't (you've got HQ). Again could be completely wrong -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 --- Comment #15 from Sreehari S --- (In reply to Sreehari S from comment #14) I've got an i7-8565U and some hw probes: http://bsd-hardware.info/?probe=77e80759a0 http://bsd-hardware.info/?probe=8d1c80c2cb -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253435] Jail does not create tunnel (wireguard) interface alias.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|j...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 Yuri Pankov changed: What|Removed |Added CC||yur...@freebsd.org --- Comment #16 from Yuri Pankov --- (In reply to Sreehari S from comment #14) I also have Intel NUC7i7BNH featuring "Intel(R) Core(TM) i7-7567U CPU", and I don't remember seeing any issues with it either. The system does not have any storage device at the moment, but I'll get one shortly and re-check to confirm (or disprove) the U series guess. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243174] mq_unlink(3) manual page is missing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243174 Fernando ApesteguĂa changed: What|Removed |Added CC||fern...@freebsd.org Assignee|b...@freebsd.org|fern...@freebsd.org Status|Open|In Progress -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253440] dtrace failing to resolve some fbt probe argument types
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|ma...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253440] dtrace failing to resolve some fbt probe argument types
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440 Bug ID: 253440 Summary: dtrace failing to resolve some fbt probe argument types Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ma...@freebsd.org We have: > dtrace -lv -n fbt::ifa_alloc:entry ID PROVIDERMODULE FUNCTION NAME 52703fbtkernel ifa_alloc entry Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Types args[0]: (unknown) args[1]: int But: > ctfdump -f /boot/kernel/kernel | grep ifa_alloc [28508] FUNC (ifa_alloc) returns: 533 args: (35, 66) > ctfdump -t /boot/kernel/kernel | grep -B3 '<35>' <32> INTEGER unsigned long encoding=0x0 offset=0 bits=64 <33> TYPEDEF __uint64_t refers to 32 <34> TYPEDEF __size_t refers to 33 <35> TYPEDEF size_t refers to 34 So the type info is there. DTRACE_DEBUG shows libdtrace DEBUG: discovering probe fbt:kernel:ifa_alloc:entry id=52703 libdtrace DEBUG: failed to resolve input type size_t for fbt:kernel:ifa_alloc:entry arg #1: syntax error near " -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 --- Comment #17 from Sreehari S --- (In reply to Yuri Pankov from comment #16) >From what I can tell only Lenovo/thinkpad users have complained about this bug, though it's worth checking out if it affects all U processors or something. In all likeliness it could be some differences in MSR writes through some edge case not covered in FreeBSD that is covered in linux and others. I tried checking for deadlocks in the new code through printf debugging (that's all I know) and I couldn't find any myself, but I'm no expert so I wouldn't completely rule that out unless someone else can confirm. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 --- Comment #18 from Sreehari S --- (In reply to Sreehari S from comment #17) I might try to wrap my head around remote gdb or ddb or even trying to find crash dumps if they're created, but I'm not too familiar with all that yet. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253251] Hardware Revision Realtek 8117
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253251 Christian Gutzler changed: What|Removed |Added CC||christiangutz...@gmail.com --- Comment #1 from Christian Gutzler --- Created attachment 222373 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222373&action=edit Patch My first patch ever, hope I did everything right. Please review. THX -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253251] Hardware Revision Realtek 8117
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253251 --- Comment #2 from Christian Gutzler --- Comment on attachment 222373 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222373 Patch My first patch ever. Hope I did everything right. Pls review. THX. Christian -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 Bug ID: 253445 Summary: bectl: does not function in two-level zfs datasets Product: Base System Version: 12.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: do...@dawnsign.com I used mfsbsd to set up default datasets. If using non-raid, by default, mfsbsd formats its zfs datasets for a single disk as follows: Filesystem 1K-blocks Used Avail Capacity Mounted on tank/root 302305222 9711156 292594065 3% / devfs 1 1 0 100% /dev tank/root/tmp 292594102 37 292594065 0% /tmp tank/root/var 292924432 330366 292594065 0% /var When I attempt to list bootable environments, it comes back empty. [root@squid 11.Feb 12:20pm /usr]# bectl list [root@squid 11.Feb 12:20pm /usr]# bectl check does not return anything: [root@squid 11.Feb 12:20pm /usr]# bectl check [root@squid 11.Feb 12:20pm /usr]# I would like to implement boot environments using two level datasets. Is the three level datasets a requirement for using bectl? See https://forums.freebsd.org/threads/boot-environments-with-non-standard-dataset-layout-and-bectl-beadm.74925/ for additional details. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 Wes Maag changed: What|Removed |Added CC||jwm...@gmail.com --- Comment #1 from Wes Maag --- (In reply to do...@dawnsign.com from comment #0) Out of curiosity, what happens if you specify the root as tank? i.e bectl -r tank list? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 --- Comment #2 from do...@dawnsign.com --- [root@squid 11.Feb 12:32pm /]# bectl -r tank list [root@squid 11.Feb 2:36pm /]# -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 --- Comment #3 from do...@dawnsign.com --- Out of curiosity, I did this: [root@squid 11.Feb 2:36pm /usr]# bectl -r tank/root list BE Active Mountpoint Space Created tmp - /tmp 58K 2021-02-06 13:49 var - /var 336M 2021-02-06 13:49 [root@squid 11.Feb 2:37pm /usr]# -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 --- Comment #4 from Wes Maag --- Created attachment 222379 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222379&action=edit diff to allow the pool dataset to be the BE root when specified -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 --- Comment #5 from Wes Maag --- Yeah, libbe really wants there to be at least two levels. It checks for the existence of a '/' in the root name and errors out if it does not exist. Attached is a diff that I scratched together which seems to work works[wes]:/home/wes $ zfs list -r test [16:27:06] NAME USED AVAIL REFER MOUNTPOINT test 246K 832M 24K none test/root124K 832M 24K /tmp/bectl_test_75GY test/root224K 832M 24K /tmp/bectl_test_75GY works[wes]:/home/wes $ bectl -r test list [16:16:30] BEActive Mountpoint Space Created root1 - - 24K 2021-02-11 15:46 root2 - - 24K 2021-02-11 15:46 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 252132] mergemaster: needs to cope with empty $FreeBSD$ tags or /etc files must have $FreeBSD: number$
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252132 Katsuyuki Miyoshi changed: What|Removed |Added CC||katsu...@gmail.com --- Comment #3 from Katsuyuki Miyoshi --- Created attachment 222381 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222381&action=edit id_tools.tar.gz This is my personal solution. My solution is to replace "$FreeBSD$" with "$FreeBSD: MD5 $". (MD5 is the MD5 checksum of the source file.) "$FreeBSD: MD5 $" is not the original "$FreeBSD$" format, but it is useful enough for mergemaster. I'm happy with these. However, I don't know if these are enough for everyone who does various tasks. And, I don't even know what will happen to "$FreeBSD$" in the future. I hope that a better response will be made. Here are the steps: === [Provides 3 files] replace_id.sh: This is a script that replaces "$FreeBSD ... $" in files installed by "make distribution" with "$FreeBSD: MD5 $". src_id.sh: This is a git filter script. post-commit: This is a git hook script. -- [0] Start with the mergemaster completed by the traditional way. It doesn't matter if you use a subversion repository, a git repository, or any revision of the source files. -- [1-1] Backup the files installed by "make distribution" (That is, /etc/*, /root/*, and /boot/device.hints) It's not mandatory to do this, but I recommend that you back up your /etc, /root, /boot/device.hints files so that you can restore them in case of an accident. [1-2] # sh replace_id.sh Make sure the SOURCEDIR and DESTDIR in replace_id.sh are correct and run replace_id.sh. With the above, "$FreeBSD ... $" in files installed by "make distribution" will be replaced with "$FreeBSD: MD5 $". Make sure those files are not corrupted. -- [2-1] Now let /usr/src be the new git repository. [2-2] Install "src_id.sh" in the appropriate directory in the ${PATH}. (ex: /usr/local/bin/src_id.sh) And, in the git repository: [2-3] # git config filter.src_id.smudge 'src_id.sh add' [2-4] # git config filter.src_id.clean 'src_id.sh del' [2-5] # echo '* filter=src_id' >> .git/info/attributes [2-6] (After checking that your post-commit file doesn't exist in .git/hooks) # /bin/cp post-commit .git/hooks [2-7] # git ls-files -z | /usr/bin/xargs -0 /bin/rm -f [2-8] # git checkout -f >From now on, even if you update the source files, mergemaster will work fine. -- [Notes] When you first run mergemaster after the above work, you will be asked to merge the following four files. /etc/mail/freebsd.cf /etc/mail/freebsd.submit.cf /etc/mail/sendmail.cf /etc/mail/submit.cf For these, please merge at that time. (This is because replace_id.sh doesn't support cases for those files.) === That's all. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"