Control: tags 1040467 upstream fr...@gmail.com wrote...
> UEFI systems make the boot logo accessible for reading at the path
> /sys/firmware/acpi/bgrt/image
>
> The file can be displayed directly using for example:
> $ feh /sys/firmware/acpi/bgrt/image
>
> Strange things happen when you copy this file elsewhere:
> $ cp /sys/firmware/acpi/bgrt/image /tmp/image
>
> and then run `file` on it:
> $ file /sys/firmware/acpi/bgrt/image /tmp/image
> /sys/firmware/acpi/bgrt/image: data
> /tmp/image: PC bitmap, Windows 3.x format, 434 x 432 x 24,
> image size 565056, cbSize 565110, bits offset 54
While that particular sysfs file does not exist on my system, there's
already enough clue to get an idea what is happening here, and you
already almost got it:
(...)
> If you then diff those logfiles, you can notice that that
> /tmp/sys-firmware-acpi-bgrt-image.log only uses nbytes=4096, whereas
> /tmp/tmp-image.log uses nbytes=565110.
This difference comes from the read() syscall file/libmagic does to get
the file content: When reading a file in /sys/, that call only reads
4096 bytes and returns an according result. However, some bits used to
identify the file are likely beyond that limit. To confirm, try file on
the first 4096 bytes only, this should again result in "data", or:
$ dd if=/tmp/image bs=4096 count=1 | file -
data
As a workaround, you could again use file(1) in a pipe, i.e.
$ </sys/firmware/acpi/bgrt/image file -
PC bitmap, Windows 3.x format, (...)
Feel free to confirm both.
This is (mostly) Linux-specific, still I'll take this to upstream.
Thanks for reporting.
Christoph
signature.asc
Description: PGP signature
