Booting from a clean copy of /boot obtained from FreeBSD-12.0-RELEASE-amd64-bootonly.iso does not work. The BTX loader seems to have issues traversing the filesystem - when I poke around with 'ls', it sees the root, but can't enter subdirectories. The system disk uses BSD/UFS scheme. The loader however has no trouble browsing the storage disk, which is GPT/UFS. This has been previously reported a month ago in CURRENT as bug #233098 but was miscategorized and no additional info was provided. The issue is currently being discussed in https://forums.freebsd.org/threads/lua-error-can-not-open-boot-lua-loader-lua.68635/ I am currently working around this by booting off of the iso, then mounting the system disk. Interestingly, /dev/ada0 exists but dev/ada0a doesn't, and 'gpart list' does not even mention ada0. No idea what this means. I ran fsck just in case, all filesystems are clean. FreeBSD/x86 bootstrap loader. Revision 1.1 Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK lsdev disk devices: disk0: BIOS drive C (16514064 x 512): disk0a: FreeBSD UFS disk1: BIOS drive D (3907029168 x 512): disk1p1: FreeBSD UFS OK ls disk1p1:/example disk1p1:/example d dir1 d dir2 OK ls disk0a:/boot open 'disk0a:/boot' failed: no such file or directory OK ls disk0a:/root open 'disk0a:/root' failed: no such file or directory
Installing from media FreeBSD-12.0-RELEASE-amd64-disc1.iso in a VM (VirtualBox), legacy BIOS mode and BSD disklabel resulted in the same error: Can't boot with "LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory."
CCing tsoome@, since this is the one reported via IRC <= 24 hours ago -- looked like x86 loader may not be getting currdev set in some circumstances.
currdev and loaddev is set to 'disk0s4a'. This is maybe correct? (the size is weird tho') # fdisk /dev/ada0 ******* Working on device /dev/ada0 ******* parameters extracted from in-core disklabel are: cylinders=58161 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=58161 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: <UNUSED> The data for partition 2 is: <UNUSED> The data for partition 3 is: <UNUSED> The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 50000 (24 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63
Have been able to reproduce the issue inside a VM - when GPT isn't used, the problems always happen. Once switching to GPT, everything works as expected. Well, if you've an existing partition layout not using GPT, bad luck. Oh, problem solved here by reinstalling but of course not freebsd - if I've to reinstall anyways I thought I can switch to something better tested before releasing.
(In reply to vollbluthengst from comment #4) could you post: gpart list ada0 gpart list adad0s4 This setup sounds like you intend to have MBR partition table (4 slices), and in one slice, BSD disk label, thats why loader lsdev -v will show letters at the end of the disk names, like disk0p1a: however, in your example, you have something really weird going on with disk0, as we see disk0a:, with MBR + BSD I would expect the output like disk0s4a: in my test disk I have: Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 10474317 (5114 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 651/ head 254/ sector 63 The data for partition 2 is: <UNUSED> The data for partition 3 is: <UNUSED> The data for partition 4 is: <UNUSED> root@freebsd-2:~ # gpart list da3 Geom name: da3 modified: false state: OK fwheads: 255 fwsectors: 63 last: 10485759 first: 63 entries: 4 scheme: MBR Providers: 1. Name: da3s1 Mediasize: 5362850304 (5.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 efimedia: HD(1,MBR,0x90909090,0x3f,0x9fd34d) attrib: active rawtype: 165 length: 5362850304 offset: 32256 type: freebsd index: 1 end: 10474379 start: 63 Consumers: 1. Name: da3 Mediasize: 5368709120 (5.0G) Sectorsize: 512 Mode: r0w0e0 root@freebsd-2:~ # gpart list da3s1 Geom name: da3s1 modified: false state: OK fwheads: 255 fwsectors: 63 last: 10474316 first: 0 entries: 8 scheme: BSD Providers: 1. Name: da3s1a Mediasize: 5362850304 (5.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 rawtype: 7 length: 5362850304 offset: 0 type: freebsd-ufs index: 1 end: 10474316 start: 0 Consumers: 1. Name: da3s1 Mediasize: 5362850304 (5.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0
To add, a VM running inside Qemu so there's no ada0 - instead the device is vtbd0 and the gpart output: Geom name: vtbd0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 104857559 first: 0 entries: 2 scheme: BSD Providers: 1. Name: vtbd0a Mediasize: 50465341440 (47G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 50465341440 offset: 0 type: freebsd-ufs index: 1 end: 10485759 start: 0 2. Name: vtbd0b Mediasize: 2684354560 (2.5G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 3221245952 Mode: r1w1e0 rawtype: 1 length: 2684354560 offset: 50465886208 type: freebsd-swap index: 2 end: 103809063 start: 10485760 A reinstall with explicitly choosing GPT and ignoring the installer wants to use BSD the layout: Geom name: vtbd0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 104857559 first: 40 entries: 152 scheme: GPT Providers: 1. Name: vtbd0p1 Mediasize: 524288 (512K) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 efimedia: HD(1,GPT,d9da6ff2-021d-11e9-b4eb-00163cfd496c,0x28,0x400) rawuuid: d9da6ff2-021d-11e9-b4eb-00163cfd496c rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 524288 offset: 20480 type: freebsd-boot index: 1 end: 1063 start: 40 2. Name: vtbd0p2 Mediasize: 50465341440 (47G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 544768 Mode: r1w1e1 efimedia: HD(2,GPT,d9e22632-021d-11e9-b4eb-00163cfd496c,0x428,0x5dffc00) rawuuid: d9e22632-021d-11e9-b4eb-00163cfd496c rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 50465341440 offset: 544768 type: freebsd-ufs index: 2 end: 98566183 start: 1064 3. Name: vtbd0p3 Mediasize: 2684354560 (2.5G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 3221245952 Mode: r1w1e0 efimedia: HD(3,GPT,d9fa078e-021d-11e9-b4eb-00163cfd496c,0x5e00028,0x500000) rawuuid: d9fa078e-021d-11e9-b4eb-00163cfd496c rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 2684354560 offset: 50465886208 type: freebsd-swap index: 3 end: 103809063 start: 98566184 Consumers: 1. Name: vtbd0 Mediasize: 53687091200 (50G) Sectorsize: 512 Mode: r2w2e3 which works. Another system still affected by the issue: Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 976773167 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ada0a Mediasize: 5368709120 (5.0G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 5368709120 offset: 0 type: freebsd-ufs index: 1 end: 10485759 start: 0 2. Name: ada0b Mediasize: 17179869184 (16G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1073741824 Mode: r1w1e0 rawtype: 1 length: 17179869184 offset: 5368709120 type: freebsd-swap index: 2 end: 44040191 start: 10485760 3. Name: ada0d Mediasize: 5368709120 (5.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1073741824 Mode: r1w1e1 rawtype: 7 length: 5368709120 offset: 22548578304 type: freebsd-ufs index: 4 end: 54525951 start: 44040192 4. Name: ada0e Mediasize: 53687091200 (50G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2147483648 Mode: r1w1e1 rawtype: 7 length: 53687091200 offset: 27917287424 type: freebsd-ufs index: 5 end: 159383551 start: 54525952 5. Name: ada0f Mediasize: 418503483392 (390G) Sectorsize: 512 Mode: r1w1e1 rawtype: 27 length: 418503483392 offset: 81604378624 type: freebsd-zfs index: 6 end: 976773167 start: 159383552 Consumers: 1. Name: ada0 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r5w5e9 In the non-working cases the loader gets stuck being unable to find lua, lsdev shows disk0a / disk0b etc. and one is able to do "ls /" but unable to "walk" into directories. Manually setting currdev to e.g. disk0a still won't help. Booting from ISO, then setting currdev and loading the kernel helps as work-around. To reproduce do an install of 11.2-RELEASE inside a VirtualBox / QEMU VM, choosing BSD disklabel as layout, let it use the entire disk and then upgrade to 12.0-RELEASE.
so, I did: root@freebsd-2:~ # gpart list da3 Geom name: da3 modified: false state: OK fwheads: 255 fwsectors: 63 last: 10485759 first: 0 entries: 8 scheme: BSD Providers: 1. Name: da3a Mediasize: 5368709120 (5.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 5368709120 offset: 0 type: freebsd-ufs index: 1 end: 10485759 start: 0 Consumers: 1. Name: da3 Mediasize: 5368709120 (5.0G) Sectorsize: 512 Mode: r0w0e0 root@freebsd-2:~ # did put ufson it, did copy /boot and it is quite readable... even boot/lua :) BUT, I did test it with current... I can provide you binary loader so you can check if it does fix it for you - if it does, then we have already fixed the issue:)
I'm having the same issue with 12.0-RELEASE. I've also tried to build the world with the "LOADER_DEFAULT_INTERP=4th" setting in src.conf. In this case, I've just received the "can't load 'kernel'" error message, with no reference to a missing "loader.lua" file. My gpart output is the following. Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 468862127 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ada0a Mediasize: 240057409536 (224G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 240057409536 offset: 0 type: freebsd-ufs index: 1 end: 468862127 start: 0 Consumers: 1. Name: ada0 Mediasize: 240057409536 (224G) Sectorsize: 512 Mode: r1w1e2
The question is still up - is anyone experiencing this issue willing to test binary from 12 stable and current (I can build the binary) - so we can be sure the problem is not fixed already.
Well, wouldn't it be as simple as downloading latest CURRENT bootonly iso from https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ and transplanting /boot? If anyone still has a testing VM handy, maybe give it a try.
(In reply to ultramage from comment #10) I just did install 12-release to vmware fusion: root@freebsd-test:~ # uname -a FreeBSD freebsd-test 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64 root@freebsd-test:~ # gpart list Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 41943039 first: 0 entries: 8 scheme: BSD Providers: 1. Name: da0a Mediasize: 20401094656 (19G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 20401094656 offset: 0 type: freebsd-ufs index: 1 end: 39845887 start: 0 2. Name: da0b Mediasize: 1073741824 (1.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 3221225472 Mode: r1w1e0 rawtype: 1 length: 1073741824 offset: 20401094656 type: freebsd-swap index: 2 end: 41943039 start: 39845888 Consumers: 1. Name: da0 Mediasize: 21474836480 (20G) Sectorsize: 512 Mode: r2w2e3 root@freebsd-test:~ # And unfortunately it does boot just fine... Then I did create exactly the same install on vbox, and again it does boot... also browsing disk manually with ls (from OK prompt) does not give errors. Therefore I am in trouble with reproducing the error.
Right. I tried the posted instructions in vmware player 14, using both guided and manual partitioning, and using both freebsd-update and just copying /boot. In all cases, the loader could find the disk just fine. I used the -disc1 isos from the ftp server. It's difficult for me to do live testing on the affected host at the moment. I hope the others posting here can reproduce this. More detailed steps (and perhaps a confirmation from the person who posted them) would be helpful. > To reproduce do an install of 11.2-RELEASE inside a VirtualBox / QEMU VM, choosing BSD disklabel as layout, let it use the entire disk and then upgrade to 12.0-RELEASE.
(In reply to ultramage from comment #12) I am not even sure the detailed instructions are possible - it is more about if you find the affected host, and can create disk image, such image would be helpful. This is because it seems to me, it is about some sort of corner case in ufs reader.
Hello. Installed again (fresh install) from FreeBSD-12.0-RELEASE-amd64-disc1.iso (MD5 9d3d2933390400918736fcdf46825ee3)in VirutalBox with same error result. Installed two times, one with default IDE controller other with SATA controller, both tries resulted with same broken boot. Installed with default installer options except scheme, choosing BSD disk label (entire disk). Windows10 Guest and VirtualBox 5.2.18 r124319(Qt5.6.2). I exported the appliance (.ova) so tell me if have interest. Unfortunately my internet is very, very bad atm (not at home) but I can try uploading (850Mb).
Ok. I've uploaded the exported virtualbox appliance in the case it helps in something: http://www.minasambiente.com.br/repo1/FreeBSDT2.ova (MD5 482f2e5489aa949af904cf49fa6ae9f9). Also, tell me what more I can do with this VM to help (if anything). Thanks!
Thank you. Your vm image reproduces the issue on VMWare Workstation 14 Player. And by booting off of and then copying /boot from FreeBSD-13.0-CURRENT-amd64-20181213-r342020-bootonly.iso I can get the VM to work properly. That's the oldest image I can find, but maybe the FreeBSD devs can use the VM to narrow down the regression window. I then gave reproducing it another try, since I noticed the VM used slightly different options. I then determined that when using the default HDD controller mode, SCSI, or using SATA, it works. But when IDE mode is used, it doesn't. Well, at least for this virtual machine software. I'm fairly sure my server uses SATA+AHCI.
(In reply to ultramage from comment #16) ok, I got the image and I can see the problem already - if you run show currdev, it will be quite apparent. I think I can guess whats wrong there, and if I'm correct, it should be fixed in 12-stable too.
(In reply to Toomas Soome from comment #17) This would be worthy of an EN, yeah?
(In reply to ultramage from comment #16) Did following checks: booted from 12 release iso, OK ls disk0a:boot did gave an error. booted from FreeBSD-12.0-STABLE-amd64-20181226-r342545-disc1.iso - no error from ls. booted from FreeBSD-13.0-CURRENT-amd64-20190103-r342707-disc1.iso - no error from ls. So we have fix in 12 stable. I think it likely is this fix: https://svnweb.freebsd.org/base?view=revision&revision=340240 but I have not verified it.
I have applied the change you linked to to releng/12.0 r343997 and the issue is still present. Manipulating the loader disk variable currdev does nothing and changing lodadev is not permitted. Which doesn't matter since the loader still can't traverse the filesystem. I would like to request that this issue be escalated to critical and added to the 12.0 errata. Since STABLE is supposedly fixed, it should be possible to identify the exact code that causes this. A brief note: In a VMWare VM, IDE fails but SATA and SCSI work. On my machine, SATA(AHCI) fails.
(In reply to ultramage from comment #20) Could you check with stable/12? We have backported a list of updates from current to stable/12.
I have transplanted the contents of FreeBSD-12.0-STABLE-amd64-20190207-r343863-bootonly.iso's /boot directory, minus the kernel, into the 12.0-releng host that has the issue. The updated loader works and I am currently using it as a workaround.
For me this issue occurs immediately when trying to boot from a CD, even without any hard disk present. This is on a physical machine, not a VM, and with the hard disk disconnected. I have tried FreeBSD-12.0-STABLE-i386-20190207-r343863-bootonly.iso, FreeBSD-12.0-STABLE-amd64-20190207-r343863-bootonly.iso, and FreeBSD-13.0-CURRENT-i386-20190207-r343862-bootonly.iso, and all 3 result in the loader stopping at the "OK" prompt after the same "LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory." error (despite the fact that that file is present in each of those CDs) -- and I am unable to traverse the CDROM filesystem from the loader prompt. I have also tried FreeBSD-11.2-STABLE-i386-20190207-r343863-bootonly.iso, which works perfectly.
This issue also occurs for me when booting from a CD-ROM installation image for 12.0-REL-i386 and 12-STABLE-i386 snapshot ISO of 20190207 on real hardware (Apple Mac mini 2,1).
Hit the same issue while trying to boot kernel and world compiled from base/head sources (13-CURRENT) with TARGET_ARCH=aarch64 via network. So the loader.efi is also somehow affected and this is not only ISO-images and not only amd64 related issue. Add it is still present :( ...(log skipped)... BOOTP broadcast 1 DHCP client bound to address 192.168.1.201 (1 ms) Using ethernet@ff540000 device TFTP from server 192.168.1.102; our IP address is 192.168.1.201 Filename 'boot/loader.efi'. Load address: 0x800800 Loading: ################################################################# ############################################################## 3.9 MiB/s done Bytes transferred = 646512 (9dd70 hex) Speed: 1000, full duplex Using ethernet@ff540000 device TFTP from server 192.168.1.102; our IP address is 192.168.1.201 Filename 'boot/loader.efi'. Load address: 0x2080000 Loading: ################################################################# ############################################################## 3.9 MiB/s done Bytes transferred = 646512 (9dd70 hex) Speed: 1000, full duplex Using ethernet@ff540000 device TFTP from server 192.168.1.102; our IP address is 192.168.1.201 Filename 'boot/dtb/rockchip/rk3328-rock64.dtb'. Load address: 0x1f00000 Loading: ########## 3.4 MiB/s done Bytes transferred = 49194 (c02a hex) Scanning disk rksdmmc@ff500000.blk... Card did not respond to voltage select! Scanning disk rksdmmc@ff520000.blk... Disk rksdmmc@ff520000.blk not ready Found 2 disks Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env FreeBSD/arm64 EFI loader, Revision 1.1 (Sat Aug 10 14:11:30 JST 2019 denis@buildarm) Command line arguments: loader.efi EFI version: 2.70 EFI Firmware: Das U-Boot (rev 8217.1792) Console: efi (0) Load Path: /boot\dtb\rockchip\rk3328-rock64 Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(82d605ceda87,0x1) Setting currdev to net0: Speed: 1000, full duplex net0: cannot set rx. filters (status=3) Setting currdev to net0: Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK
Please ignore my previous message. The error message: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. was due to mis-configuration of my NFS server, so the loader.efi did not have access to the /boot directory.
I did an test today with failing vbox image - with loader from latest current, it does load and start the kernel. However, not 100% sure what was the cause, therefore can not be 100% sure we have fix.
I don't think this is fixed. My hardware is much like Trev's 2019-04-16 comment: I'm using an old MacPro1,1. [1] All disks physically removed except a real DVD made from the .iso. No upgrading here, just trying to boot an install DVD. My result is much like Jeff Gibbons' 2019-02-15 comment, but I've used a newer build: FreeBSD-13.0-CURRENT-amd64-20191226-r356085-disc1.iso.xz By contrast, I've succeeded in booting an OpenBSD 6.6 install DVD. So I'm pretty sure my hardware is fine, and my DVD burning works. [1] https://everymac.com/systems/apple/mac_pro/specs/mac-pro-quad-2.66-specs.html
(In reply to Sean McBride from comment #28) Could you test with latest image (20200123 seems to be currenlty latest one). Also please paste output from lsdev -v (from loader prompt).
Same with 20200123 build. lsdev -v gives: cd devices: cd0: BIOS drive C (12402432 X 2048): (As I said, I have no other disks connected.)
I am also having this same problem on a Pentium 3 machine (Acer Altos 1100e), FreeBSD 10.4 is the last version that can successfully boot to installer from CD, oddly I have another Pentium 3 machine (Dell Precision 220) that I had no issue installing FreeBSD 12.1 on.
I went ahead a moved the hard drive from the unaffected system to the affected system and upon booting I got some console spam, something to the effect of "loading 8 sectors from device ada0 to 0x77fe5" but once the kernel loads it goes away, and boots fine. Is int13 being used to read from devices this early in boot or is FreeBSD using that other fancy one that I could never get to work?
(In reply to Adam from comment #32) Yes, all BIOS systems still use INT13 to read from disks. It would be helpful to get exact messages. However, to get on with diagnostic, we would need to build custom cd image with debug printouts. And all that in few cycles. BIOS disk message from MBP is more qurious, that sounds like bootcamp and bootcamp is reported to have "interesting" bugs. Native MBP would be UEFI boot.
(In reply to Toomas Soome from comment #33) It was interrupt 25 that I was thinking of, just give it a buffer and how many sectors you want and no more int 13 loop dance. but I never was able to get it to work. the exact output of the console spam is: disk0: Read 8 sectors(s) from 304087096 to 0x5ddbc (0x67dbc): 0x4 once the kernel starts the console spam stops. sounds like I'll need a serial to serial cable, I'll have a look around.
Toomas, pardon my ignorance, but what is "MBP"? Did you mean "MBR"?
(In reply to Sean McBride from comment #35) Oops, my bad, I meant MacPro which is referred above.
Ah ok. It's probably worth noting that the MacPro1,1 is a bit weird in that it's generally a fully 64 bit system, *except* it has only 32 bit EFI. Apparently, FreeBSD does not support EFI32, see #215143. So, I have used the technique below to remove the EFI part from the CD .iso: https://mattgadient.com/linux-dvd-images-and-how-to-for-32-bit-efi-macs-late-2006-models/ As I said, this results in a working OpenBSD 6.6 DVD, and according to that site, many linux distros too. I have many models of Macs at my office, I can try others, if that's likely to yield any useful information.
Created attachment 211089 [details] bootloader debug I managed to build the boot loader with DISC_DEBUG and SIO and captured the output via serial port, Attached is the serial port dump.
Created attachment 211178 [details] screen shot I got my hands on a SCSI dvd drive and gave booting the FreeBSD 12.1 and 11.3 iso's another shot. text of the 12.1 panic is "panic: zfree(0x16915340,8224): wild pointer" and the 11.3 panic resulted in a register dump, see attached .jpg. 10.4 boots to sysintall fine.
(In reply to Adam from comment #39) And 13 current?
(In reply to Toomas Soome from comment #40) 13 current 20200116-r356767 panics with a register dump similar to 11.3
so I built btxldr with BTXLDR_VERBOSE and had to resort to taking pictures of the monitor, my problem machined is passing the bootdev for CDROM's in the 0x90 range (scsi is 0x9f and ide is 0x90) while my working machine has the CDROM bootdev as 0x82. looking through the code a 'base/head/stand/i386/llibi386/biosdisk.c' it appears that 0x80 is assumed in 2 places, and in '/base/stable/10/sys/boot/i386/libi386' it looks like CDROM is handled by bioscd.c and doesn't make such assumptions. At some point after freebsd 10, biosdisk.c and bioscd.c were merged, is my guess. images are too large to attach, please forgive the mega link. https://mega.nz/#!CfRhiIiD!sU86zyBKp2AcDCk7qQBMwl-dbjTqISD2lifND7nqQXM
I haven't had a chance to try every Mac in my office, but did try 3: MacBookPro6,1 MacPro3,1 MacMini4,1 Same result as my MacPro1,1. These machines all have EFI64 though, so I guess EFI32 vs EFI64 is irrelevant. I am though using my hacked non-EFI DVD in all cases. I'll next try a non-hacked DVD on the EFI64 Macs to see if that works...
My previous hypothesis was a dead end. freebsd-head correctly sets the sector size, implying bc_add() is called bypassing the '0x80 + unit' bits. interestingly setting the SCSI ID of my SCSI CDROM from 1 to 0 has changed the behavior of booting 12.1 from the zfree panic to BTX register dump. lsdev from the loader prompt on 10.4 shows 0x5 for the SCSI CDROM and 0x0 for the IDE CDROM, but when 10.4 is installed to a SCSI hard drive, boot stalls at BTX Loader. OpenBSD 6.6 also has trouble booting with only SCSI hard drives on both of my Pentium III machines.
(In reply to Adam from comment #44) I havent had time yet to build freebsd iso, but if you do not mind to try this one (built this on to test on hp proliant system): http://148-52-235-80.sta.estpak.ee/oi.iso - it has the same loader core code, so we would know if we do have the same issue:)
Created attachment 211290 [details] lsdev
(In reply to Toomas Soome from comment #45) the iso gets me to a loader prompt and lsdev shows all my SCSI stuff detected and categorized correctly. good work.
A commit references this bug: Author: tsoome Date: Mon Feb 3 11:33:33 UTC 2020 New revision: 357442 URL: https://svnweb.freebsd.org/changeset/base/357442 Log: loader: bc_add can not use any other probes than ah=0x4b CD boot is broken for some systems since bioscd and biosdisk merge. The issue is that we can not use anything else than int 13 ah=0x4b to query cd information. The patch does restore the same probe as was originally used in bioscd.c. Additionally extra buffer padding is used to avoid memory corruption caused by some systems. PR: 234031 Reported by: ultramage and others MFC after: 1 day Changes: head/stand/i386/libi386/biosdisk.c
Toomas, I tried your oi.iso. I burnt it to DVD and booted the MacMini4,1 at my office. I _didn't_ hack it to remove the EFI part. This Mac has 64 bit EFI. When holding option key at boot (that's how to get the boot disk choice on Mac), I see two choices from that DVD: - "Windows" (which, I believe, it what it calls any old BIOS option) - "EFI boot" I tried both. I no longer see any LUA error messages! And it gets farther too, with a 'Welcome to illumos' message, and multi user / single user choice. But it still ends up failing, the output is: Loading unix... can't find 'unix' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Loading unix... can't find 'unix' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Loading /boot/defaults/loader.conf Loading unix... can't find 'unix' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Loading unix... can't find 'unix' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Loading i86pc/kernel/amd64... can't find 'i86pc/kernel/amd64' Unable to load a kernel! So I guess you definitely fixed something! But I still can't install FreeBSD. :(
(In reply to commit-hook from comment #48) OMG..... booting from SCSI or IDE cdrom/dvdrom works perfectly installing and booting to/from IDE hard drive works perfectly installing and booting to/from a SCSI hard drive with ZFS root stalls at "reducing read 458673949 from 16 to 10" and booting from a UFS MBR SCSI hard drive stalls at "boot/entropy size=0x1000" from my testing booting from SCSI hard drives on this particular machine stopped working after FreeBSD 4.11, admittedly I didn't test anything in the 5.x series. for any others that want to test, I built the amd64/i386 ISO's for this patch and they can be found at: ftp://ftp.bestgodzilla.com
Toomas, now back home, I tried your oi.iso on my old MacPro1,1, which has 32 bit EFI. If I boot from the BIOS partition it prompts me: ------------ 1. 2. Select CD-ROM Boot Type : ------------ But doesn't seem to accept any keyboard input. If I boot from the EFI partition, then it goes better! I see it output things like "i386 EFI" and "loader32.efi". So maybe you fixed bug #215143. But it ends up failing like the MacMini4,1 with "Unable to load a kernel!".
(In reply to Sean McBride from comment #49) It is perfectly ok the oi.iso not loading the kernel, because I did create that image with only /boot bits and no kernel is stored there -- this iso is not From FreeBSD but the biosdisk code is the same anyhow.
(In reply to Adam from comment #50) If you get reduced read messages from loader, it does mean we have detected some value for disk (partition) size, and refusing to read past disk/partition end. If this is not 13-current, you may want to try it as we have implemented way to use pool size to avoid reading past disk end (which can hung some systems).
A commit references this bug: Author: tsoome Date: Tue Feb 4 07:15:34 UTC 2020 New revision: 357495 URL: https://svnweb.freebsd.org/changeset/base/357495 Log: MFC r357442: loader: bc_add can not use any other probes than ah=0x4b CD boot is broken for some systems since bioscd and biosdisk merge. The issue is that we can not use anything else than int 13 ah=0x4b to query cd information. The patch does restore the same probe as was originally used in bioscd.c. Additionally extra buffer padding is used to avoid memory corruption caused by some systems. PR: 234031 Reported by: ultramage and others Changes: _U stable/12/ stable/12/stand/i386/libi386/biosdisk.c
A commit references this bug: Author: tsoome Date: Tue Feb 4 07:18:49 UTC 2020 New revision: 357496 URL: https://svnweb.freebsd.org/changeset/base/357496 Log: MFC r357442: loader: bc_add can not use any other probes than ah=0x4b CD boot is broken for some systems since bioscd and biosdisk merge. The issue is that we can not use anything else than int 13 ah=0x4b to query cd information. The patch does restore the same probe as was originally used in bioscd.c. Additionally extra buffer padding is used to avoid memory corruption caused by some systems. PR: 234031 Reported by: ultramage and others Changes: _U stable/11/ stable/11/stand/i386/libi386/biosdisk.c
(In reply to Toomas Soome from comment #53) The problem appears to be a SCSI issue, I think maybe there is some confusion caused by multi-channel cards or even multiple cards installed. Mixing and matching cards and swapping them into different PCI slots, I was able to find a working configuration.
(In reply to Toomas Soome from comment #52) Oh I see, sorry about that. So I downloaded FreeBSD-13.0-CURRENT-amd64-20200213-r357847-disc1.iso.xz and it boots successfully on my MacMini4,1. So indeed I'd say this is fixed!
Still reproduced with 12.1-RELEASE DVD. Can't install release because of LUA ERROR.
FreeBSD-12.1-STABLE-i386-20200402-r359553-bootonly.iso - boots up fine on my usb cdrom + epia-m (teenager!), now loading kernel..
This is still broken for me. I am using a 12.1-RELEASE amd64 ISO CD to install on a UEFI Dell T610 with an H700 and 24TB of RAID6 disk space. I take the defaults during the install and reboot to LUA errors. I have found that the loader can't see my MFI 16TB mfid0p2: slice. I get errors 'ls disk0p2:'. I am expecting to see the UFS file system. I created a ticket but it sounds like this ticket is the same issue as mine: loader can't read the slice which has the FreeBSD OS on it. I can read the EFI partition just fine. My ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249045
I don't think this issue is fixed. There's still configurations whereby the CD-ROM presence causes the loader to get confused. This results in the loader not being able to read the boot fixed disk. In my case, it was a 17TB RAID6 disk connected to a PERC H700. I disconnected the CD-ROM and disabled the SATA ports and then my Dell T610 was able to boot/reboot (12.1-RELEASE and various builds of 12-STABLE).