Bug 286655
| Summary: | i386: Installer produces unbootable image | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Alexander Ziaee <ziaee> |
| Component: | kern | Assignee: | freebsd-i386 (Nobody) <i386> |
| Status: | Closed Unable to Reproduce | ||
| Severity: | Affects Only Me | CC: | cperciva, emaste, jhb, pauamma, rmacklem, ziaee |
| Priority: | --- | Keywords: | regression |
| Version: | 14.3-RELEASE | ||
| Hardware: | i386 | ||
| OS: | Any | ||
|
Description
Alexander Ziaee
2025-05-07 16:57:46 UTC
I installed from FreeBSD-14.3-BETA1-i386-disc1.iso in QEMU following defaults as much as possible except choosing UFS and not adding any extra users. I was unable to reproduce this issue. (I did stop at the "boot: " prompt once; I believe this can happen if there is an errant keystroke.) I did observe a bug during dist set installation though, reporting things like "6148914689804876330 files read @ 0.0 files/sec". Excuse me, I made a glaring omission, this issue is on BIOS only boot. My QEMU reproduction is BIOS boot (we don't support UEFI for i386 anyway) and MBR (the default). Would it be possible to get the output of `gpart <disk>` against the resulting disk? If it's a disk image you can attach to it via mdconfig, if it's a real disk, maybe try booting from the installer USB stick and then using the live fs to inspect the disk? I do not have this hardware but I have reached out to the testers for comment. I've opened https://reviews.freebsd.org/D50261 for the bogus file count (for stable/14; this is already fixed in main with a bsddialog update). A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a9b30c92ab1c0dbed31eed94b8b975eb574d2a3f commit a9b30c92ab1c0dbed31eed94b8b975eb574d2a3f Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2025-05-09 00:35:10 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2025-05-09 16:58:11 +0000 bsddialog: Correct type for bsddialog_total_progview It was an int, but printed with %lli format. Although it would be reasonable to use a 32-bit int here (i.e., changing the printf format instead) this matches what was done in bsddialog upstream (and now in main). PR: 286655 Reviewed by: asiciliano Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D50261 contrib/bsddialog/lib/barbox.c | 4 ++-- contrib/bsddialog/lib/bsddialog_progressview.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (In reply to Alexander Ziaee from comment #5) I just tried a couple of installs on an old i386 laptop I have using the 14.3-PRE-RELEASE bootonly iso and they worked. I tried a UFS root plus swap and did not delete the MBR and it worked. I also tried a UFS root, plus swap and a ZFS partition, deleting/recreating the MBR and it worked, as well. I did not try a ZFS root, since I consider ZFS unusable on 32bits. If someone wants me to try a different variant, just let me know. I tested with all 8 combinations of (ZFS-on-root vs. guided-UFS) x (beta1 vs. beta2) x (GPT vs. MBR), all on scratch installs under VirtualBox using i386 VMs, and I duplicate on both beta1 and beta2 for the ZFS x MBR combination, with a "Missing operating system" message instead of the loader screen. The other 6 combinations boot correctly into the installed FreeBSD. (In reply to Pau Amma from comment #9) Forgot to say this was with -disc1 in all cases. I heard back from the testers today. One of them was unable to reproduce this issue and the other's disk died, so I am now thinking it was just a very improbable coincidence. (In reply to John Baldwin from comment #4) I can do that later tonight or tomorrow. (Only seeing this request now.) (In reply to John Baldwin from comment #4) # ZFS on root, MBR, beta1 root@:~ # gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 20971519 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada0s1 Mediasize: 10737385472 (10G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32768 Mode: r0w0e0 efimedia: HD(1,MBR,0x90909090,0x40,0x13fffc0) attrib: active rawtype: 165 length: 10737385472 offset: 32768 type: freebsd index: 1 end: 20971519 start: 64 Consumers: 1. Name: ada0 Mediasize: 10737418240 (10G) Sectorsize: 512 Mode: r0w0e0 # ZFS on root, MBR, beta2 root@:~ # gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 20971519 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada0s1 Mediasize: 10737385472 (10G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32768 Mode: r0w0e0 efimedia: HD(1,MBR,0x90909090,0x40,0x13fffc0) attrib: active rawtype: 165 length: 10737385472 offset: 32768 type: freebsd index: 1 end: 20971519 start: 64 Consumers: 1. Name: ada0 Mediasize: 10737418240 (10G) Sectorsize: 512 Mode: r0w0e0 (In reply to Pau Amma from comment #9) Hmm, so only ZFS on MBF fails for you? Are you able to easily test if that case works in 14.2? I'm curious if that is a regression or if that has been broken for a while. (In reply to John Baldwin from comment #14) Broken the same way on 14.2-RELEASE for i386. Time to test that combo on amd64 14.x images, I think. Then maybe 13.x. (In reply to Pau Amma from comment #15) If it is broken on 14.2 as well then it at least is not a regression (even if not ideal). I don't want to waste your time, so only test on 13.x or 12.x if you really want to. It might be more interesting to test ZFS + MBR on amd64, though even that is more of an edge case. If amd64 is also broken then I would be inclined to just remove support from using ZFS + MBR from the installer and require GPT for ZFS instead. (In reply to John Baldwin from comment #16) Also broken (although I didn't check gpart list) on 14.2 amd64 and 13.3 amd64. I'll stop testing now unless you or someone need specific additional testing. So ZFS + MBR has been broken since OpenZFS was imported and there are two PRs about it which have a patch to bsdinstall to fix it: 271262 and 267843. The patch to fix this is at https://reviews.freebsd.org/D40816. I'm going to close this bug though as I don't think we've found any regressions relative to 14.2. |