Ubuntu: Error unknown command hwmatch [closed]



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.


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »