I tried reading the contents of a BIOS EEPROM Chip saved in a file called dump.bin. I also tried opening a file called coreboot.rom containing a Coreboot image. In both cases this error occurred:
I used Bless Hexeditor to open the file, but I only got these ASCII squares with four numbers in it, describing which ASCII value the characters have.
Most of them are 0046-squares, which equivalents to letter "F
".
This goes well with what I already know about the contents of dump.bin.
How can I make Bless Hexeditor show me the real byte values as integers/characters? I didn't find any resource regarding this topic. I tried reinstalling Bless with Synaptic package manager, but it didn't help.
I use Ubuntu 20.04.2 LTS, Xubuntu flavor. I use xfce4 desktop but I also have some GNOME stuff installed.
ls /usr/bin/*session
returns
/usr/bin/dbus-run-session
/usr/bin/gnome-session-custom-session
/usr/bin/gnome-session
/usr/bin/xfce4-session
Edit:
When I run bless
in terminal, I get the following errors before bless
starts:
Could not find a part of the path '/home/user/.config/bless/plugins'.
Could not find a part of the path '/home/user/.config/bless/plugins'.
Could not find file "/home/user/.config/bless/export_patterns"
When searching for these errors, I found this thread saying that the errors don't actually mean sth.
Edit2: I found that GHex
works just fine, so I'll probably stick with that. It's weird though that a friend of mine using Bless with Ubuntu 20.04 doesn't have this problem.
Converting my comment and
@user.dz
's comment to an answer as requested.As per this bug report, the issue is caused because the latest version of an upstream library (pango) deprecated the use of certain fonts, causing breaking changes to older programs which used these fonts. This mainly affects users on Ubuntu 20.04, which uses the upgraded pango libraries and the 0.6.0 bless version.
The bug has been fixed in the latest bless releases on github.