Bug #16041
openInstaller freeze while booting, saying "hash mismatch!"
0%
Description
on MBR and UEFI
after saying : Booting...
it says : hash mismatch!
then it freezes.
There was a similar issue on freebsd, the problem was that the motherboard is supposed to reply 0x20 to confirm it is a PC, but many ASROCK replies 0x00.
We should install anyway.
Updated by Toomas Soome 21 days ago
yomgui oim wrote:
on MBR and UEFI
after saying : Booting...
it says : hash mismatch!
then it freezes.There was a similar issue on freebsd, the problem was that the motherboard is supposed to reply 0x20 to confirm it is a PC, but many ASROCK replies 0x00.
We should install anyway.
HASH mismatch is explained by Rich; however, there is a bit more background.
To start illumos, we read into memory the kernel, boot_archive and if exist, the boot_archive.hash. the hash itself is computed with sha1 algorithm, and the purpose is to provide an mechanism to validate the contents of boot_archive.
This content can get corrupted when something unexpectedly does write to memory used by boot_archive or if the memory itself is bad and bits do change after boot_archive was written. Note, the boot media issues are usually detected earlier, because our boot_archive is usually stored compressed on boot media and is uncompressed while it is read into the memory - so the media (read) errors would cause decompression errors.
You can test the loaded files yourself; if you press ESC while boot menu is there, you get to boot loader OK prompt, there you can enter: start
This will cause kernel and configured modules to be read into the memory, now, you can enter: lsmod -s
lsmod -s will show you loaded items with computed hash and the contents of boot_archive.hash if it was loaded. So you can compare that contents with calculated hash.
However, with UEFI system, even if the initial load was ok, on boot, the kernel and loaded modules are relocated and the corruption can take place during or after such relocation. On kernel startup, the early kernel does check the boot_archive hash and will stop the kernel in case of hash mismatch. This can be observed if you use this boot command: boot -B prom_debug=true
Now, you can attempt to disable loading boot_archive.hash and hope the corruption is in unused part of the archive, to do this, you can use those commands:
ok unload ok disable-module boot_archive.hash ok show-module-options
And then enter: boot
However, getting boot_archive corruption is obviously bad and the attempt to boot with it will probably end up with some sort of unexpected results...