https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #17 from Dani I. ---
(In reply to Gleb Smirnoff from comment #16)
Ah sorry, that wasn't clear in my last comment. No, we have just used
"net.link.ether.ipfw=1" while testing with out 13.2 hosts - we do not have it
set in product
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275225
Bug ID: 275225
Summary: On ARM64 carp preempt not working as expected
Product: Base System
Version: 14.0-RELEASE
Hardware: arm64
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
--- Comment #6 from i...@tutanota.com ---
Yup. Sorry.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
Li-Wen Hsu changed:
What|Removed |Added
Resolution|--- |Not A Bug
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
--- Comment #4 from i...@tutanota.com ---
(In reply to Daniel Tameling from comment #3)
Actually, yes it did!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
Daniel Tameling changed:
What|Removed |Added
CC||tamelingdan...@gmail.com
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
--- Comment #2 from i...@tutanota.com ---
I have discovered that using `# passwd` creates a new password and then all
users need to type in the password.
On the boxes I have just upgraded from 13.2 to 14.0, the root password has been
"remov
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
--- Comment #1 from i...@tutanota.com ---
Sorry, they are in the wheel group, but they do NOT get asked for any password.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275222
Bug ID: 275222
Summary: 14.0-RELEASE su gives root to all users without
requesting a password
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275221
Bug ID: 275221
Summary: More rototilling of cdefs.h
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only M
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #16 from Gleb Smirnoff ---
Did you have net.link.ether.ipfw=1 on FreeBSD 12?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #15 from Dani I. ---
(In reply to Mark Johnston from comment #11)
(In reply to Gleb Smirnoff from comment #14)
Hey guys, thanks already for assisting and helping! That is really very much
appreciated! Please just get back to us
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275063
--- Comment #5 from Martin Birgmeier ---
I believe you are taking this bug too lightly. With it, 14.0 may be usable for
private home use, but not in any serious setting.
There is no harm in postponing a release if there are good reasons fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #14 from Gleb Smirnoff ---
I assumed that ether_ipfw & uid/gid rules problem has been there since very
beginning and is well known, maybe even documented. :)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #13 from Mark Johnston ---
(In reply to Gleb Smirnoff from comment #12)
Oh, I was looking at the crash from the net.link.ether.ipfw=1 case, where the
problem is clear: ether_output_frame() cannot pass an inp at all. But yes,
yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #12 from Gleb Smirnoff ---
Normally inp pointer is passed down to ipfw and if it is passed, the lookup is
avoided. So in the trace with tcp_respond the pointer was somehow lost and ipfw
looked up the same inpcb again.
I'll try
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Stat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275169
--- Comment #10 from Dani I. ---
Created attachment 246450
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246450&action=edit
Panic caused by sysctl net.link.ether.ipfw=1
A small update:
1: We're also able to trigger a panic when
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274812
Mark Johnston changed:
What|Removed |Added
Resolution|--- |Unable to Reproduce
St
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274812
--- Comment #4 from tomasz.sowin...@nucleus.malbork.pl ---
Thanks Guys for your help. I removed all entries from make.conf then rebuild
system with make build world. After that system was able to build normally.
Issue can be closed now.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274654
Andrey Bushev changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275063
Mark Johnston changed:
What|Removed |Added
Status|New |In Progress
--- Comment #4 from Ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275063
Mark Johnston changed:
What|Removed |Added
Blocks||275215
Referenced Bugs:
https://
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275215
Bug ID: 275215
Summary: tracking bug for 14.0 errata
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275044
Kristof Provost changed:
What|Removed |Added
Status|New |Closed
Resolution|---
25 matches
Mail list logo