XPost: linux.debian.devel.cd

Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3.1
Severity: normal
Tags: patch

Dear Maintainer,

While debugging #1103692, I came across an issue where error messages
generated early in the syslinux boot process through writestr() didn't
end up appearing on-screen. Instead, it appeared that only the cursor
moved.

I discovered that it's because the early code passes a video attribute
of 0 to the efi_write_char() function, which is black-on-black, and
produces invisible output.

The output can actually be read on the serial line. For example, if we
have a serial line dump in the file serial.dump, and we have problems
with loading ldlinux.e32, the following can be used to read the message:

$ ansi2txt < serial.dump > serial.log
$ tail -n4 serial.log
Shell> FS0:\EFI\syslinux\syslinux.efi

Failed to load ldlinux.e32
Shell>

Detailed steps on reproducing this issue are present in #1103692,
and if the issue reported in that bug gets fixed, you can easily
trigger this error message by deleting the ldlinux.e32 file.

Another issue which might render the error message unreadable is that
the error message doesn't contain a newline marker, which might cause
the EFI shell command prompt to overwrite the message. This happens
with OVMF under Qemu.


Yet another minor issue is that the efi_scroll_up() function generates
a CRLF pair on the reverse order, LFCR, which can confuse some text
editors when viewing the logs, so it would be good to put them into
the correct order.

The efi_scroll_up() function also contains a bug where it ignores
the number of rows to scroll up by and always scrolls once, but this
seems to be intentional, as it's used to mask a different bug in
the ansicon module that causes it to scroll way more than it should
under EFI.

The ansicon module is used by ldlinux, and this masked bug can be seen
if you implement the rows parameter in efi_scroll_up() and try to boot
a kernel with the default boot prompt, the "Loading <xyz>..." messages
will be spaced apart with a ludicrous amount of spaces. Fixing this
properly is outside of the scope of this task, so for now, I think it's
okay to ignore the "rows" parameter in efi_scroll_up(), as ansicon
appears to be the only place where it's used.


Another related thing to keep in mind is that printf() and friends
don't work in this early mode. That appears to be intentional though,
and it only affects debugging messages. The printf() family tends
to be enabled through openconsole(), and this happens once the ldlinux
module is loaded, but in the bare syslinux.efi environment, the function
is not present (trying to use it gives an undefined symbol error),
though its behavior can thankfully be recreated pretty easily by just
adding the following lines somewhere before you start using debugging statements with the printf() family of functions:

close(1);
close(2);
opendev(&dev_null_r, &dev_stdcon_w, O_WRONLY);
opendev(&dev_null_r, &dev_stdcon_w, O_WRONLY);


I'm attaching a patch that updates the writechr() implementation
for EFI by including a default color attribute of light gray on black,
which matches what the BIOS implementation of writechr() does.

The patch additionally also updates efi_write_char() to not change
the color attribute unconditionally whenever a character is written,
and fixes the CR LF order in efi_scroll_up().

A newline character is also added at the end of the ldlinux loading
error message. This newline is added in efi_main() and not
in load_env32() to be consistent with how it's implemented under BIOS.
The load_env32() function is shared between EFI and BIOS, and under
BIOS, the newline is also added as part of the following error message
which tells the user that boot failed, e.g. the err_bootfailed string
in core/diskfs.inc.


Only the writechr() update and newline addition is strictly neccessary
to fix the bug this bug report is about, but the other updates make
the screen output process more efficient and improve the usability
of the generated logs with text editors.


With this patch, the error message about ldlinux is dispalyed correctly, informing the user about a potentially misconfigured setup, e.g.
with the ldlinux.e32 / ldlinux.e64 file not being present.


Best Regards,
Marek


-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.14.3 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3.1

Versions of packages syslinux-efi suggests:
ii dosfstools 4.2-1.2

-- no debconf information

LS0tIHN5c2xpbnV4LTYuMDR+Z2l0MjAxOTAyMDYuYmY2ZGI1YjQrZGZzZzEub3JpZy9lZmkvY29u c29sZS5jDQorKysgc3lzbGludXgtNi4wNH5naXQyMDE5MDIwNi5iZjZkYjViNCtkZnNnMS9lZmkv Y29uc29sZS5jDQpAQCAtMzQsNyArMzQsNyBAQCB2b2lkIGVmaV9jb25zb2xlX3Jlc3RvcmUodm9p ZCkNCiANCiBfX2V4cG9ydCB2b2lkIHdyaXRlY2hyKGNoYXIgZGF0YSkNCiB7DQotCWVmaV93cml0 ZV9jaGFyKGRhdGEsIDApOw0KKwllZmlfd3JpdGVfY2hhcihkYXRhLCBFRklfQkFDS0dST1VORF9C TEFDSyB8IEVGSV9MSUdIVEdSQVkpOw0KIH0NCiANCiBzdGF0aWMgaW5saW5lIEVGSV9TVEFUVVMg b3Blbl9wcm90b2NvbChFRklfSEFORExFIGhhbmRsZSwgRUZJX0dVSUQgKnByb3RvY29sLA0KLS0t IHN5c2xpbnV4LTYuMDR+Z2l0MjAxOTAyMDYuYmY2ZGI1YjQrZGZzZzEub3JpZy9lZmkvbWFpbi5j DQorKysgc3lzbGludXgtNi4wNH5naXQyMDE5MDIwNi5iZjZkYjViNCtkZnNnMS9lZmkvbWFpbi5j DQpAQCAtMjU1LDcgKzI1NSwxMCBAQCB2b2lkIGVmaV93cml0ZV9jaGFyKHVpbnQ4X3QgY2gsIHVp bnQ4X3QNCiAJU0lNUExFX1RFWFRfT1VUUFVUX0lOVEVSRkFDRSAqb3V0ID0gU1QtPkNvbk91dDsN CiAJdWludDE2X3QgY1syXTsNCiANCi0JdWVmaV9jYWxsX3dyYXBwZXIob3V0LT5TZXRBdHRyaWJ1 dGUsIDIsIG91dCwgYXR0cmlidXRlKTsNCisJaWYgKFNULT5Db25PdXQtPk1vZGUtPkF0dHJpYnV0 ZSAhPSBhdHRyaWJ1dGUpDQorCXsNCisJCXVlZmlfY2FsbF93cmFwcGVyKG91dC0+U2V0QXR0cmli dXRlLCAyLCBvdXQsIGF0dHJpYnV0ZSk7DQorCX0NCiANCiAJLyogTG9va3VwIHByaW1hcnkgVW5p Y29kZSBlbmNvZGluZyBpbiB0aGUgc3lzdGVtIGNvZGVwYWdlICovDQogCWNbMF0gPSBjb2RlcGFn ZS51bmlbMF1bY2hdOw0KQEAgLTI4MSw4ICsyODQsOCBAQCBzdGF0aWMgdm9pZCBlZmlfc2V0X2N1 cnNvcihpbnQgeCwgaW50IHksDQogDQogc3RhdGljIHZvaWQgZWZpX3Njcm9sbF91cCh1aW50OF90 IGNvbHMsIHVpbnQ4X3Qgcm93cywgdWludDhfdCBhdHRyaWJ1dGUpDQogew0KLQllZmlfd3JpdGVf Y2hhcignXG4nLCAwKTsNCi0JZWZpX3dyaXRlX2NoYXIoJ1xyJywgMCk7DQorCWVmaV93cml0ZV9j aGFyKCdccicsIGF0dHJpYnV0ZSk7DQorCWVmaV93cml0ZV9jaGFyKCdcbicsIGF0dHJpYnV0ZSk7 DQogfQ0KIA0KIHN0YXRpYyB2b2lkIGVmaV9nZXRfbW9kZShpbnQgKmNvbHMsIGludCAqcm93cykN CkBAIC0xMzg0LDcgKzEzODcsMTAgQEAgRUZJX1NUQVRVUyBlZmlfbWFpbihFRklfSEFORExFIGlt YWdlLCBFRg0KIAl9IHdoaWxlIChzdGF0dXMgPT0gRUZJX1NVQ0NFU1MpOw0KIA0KIAlpZiAoIXNl dGptcChsb2FkX2Vycm9yX2J1ZikpDQorCXsNCiAJCWxvYWRfZW52MzIoTlVMTCk7DQorCQl3cml0 ZXN0cigiXHJcbiIpOw0KKwl9DQogDQogCS8qIGxvYWRfZW52MzIoKSBmYWlsZWQuLiBjYW5jZWwg dGltZXIgYW5kIGJhaWxvdXQgKi8NCiAJc3RhdHVzID0gY2FuY2VsX3RpbWVyKHRpbWVyX2V2KTsN Cg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.cd

Hello,

FIY, I've forwarded the patch to upstream: https://www.syslinux.org/archives/2025-April/026928.html


Best Regards,
Marek

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)