[Bug 274389] bhyve in 15-CURRENT unable to boot OpenBSD anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274389 --- Comment #12 from Corvin Köhne --- I've enabled BAR remapping in edk2 because it's required for ROM execution (e.g. PXE or VGA ROM) and VGA ROM shadowing. See https://github.com/tianocore/edk2/commit/70f3e62dc73d28962b833373246ef25c865c575e. The remapping range of OVMF is defined by: https://github.com/tianocore/edk2/blob/fb044b7fe893a4545995bfe2701fd38e593355d9/OvmfPkg/Bhyve/PlatformPei/Platform.c#L156-L157 (base = 0xC000, size = 0x4000). We may want to update those values to match our bhyve io range or we may want to adjust our bhyve io range: https://github.com/freebsd/freebsd-src/blob/82ea0132c8b17a7a6067c8a36c6434e587ede6de/usr.sbin/bhyve/pci_emul.c#L133-L134 (base = 0x2000, size = 0x1). Nevertheless, the OVMF range is part of the bhyve io range. So, that shouldn't be an issue. Another difference: Latest OVMF installs the ACPI tables provided by bhyve, while the old one uses static tables. However, bhyve's tables should report a correct io range (not checked yet) while it looks like the static ones do report a faulty one: https://github.com/tianocore/edk2/blob/fb044b7fe893a4545995bfe2701fd38e593355d9/OvmfPkg/Bhyve/AcpiTables/Dsdt.asl#L77-L83 (base = 0x0D00, size = 0xF300) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274689] 15-CURRENT does not load with bhyveload on 12-STABLE: ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274689 Bug ID: 274689 Summary: 15-CURRENT does not load with bhyveload on 12-STABLE: ERROR: cannot open /boot/lua/loader.lua: no such file or directory. Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bhyve Assignee: virtualization@FreeBSD.org Reporter: micha...@freebsd.org Hypervisor runs on: > FreeBSD deblndw013x.ad001.siemens.net 12.4-STABLE FreeBSD 12.4-STABLE > 5f446a12d GENERIC amd64 Created a VM with vm-bhyve: > loader="bhyveload" > cpu="4" > memory="4G" > network0_type="virtio-net" > network0_switch="VL-G-DE-SP02-1681" > disk0_type="virtio-blk" > disk0_name="disk0.img" > uuid="d6d905f9-71a9-11ee-b87d-b499bac04fbe" > network0_mac="58:9c:fc:08:58:c4" The installation is ZFS on root with GPT (UEFI). After the installation and the reboot the system says: > Consoles: userboot > > FreeBSD/amd64 User boot lua, Revision 1.2 > ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2 > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > Type '?' for a list of commands, 'help' for more detailed help. > OK > OK ls > open '/' failed: no such file or directory > OK lsdev > host devices: > host0: Host filesystem > disk devices: > disk0: Guest drive image > disk0p1: EFI > disk0p2: FreeBSD swap > disk0p3: FreeBSD ZFS I have used FreeBSD-15.0-CURRENT-amd64-20231019-fb7140b1f928-266042-disc1.iso As soon as I switch to loader="uefi" the system boots. Log file: > Okt. 24 11:43:27: initialising > Okt. 24 11:43:27: [loader: bhyveload] > Okt. 24 11:43:27: [cpu: 4] > Okt. 24 11:43:27: [memory: 4G] > Okt. 24 11:43:27: [hostbridge: standard] > Okt. 24 11:43:27: [com ports: com1] > Okt. 24 11:43:27: [uuid: d6d905f9-71a9-11ee-b87d-b499bac04fbe] > Okt. 24 11:43:27: [debug mode: no] > Okt. 24 11:43:27: [primary disk: disk0.img] > Okt. 24 11:43:27: [primary disk dev: file] > Okt. 24 11:43:27: initialising network device tap1 > Okt. 24 11:43:27: adding tap1 -> bce1bridge (VL-G-DE-SP02-1681 addm) > Okt. 24 11:43:27: bring up tap1 -> bce1bridge (VL-G-DE-SP02-1681 addm) > Okt. 24 11:43:27: booting > Okt. 24 11:43:27: bhyveload -c /dev/nmdm-deblndw013x3v.1A -m 4G -e > autoboot_delay=3 -d /usr/local/bhyve/deblndw013x3v/disk0.img deblndw013x3v > Okt. 24 11:44:19: fatal; loader returned error 2 > Okt. 24 11:44:19: destroying network device tap1 > Okt. 24 11:44:19: stopped > Okt. 24 11:44:34: initialising > Okt. 24 11:44:34: [loader: bhyveload] > Okt. 24 11:44:34: [cpu: 4] > Okt. 24 11:44:34: [memory: 4G] > Okt. 24 11:44:34: [hostbridge: standard] > Okt. 24 11:44:34: [com ports: com1] > Okt. 24 11:44:34: [uuid: d6d905f9-71a9-11ee-b87d-b499bac04fbe] > Okt. 24 11:44:34: [debug mode: no] > Okt. 24 11:44:34: [primary disk: disk0.img] > Okt. 24 11:44:34: [primary disk dev: file] > Okt. 24 11:44:34: initialising network device tap1 > Okt. 24 11:44:34: adding tap1 -> bce1bridge (VL-G-DE-SP02-1681 addm) > Okt. 24 11:44:34: bring up tap1 -> bce1bridge (VL-G-DE-SP02-1681 addm) > Okt. 24 11:44:34: booting > Okt. 24 11:44:34: bhyveload -c /dev/nmdm-deblndw013x3v.1A -m 4G -e > autoboot_delay=3 -d /usr/local/bhyve/deblndw013x3v/disk0.img deblndw013x3v > Okt. 24 11:50:43: fatal; loader returned error 1 > Okt. 24 11:50:43: destroying network device tap1 > Okt. 24 11:50:43: stopped Seems like something is broken here... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274689] 15-CURRENT does not load with bhyveload on 12-STABLE: ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274689 Michael Osipov changed: What|Removed |Added CC||micha...@freebsd.org --- Comment #1 from Michael Osipov --- File is there: root@deblndw013x3v:/boot/lua # realpath loader.lua /boot/lua/loader.lua -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273557] Regression preventing bhyve from running inside a jail without IP after f74147e26999, breaks support for jailing bhyve with IPv4 and IPv6 disabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273557
--- Comment #19 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=bc6372602a0042e5496d9ab6637558f98af0deef
commit bc6372602a0042e5496d9ab6637558f98af0deef
Author: Jan Bramkamp
AuthorDate: 2023-09-04 08:38:25 +
Commit: Mark Johnston
CommitDate: 2023-10-24 13:21:26 +
bhyve: Use VMIO_SIOCSIFFLAGS instead of SIOCGIFFLAGS
Creating an IP socket to invoke the SIOCGIFFLAGS ioctl on is the only
thing preventing bhyve from working inside a bhyve jail with IPv4 and
IPv6 disabled restricting the jailed bhyve process to only access the
host network via a tap/vmnet device node.
PR: 273557
Fixes: 56be282bc999 ("bhyve: net_backends, automatically IFF_UP
tap devices")
Reviewed by:markj
MFC after: 1 week
(cherry picked from commit fd8b9c73a5a63a7aa438a73951d7a535b4f25d9a)
usr.sbin/bhyve/net_backends.c | 52 ---
1 file changed, 4 insertions(+), 48 deletions(-)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 273557] Regression preventing bhyve from running inside a jail without IP after f74147e26999, breaks support for jailing bhyve with IPv4 and IPv6 disabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273557
--- Comment #20 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=700689bc2abaf860801b3896ceae86b0072f406c
commit 700689bc2abaf860801b3896ceae86b0072f406c
Author: Jan Bramkamp
AuthorDate: 2023-09-04 08:38:25 +
Commit: Mark Johnston
CommitDate: 2023-10-24 13:21:17 +
bhyve: Use VMIO_SIOCSIFFLAGS instead of SIOCGIFFLAGS
Creating an IP socket to invoke the SIOCGIFFLAGS ioctl on is the only
thing preventing bhyve from working inside a bhyve jail with IPv4 and
IPv6 disabled restricting the jailed bhyve process to only access the
host network via a tap/vmnet device node.
PR: 273557
Fixes: 56be282bc999 ("bhyve: net_backends, automatically IFF_UP
tap devices")
Reviewed by:markj
MFC after: 1 week
(cherry picked from commit fd8b9c73a5a63a7aa438a73951d7a535b4f25d9a)
usr.sbin/bhyve/net_backends.c | 52 ---
1 file changed, 4 insertions(+), 48 deletions(-)
--
You are receiving this mail because:
You are the assignee for the bug.
