https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277442
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|multime...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469
Bug ID: 277469
Summary: Installer incorrectly setting up UEFI boot manager
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470
Bug ID: 277470
Summary: Security Vulnerability: etcupdate incorrectly sets
permissions for
/var/db/etcupdate/conflicts/etc/master.passwd
Product: Base System
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470
Christos Chatzaras changed:
What|Removed |Added
Product|Base System |Security
Component|m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470
Christos Chatzaras changed:
What|Removed |Added
Hardware|Any |amd64
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|sect...@freebsd.org
--
You are rec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469
Mark Linimon changed:
What|Removed |Added
Keywords||install
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473
Bug ID: 277473
Summary: Virtio memory ballooning does not return unused memory
to host
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473
Laurent changed:
What|Removed |Added
CC||bry...@freebsd.org
--- Comment #1 from L
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473
Laurent changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
Thomas Dreibholz changed:
What|Removed |Added
CC||thomas.dreibh...@gmail.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #15 from Thomas Dreibholz ---
Created attachment 248918
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248918&action=edit
Screenshot of the issue with 14.0-RELEASE
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #16 from Thomas Dreibholz ---
Created attachment 248919
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248919&action=edit
Screenshot of the issue with 14.0-STABLE (20240229)
--
You are receiving this mail because:
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #17 from Michael Tuexen ---
Could it be that when using Virtual Box the VM just does not shutdown? So this
might be unrelated to the ertt issue?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #5 from Thomas Dreibholz ---
I tried 14.0-STABLE (202040229, i.e. the currently latest ISO available:
https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-STABLE-amd64-20240229-d19769300126-266911-disc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474
Bug ID: 277474
Summary: clang crashes with -fzero-call-used-regs when
optimization is enabled
Product: Base System
Version: Unspecified
Hardware: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474
dan-free...@berrange.com changed:
What|Removed |Added
Summary|clang crashes with |clang 17 crashes with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #18 from Thomas Dreibholz ---
No, this is a different bug
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450). I have to set
sysctl hw.efi.poweroff=0, so that the machine actually should power off as
intended.
The ertt m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #19 from Michael Tuexen ---
(In reply to Thomas Dreibholz from comment #18)
I'm confused:
Assuming you set hw.efi.poweroff=0 in /boot/loader.conf, not /etc/sysctl.conf,
are you observing any problem other than an error message
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #20 from Thomas Dreibholz ---
No, it is a sysctl:
$ sysctl hw.efi.poweroff
hw.efi.poweroff: 0
The default is 1. See also:
https://forums.freebsd.org/threads/efi-virtualbox-computer-non-stop-after-successful-shutdown-of-freebsd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474
--- Comment #1 from Ed Maste ---
Thanks for the analysis. It's too late to get a fix into the 13.3 release but
assuming it is this upstream issue/commit we should be able to include it in a
13.3 errata update prior to 13.2 passing EOL.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469
--- Comment #1 from Alex Bylund ---
This is with Intel RST, and a 512gb nvme and a 2tb ssd. It might just be
something to do with multiple drives.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
Oleksandr Kryvulia changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #7 from Thomas Dreibholz ---
hw.acpi.handle_reboot: 1
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #21 from Michael Tuexen ---
(In reply to Thomas Dreibholz from comment #20)
I think it is a loader tunable. At least it is listed when you use `sysctl -T`.
My question: Do you experience unexpected behavior when you use
hw.efi.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #8 from Oleksandr Kryvulia ---
Seems it is virtualbox-specific. I'll test it under bhyve and hyper-v and
report it back.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450
--- Comment #9 from Andriy Gapon ---
When hw.efi.poweroff=1, EFI shutdown routine is invoked much earlier than ACPI,
so ACPI has no play. It seems that the system hangs in the EFI routine instead
of powering off. So it must be a problem wit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #22 from Thomas Dreibholz ---
No, with setting hw.efi.poweroff=0, an EFI machine usually shuts down as
expected. The exception is the ertt module unload failure.
With the default of hw.efi.poweroff=1, an EFI machine never shuts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #23 from Michael Tuexen ---
(In reply to Thomas Dreibholz from comment #22)
So I think everything you are complaining about is covered in bug 277450. So
why reporting here?
--
You are receiving this mail because:
You are the a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #24 from Thomas Dreibholz ---
No, the machine does not power off in case of the ertt module unload failure,
even with hw.efi.poweroff=0. The patch in STABLE seems to just suppress the
ertt error message, but it reproducibly fail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
--- Comment #25 from Mike Karels ---
I strongly suspect that the ertt issue is unrelated to the failure to power
down. The message is printed (in the release) after all related processing is
done, so the system must be getting through the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|toolch...@freebsd.org
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211
--- Comment #8 from John Baldwin ---
Created attachment 248936
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248936&action=edit
fix.patch
Please try this patch. Looking at the dmesg, the address was translated
incorrectly. It
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211
John Baldwin changed:
What|Removed |Added
Assignee|b...@freebsd.org|j...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270441
Henrich Hartzer changed:
What|Removed |Added
CC||henrichhart...@tuta.io
--- Comme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272120
Mark Peek changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #2 from M
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270441
--- Comment #9 from Slawomir Wojciech Wojtczak ---
(In reply to Henrich Hartzer from comment #8)
I would add '!$' to the list alongside '!!' feature.
The !$ is the LAST argument of previous command.
Example 1:
# pwd
/
# m
37 matches
Mail list logo
