Bug 281278 - mfsroot_* and vfs.root.mountfrom is not working on legacy boot.
Summary: mfsroot_* and vfs.root.mountfrom is not working on legacy boot.
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 14.1-STABLE
Hardware: amd64 Any
: --- Affects Many People
Assignee: Warner Losh
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-09-05 00:42 UTC by Eric Turgeon
Modified: 2024-09-08 21:05 UTC (History)
1 user (show)

See Also:


Attachments
Picture of the issue on the latest FrreeBSD base. (218.63 KB, image/jpeg)
2024-09-07 04:32 UTC, Eric Turgeon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Turgeon freebsd_committer freebsd_triage 2024-09-05 00:42:40 UTC
I have these lines in loader.conf for the GhostBSD live image.
mfsroot_load="YES"
mfsroot_type="md_image"
mfsroot_name="/data/ramdisk.ufs"
vfs.root.mountfrom="ufs:/dev/md0"

The mount worked on our April build but is no longer botting on our August 6 snapshot build on legacy boot. The code is from 14/stable, and the snapshot is from August 6.

The error is that it can't mount ufs:/dev/md0. It stops at the mount prompt on the legacy boot, but it works perfectly on the EFI boot. I have tried to find what could have caused that issue on the freebsd-src 14/stable between April and August 6, and I cannot find anything.

I will be testing this on a new snapshot, but I thought I would report it immediately in case it is not fixed.
Comment 1 Warner Losh freebsd_committer freebsd_triage 2024-09-06 18:03:09 UTC
So if I understand correctly, stable/14 as of April booted with those lines, while stable/14 as of August 6th does not. Is that correct?

Can you flesh out a little more what one could use to reproduce the problem? How are you creating the image, what VM are you using (or bare metal), etc. I'd like to reproduce to confirm what's going on, and doing a bisection run would would likely be next if there's nothing suggesting itself immediately for why legacy would break.
Comment 2 Eric Turgeon freebsd_committer freebsd_triage 2024-09-07 03:21:19 UTC
(In reply to Warner Losh from comment #1)
I use https://github.com/ghostbsd/ghostbsd-build; it is built to work only from the GhostBSD repository.

Here is the last merge from FreeBSD https://github.com/ghostbsd/ghostbsd-src/pull/335.

I have a ThinkPad T530. It usually boots on EFI, but I switched it to legacy boot to test the issue when some users reported their VMs and systems were not booting in legacy boot.

We now use PKGBASE, and the 22.04.2 ISO booted fine on the legacy boot. 

I have been trying to find what could have caused that, but I can't find it.

I am about to make a change to build GhostBSD without a desktop and point ghostbsd-build for FreeBSD PKGBASE and test the new packages. It will save me time to test if the latest changes still do that or if they are fixed.
Comment 3 Eric Turgeon freebsd_committer freebsd_triage 2024-09-07 04:32:02 UTC
Created attachment 253388 [details]
Picture of the issue on the latest FrreeBSD base.

I built an ISO with the latest packages from https://pkg.freebsd.org/FreeBSD:14:amd64/base_latest/. I took a picture of the error of that build and attached it as a JPEG.
Comment 4 Eric Turgeon freebsd_committer freebsd_triage 2024-09-07 04:51:44 UTC
I have built one with the release from https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_1/, and it is booting fine, so the issue is probably near. After the release, I will try to narrow it down more.
Comment 5 Eric Turgeon freebsd_committer freebsd_triage 2024-09-07 16:25:34 UTC
OK, I did a build from the last commit on July 28, and it booted fine. From there, I started building the latest commit each day. Right now, I am building from August 1.
Comment 6 Eric Turgeon freebsd_committer freebsd_triage 2024-09-08 01:43:44 UTC
I was not able to test the August 01 build before now. The issue was introduced that day, so now I am looking at all the commits to see if I can find the problem.
Comment 9 Eric Turgeon freebsd_committer freebsd_triage 2024-09-08 02:50:53 UTC
I made a PR on my side: https://github.com/ghostbsd/ghostbsd-src/pull/342.

I will let CI run and make a build tomorrow, and if it boots fine, I will close this ticket.
Comment 10 Eric Turgeon freebsd_committer freebsd_triage 2024-09-08 21:05:20 UTC
OK, this is fixed on the GHsotBSD side. I am closing this work as intended since we don't want this by default in FreeBSD.