Error unknown command hwmatch

Question

I'm getting "unknown command hwmatch" message on each boot after I installed Ubuntu 16.04 following this steps: https://gist.github.com/umpirsky/6ee1f870e759815333c8 in order to setup RAID0.

Special attention to apt-get install -y grub-efi-amd64 part https://gist.github.com/umpirsky/6ee1f870e759815333c8#file-ubuntu-raid-sh-L40

For some reason I couldn't use apt-get, so I installed it manually downloading deb and using dpkg -i.

There is a bug report related with this error https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/733836.

System boots normally, but I would like to fix this error. Is there any way to update config and fix it?

UPDATE: After one month of using the system, one day it just failed to boot with this error, ending up in initramfs prompt, I restored it from clonezilla backup, but I'm afraid it can happen again. The worst thing is, I don't know why it happened.

UPDATE:

It happened again, and again, often after force shutdown or running out of batterx. I booted live USB and run fsck:

sudo fsck /dev/sda1
fsck from util-linux 2.20.1
fsck.fat 3.0.26 (2014-03-07)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 2
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action

Looks like some data are left inconsistent when laptop runs out of battery or force shutdown.

Also:

sudo fsck /dev/md0
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/md0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

But e2fsck does not fix it:

sudo e2fsck -b 8193 /dev/md0
e2fsck 1.42.9 (4-Feb-2014)
e2fsck: Bad magic number in super-block while trying to open /dev/md0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Thanks.

Note from comments: I cannot reproduce this since restoring from a Clonezilla backup.

Solution 1

Dealing strictly with the hwmatch problem look into /etc/grub.d/10_linux and you will find it listed something like this near the bottom (9th line down on this display):

# Use ELILO's generic "efifb" when it's known to be available.
# FIXME: We need an interface to select vesafb in case efifb can't be used.
if [ "x$GRUB_GFXPAYLOAD_LINUX" != x ] || [ "$gfxpayload_dynamic" = 0 ]; then
  echo "set linux_gfx_mode=$GRUB_GFXPAYLOAD_LINUX"
else
  cat << EOF
if [ "\${recordfail}" != 1 ]; then
  if [ -e \${prefix}/gfxblacklist.txt ]; then
    if hwmatch \${prefix}/gfxblacklist.txt 3; then
      if [ \${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
EOF
fi

For whatever reason your grub installation is incomplete and missing hwmatch module. You should see it among many other files when you use ll /boot/grub/i386-pc:

-rw-r--r-- 1 root root  47292 Dec  5 07:13 hwmatch.mod
-rw-r--r-- 1 root root   2928 Dec  5 07:13 iorw.mod
-rw-r--r-- 1 root root   8656 Dec  5 07:13 iso9660.mod
-rw-r--r-- 1 root root   6168 Dec  5 07:13 jfs.mod
-rw-r--r-- 1 root root   6280 Dec  5 07:13 jpeg.mod
-rw-r--r-- 1 root root   5112 Dec  5 07:13 keylayouts.mod
-rw-r--r-- 1 root root   2044 Dec  5 07:13 keystatus.mod
-rw-r--r-- 1 root root   6608 Dec  5 07:13 ldm.mod
-rw-r--r-- 1 root root  29816 Dec  5 07:13 legacycfg.mod
-rw-r--r-- 1 root root  14536 Dec  5 07:13 legacy_password_test.mod
-rw-r--r-- 1 root root   8048 Dec  5 07:13 linux16.mod
-rw-r--r-- 1 root root  13184 Dec  5 07:13 linux.mod
-rw-r--r-- 1 root root    100 Dec  5 07:13 load.cfg
-rw-r--r-- 1 root root   5924 Dec  5 07:13 loadenv.mod
-rw-r--r-- 1 root root   3056 Dec  5 07:13 loopback.mod
-rw-r--r-- 1 root root   4872 Dec  5 07:13 lsacpi.mod
-rw-r--r-- 1 root root   2352 Dec  5 07:13 lsapm.mod
-rw-r--r-- 1 root root   1884 Dec  5 07:13 lsmmap.mod
-rw-r--r-- 1 root root   4136 Dec  5 07:13 ls.mod
-rw-r--r-- 1 root root   4928 Dec  5 07:13 lspci.mod
-rw-r--r-- 1 root root   6724 Dec  5 07:13 luks.mod
-rw-r--r-- 1 root root   6776 Dec  5 07:13 lvm.mod

As per this bug report (bugs.launchpad.net - Ubuntu Upgrade from Lucid to Precise results in broken grub configuration) the easiest way of getting all the grub modules is to reinstall it.

You should run sudo dpkg-reconfigure grub-pc and instruct it to install the boot loader somewhere, probably /dev/vda.

Above is a direct quote from the bug report. As a comment here points out and looking at your link, this should be used instead:

sudo dpkg-reconfigure grub-efi-amd64

However looking at this post (superuser.com - How to reinstall grub2 efi) you must first boot with a live USB/DVD and use:

sudo mount /dev/sda2 /mnt #sda2 is the root partition
sudo mount /dev/sda1 /mnt/boot/efi #sda1 is the efi partition
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/ #makes the network available after chrooting
modprobe efivars # make sure this is loaded
sudo chroot /mnt

The first step is to confirm that the file hwmatch is really missing. If so the easiest method is to simply copy it from:

/usr/lib/grub/i386-pc/hwmatch.mod

into the directory:

/boot/efi/efi/grub

This directory name comes from (https://help.ubuntu.com/community/UEFIBooting) where they say that is "mostly" the directory name. Please confirm for your installation.

The more complicated methods of dpkg-reconfigure should be approached with extreme caution and only after appropriate backups.

Solution 2

Did you try to use a different copy of your superblock (I think that 8193 and 32768 are examaples):

mke2fs -n /dev/XYZ 
...
Superblock-Sicherungskopien gespeichert in den Blöcken:
          32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, ...

Choose one copy of the superblock, e.g. the third one: In this case 163840 and do:

e2fsck -p -b 163840 /dev/XYZ

Solution 3

For a Legacy boot, There's no reason you can't simply copy the spare file to the appropriate location as in sudo cp /usr/lib/grub/i386-pc/hwmatch.mod /boot/grub/i386-pc/hwmatch.mod

As my tests indicate that they are identical:

$ diff -s /usr/lib/grub/i386-pc/hwmatch.mod /boot/grub/i386-pc/hwmatch.mod 
Files /usr/lib/grub/i386-pc/hwmatch.mod and /boot/grub/i386-pc/hwmatch.mod are identical

For EFI mode:

I've checked a fresh install of 16.04 in EFI mode and hwmatch.mod doesn't exist so i would assume it can be safely ignored. If it annoys you I would suggest backing up your current grub.cfg, searching your grub.cfg for the insmod hwmatch line that's causing the issue and commenting it out to see if that alleviates the problem.

Comments

[doug]

Try sudo dpkg-reconfigure grub-efi-amd64 , don't do the force question if prompted (default is no

[Elder Geek]

VTC as "I restored previous clonezilla backup, so I cannot reproduce. :( – umpirsky 42 mins ago "

[umpirsky]

No, it does not happen after I restored clonzilla backup, that's why I cannot reproduce it.

[Elder Geek]

@umpirsky Thank you for the confirmation! Please open new questions for the new issues. (For the file not found error I recommend including a copy of your grub.cfg in the question.) Thank you for helping us help you!

[umpirsky]

Yes, I did, it's listed in the question. Thanks.

[umpirsky]

/dev/vda? You mean /dev/sda? Please see how I installed it on gist.github.com/umpirsky/…

[WinEunuuchs2Unix]

The /dev/vda is a direct quote from the bug report. It changes depending on installation. I've seen your link on other websites where you posted the same question. I couldn't repeat the steps so quickly looked at it then. I'll take a second look though.

[musbach]

Sorry, my point was that you said that you used the block 8193. I doubt that 8193 is a valid superblock in your case. 8193 is just an example. You have to obtain the real superblock values from mke2fs which is not in your question. Without the real superblock values, e2fsck won’t work. Could you please post the output of mke2fs -n /dev/XYZ?

[Elder Geek]

You can easily confirm whether hwmatch.mod is missing with the command locate hwmatch or better yet, sudo find /. -iname hwmatch* you may even find that you have a spare copy in /usr/lib/grub/i386-pc

[umpirsky]

@ElderGeek It's not missing locate hwmatch /usr/lib/grub/i386-pc/hwmatch.mod

[umpirsky]

They are not example, they are valid superblocks, I get same superblocks from mke2fs, this 2 and then several more. None of them worked.

[umpirsky]

@WinEunuuchs2Unix I would like to try to simply copy hwmatch. As you can see from my previous comment, it's in /usr/lib/grub/i386-pc/hwmatch.mod. Where should I copy it to?

[musbach]

Could you please post the output of blkid and mke2fs -n /dev/XYZ?

[Elder Geek]

@umpirsky See my answer

[WinEunuuchs2Unix]

@umpirsky I updated my answer with the target directory name, unfortunately different than Elder Geek's.

[umpirsky]

@WinEunuuchs2Unix Thanks, but in my case /boot/efi/efi/grub does not exists, there is only /boot/efi/efi/ubuntu, there is grubx64.efi in it, should I copy it there?

[umpirsky]

I don't have /boot/grub/i386-pc, I have /boot/grub/x86_64-efi, should I copy it there? Thanks.

[WinEunuuchs2Unix]

@umpirsky All I have to go on is the link posted in the answer I found yesterday. I'm sorry to say I'm not using UEFI boot so can't duplicate your problem nor verify if copying file there will fix it. I can't see it hurting.

[umpirsky]

I restored previous clonezilla backup, so I cannot reproduce. :(

[umpirsky]

@WinEunuuchs2Unix In deed, I'll try, thanks.

[musbach]

Please let me know, if it appears next time.

[Elder Geek]

Updated answer.

[umpirsky]

Strange. Should I replace hwmatch line with true or false. linux_gfx_mode value depends on it. gist.github.com/umpirsky/c6520c039a8d1e94df3a677410f1dd2e

[umpirsky]

Copying it to /boot/efi/efi/ubuntu didn't prevent the error.

[umpirsky]

Please see my updated question, hwmatch error vanished, but there are others.

[WinEunuuchs2Unix]

Sorry to hear that. I'll dig a little deeper into other websites.

[Elder Geek]

@umpirsky the choices appear to be set linux_gfx_mode=keep and set linux_gfx_mode=text If I were you I'd try them both and keep the one that provided my desired result, but honestly this question has strayed too far from the original to be of use to others and we try to be efficient by disallowing that behaviour. Adding pertinent info to existing questions is helpful to obtain answers, but at this point, you have a new issue unrelated to your original post. By creating a new question you can help us not only help you but any others with the same issue as well. Thank you!