Bug 283341
| Summary: | In version FreeBSD12.2 to FreeBSD 14.2 (include) bhyve host don't boot guest FreeBSD any version on BSD partition | ||
|---|---|---|---|
| Product: | Base System | Reporter: | DYM <dym> |
| Component: | kern | Assignee: | freebsd-virtualization (Nobody) <virtualization> |
| Status: | New --- | ||
| Severity: | Affects Some People | CC: | dym, imp, kevans, mp |
| Priority: | --- | Keywords: | bhyve |
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254813 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240364 |
||
|
Description
DYM
2024-12-15 08:35:38 UTC
I was able to reproduce this issue on a FreeBSD 14.2 host with a 14.2 guest using bhyveload. The earlier issue commented about it regressing in 12.2 so looking at the commits before that time had this one: https://github.com/freebsd/freebsd-src/commit/14243f8de746e756ad3466aa6920a80e39157d9c https://reviews.freebsd.org/D19262 which was MFC'd into 12.2: https://github.com/freebsd/freebsd-src/commit/7c7ef3e8f9f2309430d171f93e3cb85f463e87e6 bhyveload will load the host loader into the VM which is why it would regress when upgrading to 12.2 (and beyond). I applied this patch to revert a functional change and was able to boot diff --git a/stand/userboot/userboot/main.c b/stand/userboot/userboot/main.c index cf1d9b12d69f..8b8cc30ea91a 100644 --- a/stand/userboot/userboot/main.c +++ b/stand/userboot/userboot/main.c @@ -248,7 +248,7 @@ extract_currdev(void) dev.dd.d_dev = &userboot_disk; dev.dd.d_unit = 0; dev.d_slice = D_SLICEWILD; - dev.d_partition = D_PARTWILD; + dev.d_partition = 0; /* * If we cannot auto-detect the partition type then * access the disk as a raw device. This is not the correct long term patch but does indicate where the regression occurred. I've cc'd a couple of other people that might know more about what should be done here. It's a shame that the discussion ended in nothing at the time.
I believe that two different behaviors should not be described by one value.
In fact, I recently encountered some strange behavior of the disk subsystem.
Background.
There are two M.2 slots on the motherboard, one of them was NVMe with a system (GPT+ZFS).
It was installed “full automatic”.
Needed to clear NVMe 4Tb and partitioned to create another FreeBSD.
The 4Tb previously had GPT partitioning and three partitions: efi, system, home.
History.
After installing on Mb they were seen as nvd0p1, nvd0p2, nvd0p3
And the working system was on nvd1.
I had no way to repartition this 4Tb disk.
Until I _physically_ swapped these NVMe disks to Mb.
Booted by the label from the correct disk, and when mounting it.
partition nvd0p3 was attached (there was nothing there, only zeros),
and the normal nvd1p3 was mounted on top of it.
And I couldn't do anything with nvd0 because it was busy.
It turned out that Mb thought that the first slot was the slot farther away from the processor.
And when there was no disk in number 1, the second one was considered first.
These are all peculiarities of Mb. However, it was the fact that at boot up, there was a mess of confusion
with how the partitions were mounted was because the different modes
modes are described by one value.
P.S. IMHO. Finding and mounting partitions should be clearly deterministic.
If it is written that it is monitored by label -- mount by label.
Or by partition type/name in the sense of physical device numbering.
And it should be possible to specify how to perceive different partitions.
|
