Project

General

Profile

Actions

Bug #16041

open

Installer freeze while booting, saying "hash mismatch!"

Added by yomgui oim 22 days ago. Updated 21 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
bootloader
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

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.

Actions #1

Updated by Rich Lowe 21 days ago

Which installer? (which distribution is this?)

The hash mismatch error means that the boot archive we loaded doesn't match the hash given. Often (but not always) that's bad install media for some reason or other. A different USB key (or whatever) may work.

Actions #2

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...

Actions

Also available in: Atom PDF