Как я могу исправить эту поврежденную rpmdb?
Моя rpmdb повреждена, и обычная процедура ее исправления, похоже, не работает.
Это ошибка:
cris@PolariSuse [~]$ rpm -qa > /dev/null
error: rpmdbNextIterator: skipping h# 64697
Header V3 RSA/SHA256 Signature, key ID 3dbdc284: BAD
Header SHA1 digest: BAD (Expected bf167126ecaa67d16fee74af17096529278aad8d != cd4a91ad1f0d65d360cce5dacffea553e358b550)
Если я попытаюсь исправить это, я получу следующее:
cris@PolariSuse [~]$ sudo rpmdb --rebuilddb
[sudo] password for root:
error: cannot add record originally at 64697
warning: failed to rebuild database: original database remains in place
Я даже попробовал db_dump против файла Packages и последующего db_load: он, по-видимому, работает, но вновь созданный файл Packages имеет ту же ошибку.
Однако я вижу, что после того, как rpm получает ошибку при перечислении пакетов, он, тем не менее, может продолжить перечисление последующих пакетов, поэтому в идеале я хотел бы перестроить файл Packages, пропуская поврежденную запись. К сожалению, я не нашел ни одной утилиты, способной это сделать.
Кто-нибудь знает другой способ исправить эту поврежденную базу данных?
Ответы 1
Снимаем шапку и переустанавливаем.
См. Страницу руководства rpm, чтобы узнать, как удалить заголовок # (64697 в опубликованном вами сообщении).
Вам может понадобиться --nosignature --nodigest, чтобы отключить неудачные проверки.
Grrrr ... rpmdb --rebuilddb был изменен для остановки при ошибке.
Один из способов удалить запись - сохранить вывод db_dump в Packages и отредактировать запись с помощью текстового редактора. Формат db_dump - это ключ, за которым в следующей строке следует значение (т.е. заголовок rpm). Ключ - это hdrid в шестнадцатеричном формате. Используйте сопоставление с шаблоном, чтобы найти ключ, а затем удалите этот ключ и значение. Затем перейдите к загрузке файла в db_load.
Джефф, еще раз спасибо за подсказки. Я экспортировал свою базу данных с помощью db_dump. Я не понимаю, нужно ли мне искать идентификатор ключа (это 3dbdc284) или шестнадцатеричное представление заголовка (64697). А если второе: нужно ли мне брать 64697 как число и преобразовывать его в шестнадцатеричное? Или мне нужно преобразовать символы 6-4-6-9-7 и использовать их шестнадцатеричное представление? Если не возражаете, я экстраполировал все ключи из экспортированной db, они доступны здесь. Не могли бы вы взглянуть на них и сказать, какой из них я должен удалить?
Преобразуйте 64697 число, а не символы as ii) из десятичного числа в 8 шестнадцатеричных цифр: это первичный ключ в выводе db_dump.
Итак, очевидно, что 64697 - это шестнадцатеричный код FCB9, состоящий из 4 цифр, а не 8. Но я вижу, что все ключи заканчиваются на «0100», поэтому я поискал «FCB90100». К сожалению, такого ключа нет :( Даже поиск одного только "FCB9" ничего не возвращает. По крайней мере, не среди ключей.
Ммм, я подумал, что, возможно, из-за порядка байтов мне пришлось вместо этого искать 'B9FC', и на самом деле есть этот ключ 'b9fc0000', который также имеет добавленную странность, оканчивающуюся на '0000' вместо '0100' (но это не единственные, хотя они очень редки). Как вы думаете, это действительно может быть ключ, который я ищу?
Ключи будут намного короче заголовков, уникальны и размещены в одной строке. В противном случае опубликуйте 20-30 строк с начала вывода db_dump, и я постараюсь указать, что искать.
Джефф, благодаря тебе я вижу структуру файла экспорта. Дело в том, что среди ключей нет ключа, на который жалуется rpm. Но посмотрите, пожалуйста, мой последний комментарий от 15 мая. В любом случае, вы можете найти первые 20 строк моего db_dump здесь.
Спасибо за результат. См. Первую запись с ключом 0: это наибольшее значение hdrNum. Вторая запись имеет ключ! = 1, который указывает, что ключи были сделаны постоянными с помощью --rebuildid, но, возможно, не сообщение об ошибке. Удаление этой поврежденной записи по-прежнему возможно: нужно будет только найти запись по ее значению.
Итак, посмотрите на вывод --rebuilddb -v -v. Найдите в этом выводе уникальную строку. Преобразуйте эту строку в шестнадцатеричный и найдите шестнадцатеричное значение в выводе db_dump. Следующие 2 строки, скорее всего, будут поврежденным заголовком.
Хорошим кандидатом для поиска значения поврежденной записи является дайджест SHA1 заголовка.
Джефф, это в основном выше моей головы, но я постараюсь довести дело до конца. Спасибо тебе за помощь! Я дам вам знать.
Все, что я действительно пытался сказать, это найти SHA1 в выводе db_dump. Вероятно, это плохой заголовок.
Джефф, спасибо за ответ! Однако я был бы очень признателен, если бы вы могли подробнее рассказать об этом. Я просмотрел страницу руководства, но не вижу ничего, связанного с заголовком #, особенно в параметрах операции стирания. Я также попробовал параметры --hdrid и --pkgid, но оба ответили одной и той же ошибкой: «error: malformed pkgid: 64697».