src/stand/forth, branch upstream/13.1.0

loader.4th(8): Fix a typo in the manual page

2022-04-15T13:25:48Z

- s/commmand/command/ Approved by: re@ (gjb) (cherry picked from commit ad49d7c54cca4906179369e2196c1edbcf509342)

loader: support.4th resets the read buffer incorrectly

2021-09-12T15:56:15Z

Large nextboot.conf files (over 80 bytes) are not read correctly by the Forth loader, causing file parsing to abort, and nextboot configuration fails to apply. Simple repro: nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx shutdown -r now That will cause the bug to cause a parse failure but shouldn't otherwise affect the boot. Depending on your loader configuration, you may also have to set beastie_disable and/or reduce the number of modules loaded to see the error on a small console screen. 12.0 or CURRENT users will also have to explicitly use the Forth loader instead of the Lua loader. The error will look something like: Warning: syntax error on file /boot/loader.conf.local foo="xxxxxxxxxxxxxxnextboot_enable="YES" ^ /boot/support.4th has crude file I/O buffering, which uses a buffer 'read_buffer', defined to be 80 bytes by the 'read_buffer_size' constant. The loader first tastes nextboot.conf, reading and parsing the first line in it for nextboot_enable="YES". If this is true, then it reopens the file and parses it like other loader .conf files. Unfortunately, the file I/O buffering code does not fully reset the buffer state in the reset_line_reading word. If the last file was read to the end, that doesn't matter; the file buffer is treated as empty anyway. But in the nextboot.conf case, the loader will not read to the end of file if it is over 80 bytes, and the file buffer may be reused when reading the next file. When the file is reread, the corrupt text may cause file parsing to abort on bad syntax (if the corrupt line has <>2 quotes in it), the wrong variable to be set, no variable to be set at all, or (if the splice happens to land at a line ending) something approximating normal operation. The bug is very old, dating back to at least 2000 if not before, and is still present in 12.0 and CURRENT r345863 (though it is now hidden by the Lua loader by default). Suggested one-line attached. This does change the behavior of the reset_line_reading word, which is exported in the line-reading dictionary (though the export is not documented in loader man pages). But repo history shows it was probably exported for the PNP support code, which was never included in the loader build, and was removed 5 months ago. One thing that puzzles me: how has this bug gone unnoticed/unfixed for nearly 2 decades? I find it hard to believe that nobody's tried to do something interesting with nextboot, like load a kernel and filesystem, which is what I'm doing. Tested by: Gary Jennejohn PR: 239315 MFC After: 3 weeks Reviewed by: imp (and correctly applied this time) Differential Revision: https://reviews.freebsd.org/D31328 (cherry picked from commit dbdf2b52f59df7374eb1f799b4df1b54e4502e40)

Revert "loader: support.4th resets the read buffer incorrectly"

2021-07-27T02:37:40Z

This reverts commit 9c1c02093b90ae49745a174eb26ea85dd1990eec. It seems to have broken all old nextboot.conf files causing hangs on boot. PR: 239315 (cherry picked from commit 4783fb730fa1cfdbe5c905bb23ac74f681e2df6b)

loader: support.4th resets the read buffer incorrectly

2021-07-16T18:28:44Z

Large nextboot.conf files (over 80 bytes) are not read correctly by the Forth loader, causing file parsing to abort, and nextboot configuration fails to apply. Simple repro: nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx shutdown -r now That will cause the bug to cause a parse failure but shouldn't otherwise affect the boot. Depending on your loader configuration, you may also have to set beastie_disable and/or reduce the number of modules loaded to see the error on a small console screen. 12.0 or CURRENT users will also have to explicitly use the Forth loader instead of the Lua loader. The error will look something like: Warning: syntax error on file /boot/loader.conf.local foo="xxxxxxxxxxxxxxnextboot_enable="YES" ^ /boot/support.4th has crude file I/O buffering, which uses a buffer 'read_buffer', defined to be 80 bytes by the 'read_buffer_size' constant. The loader first tastes nextboot.conf, reading and parsing the first line in it for nextboot_enable="YES". If this is true, then it reopens the file and parses it like other loader .conf files. Unfortunately, the file I/O buffering code does not fully reset the buffer state in the reset_line_reading word. If the last file was read to the end, that doesn't matter; the file buffer is treated as empty anyway. But in the nextboot.conf case, the loader will not read to the end of file if it is over 80 bytes, and the file buffer may be reused when reading the next file. When the file is reread, the corrupt text may cause file parsing to abort on bad syntax (if the corrupt line has <>2 quotes in it), the wrong variable to be set, no variable to be set at all, or (if the splice happens to land at a line ending) something approximating normal operation. The bug is very old, dating back to at least 2000 if not before, and is still present in 12.0 and CURRENT r345863 (though it is now hidden by the Lua loader by default). Suggested one-line attached. This does change the behavior of the reset_line_reading word, which is exported in the line-reading dictionary (though the export is not documented in loader man pages). But repo history shows it was probably exported for the PNP support code, which was never included in the loader build, and was removed 5 months ago. One thing that puzzles me: how has this bug gone unnoticed/unfixed for nearly 2 decades? I find it hard to believe that nobody's tried to do something interesting with nextboot, like load a kernel and filesystem, which is what I'm doing. PR: 239315 Reviewed by: imp (cherry picked from commit 9c1c02093b90ae49745a174eb26ea85dd1990eec)

loader: do not output empty menu title

2021-04-28T09:35:54Z

As we output spaces around the menu title, we should also check, if the title is actually empty string. PR: 255299 Submitted by: Jose Luis Duran Reported by: Jose Luis Duran (cherry picked from 4ba91fa0736bb0672d475b6b56d9e7b06e78ff69)

loader: insert spaces around menu title

2021-04-03T23:03:33Z

Small visual nit, make menu title more clean (cherry picked from 62ffcaab8f3ccba6053d4a5622c5ef2de9f636b5)

loader_4th: brand image is aligned right

2021-03-06T09:06:51Z

With screen border removed, I forgot to update forth brand image coordinates to avoid image alignment. (cherry picked from commit 6a3095aa6d0350dda89bac66d26f22a01e2257c4)

loader: implement framebuffer console

2021-01-02T19:41:36Z

Draw console on efi. Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list, vbe set xxx). autoload font (/boot/fonts) based on resolution and font size. Add command loadfont (set font by file) and variable screen.font (set font by size). Pass loaded font to kernel. Export variables: screen.height screen.width screen.depth Add gfx primitives to draw the screen and put png image on the screen. Rework menu draw to iterate list of consoles to enamble device specific output. Probably something else I forgot... Relnotes: yes Differential Revision: https://reviews.freebsd.org/D27420

Fix a few mandoc issues

2020-10-09T15:14:19Z

- whitespace at end of input line - skipping paragraph macro: Pp at the end of Sh - new sentence, new line - consider using OS macro: Fx - AUTHORS section without An macro - skipping paragraph macro: Pp before Ss

loader: zfs should support bootonce an nextboot

2020-09-21T09:01:10Z

bootonce feature is temporary, one time boot, activated by "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag. By default, the bootonce setting is reset on attempt to boot and the next boot will use previously active BE. By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will be set permanently active. bootonce dataset name is recorded in boot pool labels, bootenv area. in case of nextboot, the nextboot_enable boolean variable is recorded in freebsd:nvstore nvlist, also stored in boot pool label bootenv area. On boot, the loader will process /boot/nextboot.conf if nextboot_enable is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf processing on next boot. bootonce and nextboot features are usable in both UEFI and BIOS boot. To use bootonce/nextboot features, the boot loader needs to be updated on disk; if loader.efi is stored on ESP, then ESP needs to be updated and for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated (gpart or other tools). At this time, only lua loader is updated. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25512