Ошибка unknown command hwmatch [closed]

Я получаю сообщение «unknown command hwmatch» при каждой загрузке после того, как я установил Ubuntu 16.04, выполнив следующие действия: https://gist.github.com/umpirsky/6ee1f870e759815333c8 по порядку для настройки RAID0.

Особое внимание к apt-get install -y grub-efi-amd64 part https://gist.github.com/umpirsky/6ee1f870e759815333c8#file-ubuntu-raid-sh-L40

По какой-то причине я не мог использовать apt-get, поэтому я установил его вручную, загрузив deb и используя dpkg -i.

Имеется отчет об этой ошибке https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/733836 .

Система загружается нормально, но я хотел бы исправить эту ошибку. Есть ли способ обновить конфигурацию и исправить ее?

ОБНОВЛЕНИЕ: Через месяц использования системы однажды она просто не загрузилась с этой ошибкой, и в итоге появилось приглашение initramfs, я восстановил ее из резервной копии clonezilla , но боюсь, это может повториться. Хуже всего то, что я не знаю, почему это произошло.

ОБНОВЛЕНИЕ:

Это происходило снова и снова, часто после принудительного выключения или выхода из строя batterx. Я загрузил live 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.

5
задан 14 January 2017 в 21:55

3 ответа

Контакт строго с 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

По любой причине Ваша установка личинки является незавершенной и недостающей 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 от Ясного до Точных результатов в поврежденной конфигурации личинки) самый легкий способ получить все модули личинки состоит в том, чтобы переустановить его.

Необходимо работать 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
ответ дан 15 January 2017 в 07:55

Сделал Вы пытаетесь использовать другую копию своего суперблока (я думаю, что 8193 и 32768 examaples):

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

Выбирают одну копию суперблока, например, третью: В этом случае 163840 и сделайте:

e2fsck -p -b 163840 /dev/XYZ
0
ответ дан 15 January 2017 в 07:55
  • 1
    Хорошо, @bodhi.zazen, я перестал работать одну неделю назад в актуальных 16.04 системах LTS с gparted. Но когда Вы говорите, что другие инструменты могут сделать это, I' m счастливый:-) – sudodus 8 October 2017 в 04:38

Для начальной загрузки Прежней версии , нет никакой причины, Вы не можете просто скопировать запасной файл в соответствующее местоположение как в 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

режим For EFI:

я проверил новую установку 16,04 в режиме EFI, и hwmatch.mod не существует так, я предположил бы, что это может быть безопасно проигнорировано. Если бы Вас раздражает, что я предложил бы создать резервную копию Вашего текущего grub.cfg, ища Ваш grub.cfg insmod hwmatch строка это вызывает проблему и комментирует его, чтобы видеть, облегчает ли это проблему.

0
ответ дан 15 January 2017 в 07:55
  • 1
    @Rengasami Ramanujam, можно попытаться уменьшить файловую систему FAT32 и раздел, но я не полагаюсь на процесс после отказа на прошлой неделе, таким образом, я рекомендую скопировать данные в форме файлов к безопасному месту перед запуском. – sudodus 8 October 2017 в 06:28

Другие вопросы по тегам:

Похожие вопросы: