Bug 234031

Summary: loader can't traverse filesystem, LUA ERROR: cannot open /boot/lua/loader.lua
Product: Base System Reporter: ultramage <umage>
Component: kernAssignee: freebsd-bugs mailing list <bugs>
Status: Closed FIXED    
Severity: Affects Some People CC: adamrosas1972, chrissyspill, dpolyg, erik5, fbsdbugs4, garga, jgibbons, kevans, mvoorhis, rodrigo.freebsd, ruslan.yakauleu, sean, tsoome, vollbluthengst, yani
Priority: --- Keywords: needs-qa
Version: 12.0-RELEASE   
Hardware: amd64   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233098
Attachments:
Description Flags
bootloader debug
none
screen shot
none
lsdev none

Description ultramage 2018-12-15 03:41:45 UTC
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
Comment 1 Rodrigo N. Hernandez freebsd_triage 2018-12-15 07:27:18 UTC
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."
Comment 2 Kyle Evans freebsd_committer 2018-12-15 14:42:26 UTC
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.
Comment 3 ultramage 2018-12-15 14:48:19 UTC
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
Comment 4 former_user 2018-12-17 17:07:36 UTC
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.
Comment 5 Toomas Soome freebsd_committer 2018-12-17 19:40:48 UTC
(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
Comment 6 former_user 2018-12-17 20:11:30 UTC
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.
Comment 7 Toomas Soome freebsd_committer 2018-12-17 21:30:19 UTC
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:)
Comment 8 yani 2019-01-03 22:58:00 UTC
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
Comment 9 Toomas Soome freebsd_committer 2019-01-05 14:24:15 UTC
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.
Comment 10 ultramage 2019-01-05 16:07:48 UTC
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.
Comment 11 Toomas Soome freebsd_committer 2019-01-05 19:53:44 UTC
(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.
Comment 12 ultramage 2019-01-06 07:15:15 UTC
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.
Comment 13 Toomas Soome freebsd_committer 2019-01-06 07:24:13 UTC
(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.
Comment 14 Rodrigo N. Hernandez freebsd_triage 2019-01-07 02:41:25 UTC
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).
Comment 15 Rodrigo N. Hernandez freebsd_triage 2019-01-07 15:07:12 UTC
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!
Comment 16 ultramage 2019-01-07 17:25:52 UTC
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.
Comment 17 Toomas Soome freebsd_committer 2019-01-07 18:02:31 UTC
(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.
Comment 18 Kyle Evans freebsd_committer 2019-01-07 18:05:03 UTC
(In reply to Toomas Soome from comment #17)

This would be worthy of an EN, yeah?
Comment 19 Toomas Soome freebsd_committer 2019-01-07 18:20:49 UTC
(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.
Comment 20 ultramage 2019-02-11 08:10:11 UTC
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.
Comment 21 Toomas Soome freebsd_committer 2019-02-11 08:17:19 UTC
(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.
Comment 22 ultramage 2019-02-11 22:45:04 UTC
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.
Comment 23 Jeff Gibbons 2019-02-15 19:02:31 UTC
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.
Comment 24 Trev 2019-04-16 10:10:57 UTC
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).
Comment 25 Denis Polygalov 2019-08-10 11:57:57 UTC
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
Comment 26 Denis Polygalov 2019-08-16 11:19:02 UTC
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.
Comment 27 Toomas Soome freebsd_committer 2019-12-13 17:52:44 UTC
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.
Comment 28 Sean McBride 2020-01-23 17:05:25 UTC
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
Comment 29 Toomas Soome freebsd_committer 2020-01-23 17:12:07 UTC
(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).
Comment 30 Sean McBride 2020-01-25 03:53:21 UTC
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.)
Comment 31 Adam 2020-01-25 04:54:35 UTC
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.
Comment 32 Adam 2020-01-25 06:14:32 UTC
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?
Comment 33 Toomas Soome freebsd_committer 2020-01-25 07:23:37 UTC
(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.
Comment 34 Adam 2020-01-25 17:08:39 UTC
(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.
Comment 35 Sean McBride 2020-01-25 20:41:32 UTC
Toomas, pardon my ignorance, but what is "MBP"?  Did you mean "MBR"?
Comment 36 Toomas Soome freebsd_committer 2020-01-25 20:43:06 UTC
(In reply to Sean McBride from comment #35)
Oops, my bad, I meant MacPro which is referred above.
Comment 37 Sean McBride 2020-01-25 21:07:51 UTC
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.
Comment 38 Adam 2020-01-26 23:57:15 UTC
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.
Comment 39 Adam 2020-01-29 21:02:19 UTC
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.
Comment 40 Toomas Soome freebsd_committer 2020-01-29 21:03:43 UTC
(In reply to Adam from comment #39)

And 13 current?
Comment 41 Adam 2020-01-29 21:24:57 UTC
(In reply to Toomas Soome from comment #40)
13 current 20200116-r356767 panics with a register dump similar to 11.3
Comment 42 Adam 2020-02-01 19:49:53 UTC
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
Comment 43 Sean McBride 2020-02-02 00:10:28 UTC
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...
Comment 44 Adam 2020-02-02 01:15:44 UTC
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.
Comment 45 Toomas Soome freebsd_committer 2020-02-02 17:18:18 UTC
(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:)
Comment 46 Adam 2020-02-02 18:43:22 UTC
Created attachment 211290 [details]
lsdev
Comment 47 Adam 2020-02-02 18:46:16 UTC
(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.
Comment 48 commit-hook freebsd_committer 2020-02-03 11:34:25 UTC
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
Comment 49 Sean McBride 2020-02-03 23:12:51 UTC
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. :(
Comment 50 Adam 2020-02-04 03:52:05 UTC
(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
Comment 51 Sean McBride 2020-02-04 04:11:24 UTC
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!".
Comment 52 Toomas Soome freebsd_committer 2020-02-04 06:54:03 UTC
(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.
Comment 53 Toomas Soome freebsd_committer 2020-02-04 07:03:21 UTC
(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).
Comment 54 commit-hook freebsd_committer 2020-02-04 07:15:38 UTC
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
Comment 55 commit-hook freebsd_committer 2020-02-04 07:19:42 UTC
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
Comment 56 Adam 2020-02-05 06:35:19 UTC
(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.
Comment 57 Sean McBride 2020-02-14 01:54:12 UTC
(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!
Comment 58 Ruslan Yakauleu 2020-03-25 16:20:31 UTC
Still reproduced with 12.1-RELEASE DVD. Can't install release because of LUA ERROR.