Got an error message 'cannot index nil value' at line 277 in boot/lua/drawer.lua. Tracking down the possible cause is in this function: local function getLogodef(logo) if logo == nil then return nil end -- Look it up local logodef = logodefs[logo] -- Try to pull it in if logodef == nil then try_include('logo-' .. logo) <--- this is rather (?) 'logo_' logodef = logodefs[logo] end return logodef end All the logo files are stored as 'logo_*.lua' so my guess constructing the include filename should follow that convention, i.e. not use 'logo-' but 'logo_' as prefix.
(In reply to gabor.radnai from comment #0) Hmm, we should handle missing logo/brand better, but how did you end up with logo_* files instead of logo-*? Stock FreeBSD only has the latter, and that's the only format of name we currently support.
(In reply to Kyle Evans from comment #1) Ok, it's weird bit ... I was playing with GhostBSD to enable PXE or netboot. I did not change any filename but used only files with their "as is" name from GhostBSD's install medium. When the error popped I reported first to GhostBSD but they closed the ticket being upstream problem see (1). It looks the latest GhostBSD install image (2) does use logo_* format, and FreeBSD 12.1-RELEASE iso (3) too! (1) https://github.com/ghostbsd/ghostbsd-build/issues/50 (2) http://download.us.ghostbsd.org/releases/amd64/latest/GhostBSD-20.04.1.iso (3) https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/ On an installed FreeBSD instance you are right I can indeed see logo-* files, but not on the aforementioned iso images. I guess it is due to iso9660 standard naming, so logo_* are they. Guess I was doing wrong first of all, I hoped "memdisk" type PXE boot will work out of the box but I guess it was never intended. Anyhow, thanks for checking my ticket, please close it.
(In reply to gabor.radnai from comment #2) Hmm, if I mount 12.1 image as cd9660, they do appear as logo-*.lua. Are you checking after actually writing them to a disk, or how are you checking? I'm not quite ready to close this just yet, though. We still shouldn't be raising the alarm just because of a "missing" logo -- we should just not draw the graphic in question, and maybe indicate in some more subtle way that this happened.
I mounted under Windows 10 to be honest first. Read somewhere ISO standard defines upper case letters, number digits, "_" and "." as valid filenames which is followed in Windows strangely, so shows as LOGO_*, but you are right, mounting the 12.1 image under FBSD does show logo-* files. But I think better error handling would be useful, not drawing a logo is better than end up with nil pointer.
A commit references this bug: Author: kevans Date: Mon Jun 1 23:26:37 UTC 2020 New revision: 361709 URL: https://svnweb.freebsd.org/changeset/base/361709 Log: lualoader: improve drawer error handling At least one user has landed in a scenario where logo files appear to be misnamed, and we failed to find them. Our fallback for missing logodefs is orb/orbbw, based on the color status. In a scenario where we can't locate the logos, though, this is not ideal. Add in one more layer of fallback to properly just don't draw any logo if the fan has been jam packed with foreign material. PR: 246046 MFC after: 3 days Changes: head/stand/lua/drawer.lua
Fix committed, will MFC to stable/11 and stable/12; it won't make it to 11.4 because lualoader is just a non-default preview there. Thanks for the report!
A commit references this bug: Author: kevans Date: Fri Jun 5 02:52:07 UTC 2020 New revision: 361817 URL: https://svnweb.freebsd.org/changeset/base/361817 Log: MFC r361709: lualoader: improve drawer error handling At least one user has landed in a scenario where logo files appear to be misnamed, and we failed to find them. Our fallback for missing logodefs is orb/orbbw, based on the color status. In a scenario where we can't locate the logos, though, this is not ideal. Add in one more layer of fallback to properly just don't draw any logo if the fan has been jam packed with foreign material. PR: 246046 Changes: _U stable/11/ stable/11/stand/lua/drawer.lua _U stable/12/ stable/12/stand/lua/drawer.lua
This should no longer degenerate into a failure to boot on both stable branches. Thanks for the report! I'm closing this as FIXED, but of course feel free to re-open it or comment if you feel that it's not been sufficiently addressed.