ISO: 13-CURRENT does not boot in Live mode on BIOS
13-CURRENT based Live ISO does not boot. Getting
lock order reversal:
isofs -> bufwait established at:
(...)
md.c:895
Nevertheless it proceeds to loading the uzip, but then says
cannot mount tmpfs on /dev/reroot: operation not supported by device
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 20 (17 by maintainers)
Commits related to this issue
- cryptodev_load="YES" https://github.com/helloSystem/ISO/issues/11#issuecomment-733879711 — committed to helloSystem/ISO by probonopd 4 years ago
- Increase ESP size to 2048 KB, #11 Following https://github.com/freebsd/freebsd/commit/0a5f31e6db0a11743aeb4fae67d598679c9aaa7c — committed to helloSystem/ISO by probonopd 4 years ago
Possible explanation that helloSystem is using initgfx from NomadBSD (albeit a newer version than they do themselves).
Probably this ticket can be closed as the 13-CURRENT experimental builds seem to boot on BIOS devices.
Today’s
hello-13.0-CURRENT-3d72a66-amd64.isowritten to a USB flash drive (stress-tested 32 GB Kingston DataTraveler 3.0 PMAP s/nC860008AE288BF4189030BBD)Ergo Vista 631
Circa 2008. Success, with the drive in one of the two rear ports:
boot_muteOff-topic from boot: the touch pad is not driven, this might fall under https://github.com/helloSystem/ISO/issues/49#issuecomment-751280022
Note to self: in other situations (with e.g. NomadBSD) the late reappearance of the splash screen is sometimes much longer than a split-second.
kib points out “[ENODEV] is returned by vfs_mount when there is no registered fs and it cannot load the module”
Could be OpenZFS (i.e. the switch from the original ZFS port to OpenZFS) needs cryptodev loaded explicitly? You can also try kldloading it from the single user shell and then running reboot -r there.