web-dev-qa-db-ja.com

エラー不明なコマンドhwmatch

次の手順に従ってUbuntu 16.04をインストールした後、各ブートで「unknown command hwmatch」メッセージが表示されます。 https://Gist.github.com/umpirsky/6ee1f870e759815333c8 RAID0をセットアップ.

apt-get install -y grub-efi-AMD64部分への特別な注意 https://Gist.github.com/umpirsky/6ee1f870e759815333c8#file-ubuntu-raid-sh-L4

何らかの理由でapt-getを使用できなかったため、debをダウンロードし、dpkg -iを使用して手動でインストールしました。

このエラーに関連するバグレポートがあります https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/733836 。

システムは正常に起動しますが、このエラーを修正したいと思います。構成を更新して修正する方法はありますか？

UPDATE：1か月間システムを使用した後、ある日、このエラーで起動できず、initramfsプロンプトが表示され、clonezillaから復元しましたバックアップが、私はそれが再び起こる可能性があることを恐れています。最悪なのは、なぜ起こったのかわからないということです。

UPDATE：

それは何度も何度も起こりましたが、多くの場合、強制シャットダウンまたはbatterxの不足が原因でした。ライブUSBを起動して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

ラップトップがバッテリーを使い果たしたり、シャットダウンを強制すると、一部のデータが矛盾したままになるようです。

また：

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>

ただし、e2fsckでは修正されません。

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>

ありがとう。

コメントからの注意：Clonezillaバックアップから復元するため、これを再現できません。

bootgrub2raid
5
umpirsky

hwmatchの問題に厳密に対処すると、/etc/grub.d/10_linuxを調べると、下の近くにこのようなリストが表示されます（この画面の9行目）。

# 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

何らかの理由で、grubのインストールが不完全でhwmatchモジュールが欠落しています。 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

このバグレポート（ bugs.launchpad.net-UbuntuをLucidからPreciseにアップグレードするとgrubの設定が壊れる ）に従って、すべてのgrubモジュールを取得する最も簡単な方法は、再インストールすることです。

Sudo dpkg-reconfigure grub-pcを実行し、ブートローダーをおそらく/ dev/vdaのどこかにインストールするように指示する必要があります。

上記はバグレポートからの直接の引用です。ここでコメントが指摘し、あなたのリンクを見ているので、代わりにこれを使用する必要があります：

Sudo dpkg-reconfigure grub-efi-AMD64

ただし、この投稿を見ると（ superuser.com-grub2 efiを再インストールする方法 ）最初にライブUSB/DVDで起動し、以下を使用する必要があります。

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

最初のステップは、ファイルhwmatchが実際に欠落していることを確認することです。その場合、最も簡単な方法は、次の場所から単純にコピーすることです。

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

ディレクトリに：

/boot/efi/efi/grub

このディレクトリ名は（ https://help.ubuntu.com/community/UEFIBooting ）に由来し、「ほとんど」ディレクトリ名であると言います。インストールを確認してください。

dpkg-reconfigureのより複雑な方法は、極度の注意で、適切なバックアップを行った後にのみアプローチする必要があります。

2
WinEunuuchs2Unix

スーパーブロックの別のコピーを使用しようとしましたか（8193と32768は例だと思います）：

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

スーパーブロックのコピーを1つ選択します。 3番目：この場合163840および

e2fsck -p -b 163840 /dev/XYZ
1
musbach

レガシーブートの場合、Sudo cp /usr/lib/grub/i386-pc/hwmatch.mod /boot/grub/i386-pc/hwmatch.modのようにスペアファイルを適切な場所に単純にコピーできない理由はありません

私のテストが同一であることを示しているように：

$ 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

EFIモードの場合：

EFIモードで16.04の新規インストールを確認しましたが、hwmatch.modが存在しないため、無視しても安全だと思います。気になる場合は、現在のgrub.cfgをバックアップし、問題の原因となっているinsmod hwmatch行をgrub.cfgで検索し、コメントアウトして問題を軽減するかどうかを確認することをお勧めします。

0
Elder Geek