I'm getting "unknown command hwmatch" message on each boot after I installed Ubuntu 16.04 following this steps: in order to setup RAID0.

Special attention to apt-get install -y grub-efi-amd64 part

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 .

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.

4

3 Answers

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

12

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

6

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.

5