Astra linux хеш сумма не совпадает

Схожу с ума. Все контрольные суммы разные

Несколько часов уже сижу и втыкаю в контрольные суммы. Стресс нарастает)

Скопировал 3-гигабайтный iso-образ из домашней директории на внешний жесткий. Проверил md5 — не совпадают. Скопировал этот iso на несколько флешек — md5 всегда разный. Сделал копию iso рядом в эту же директорию — md5 разные. Потом уже совсем отчаялся — несколько раз вычислил md5 одного и того же iso в /home — результаты всегда разные. Точнее, почти всегда. В каких-то редких случаях бывает совпадение.

Делал sync, вытаскивал/вставлял носители — всё-равно разные суммы. Уже начал грешить на md5 — проделал те же действия с sha1 — суммы разные

Подскажите, я что-то не знаю или у меня все носители испорчены?

ЗЫ: на крошечном файле .xinitrc суммы совпадают что с ним не делай

Хэши проверял командой «md5sum ФАЙЛ» и «sha1sum ФАЙЛ»

1)Дисковый контролёр работает с ошибками, если ему надо одновременно читать и писатать на два разных диска.
побдить это можно так, сначала копируешь файл на tmpfs, потом от туда на второй диск.
2)Может у тебя ОЗУ с битыми ячейками, попробуй его memtest проверить.

memtest86+ поставь на ночь крутиться.

Спасибо память щас гляну. А вот контроллер как можно проверить..

Это не неисправность контролёра, а фича материнок, не зависящая от производителя, стоимости и ОС.

Пишешь моим способом, если в отличии от прямого копирования всё хорошо, значит проблемы с работой с несколькими дисками одновременно.

Мемтест с первой секунды посыпал ошибками. Первая сломаная память на моей памяти (pun intended). Странно, как при этом ОС работает и хоть бы что ей

А ты посмотри dmesg.

ничего подозрительного. Подозреваю, при сломанной памяти того же хрома должен хватить инфаркт. Но нет, блин. Ни намека на ошибку в работе

Действительно странно. Ну если memtest86+ находит проблемы, то память однозначно менять.

Угу. Одна плашка сдохла. Щас попробую без нее покопировать файлы

Я тоже сталкивался с квантовой пямятью. Фигня была вообще магическая — любой линукс работает и не жалуется, винду не поставить ни какую. Мемтест то не видит памяти, то она вся у него битая, то все ок.

Кстати, можешь отрезать ее на уровне ядра и использовать как генератор случайных чисел, вычисляя ее md5

Я тоже сталкивался с квантовой пямятью.

Что за квантовая память?

Вот блин, теперь такое захотелось.

Вдруг в поломке закономерности есть)

на правах мимокрокодила

Я сталкивался с тем, что мемтест выдавал ложноположительные результаты в SMP-режиме. Проверь ещё в UP.

Не обязательно, на моей памяти из 5 случаев «битой» памяти (memtest) только в 1 была реально виновата память — остальное материнка. Данные может портить контроллер при пересылке, также у контроллера есть куча всяких встроенных функций и некотороые из них могут глючить. А возможно вообще проблема с питанием — при массированом чтении/записи md5 калькуляции может не хватает питания для RAM и там начинаются чудеса

Фух. Спасибо еще раз. Теперь суммы совпадают. А то я уже начал разочаровываться в современных технологиях хранения информации.

А есть утилита, которая копирует и сразу проверяет, что скопировала? Выходит, cp, nautilus, mc об этом не заботятся

Всмысле плашки по отдельности? Проверил. И целую и сломанные плшки ставил по одной в разные слоты. Результаты предсказуемые. Виновник найден)

Совершенно очевидно — у вас протрояненный cp, который дописывает во всё гадостей. А md5sum протроянить забыли/не успели.

ИМХО нет, потому как

Дисковый контролёр работает с ошибками, если ему надо одновременно читать и писатать на два разных диска.
побдить это можно так, сначала копируешь файл на tmpfs, потом от туда на второй диск.

А есть утилита, которая копирует и сразу проверяет, что скопировала?

Такая утилита не очень то поможет, так как нет доверия к самому контролёру собственно.
Ну если что можешь написать что нибудь на основе dd и bash
только не забывай кэш сбрасывать, потому что проблемы вызывает контролёр, а кэш до него в ОЗУ.
И к стати, вдруг проблема не в контролёре на материнках, а во взаимном наведении помех двумя работающими дисками?

Да я просто тред вспомнил про вредоносный код в компиляторах. Там всё так и было, почти иллюстрация 🙂

Если бы было так, то он и в память плохо бы копировал, да и суммы бы хаотически не менялись.

Суммы как раз хаотически меняющиеся не проблема я думаю. Всего 1 битик во входе поменять.

Вот поэтому на серверах ВСЕ шины передачи данных должны быть с контролем четности и не должно быть sata. Что за мать?

лично я копирую только rsync

В данном случае rsync не поможет.

второй раз копируешь и смотришь что скажет

Но rsync (двойной), конечно, проверенное решение.

h77m-hd3. А бывает ddr с контролем четности?

Про двойной rsync интересная идея

ecc ram это называется. А у sas есть механизмы контроля end-to-end, которых у sata нет.

у sas есть механизмы контроля end-to-end

ясный перец. Ведь SAS-Serial Attached SCSI и там команды scsi летают по интерфейсу.

Проверяй память — Memtest и GoldMemory.

Я тоже сталкивался с квантовой пямятью.

И по чём там у вас доллар в 2117?

Фигня была вообще магическая — любой линукс работает и не жалуется, винду не поставить ни какую.

Очевидно что критические для работы инсталлятора винды данные перманентно записывались в битые ячейки (находящиеся скорее всего где-то в самом начале). Ничего удивительного.

Странно, как при этом ОС работает и хоть бы что ей

Источник

Виртуальная Кали Линукс не обновляется: Хеш-сумма не совпадает.

Виртуальная Кали Линукс: ошибка Хеш-сумма не совпадает.

Всем привет, приветствую в блоге К76, и сегодня мы попытаемся отчасти исправить ошибку обновления виртуальной Кали Линукс в VirtualBox типа Хеш-сумма не совпадает. Ну… картинка прилагается:

Из кучи вариантов, в том числе «стопроцентных» типа apt —fix-broken install не помогает. И, как вы убедитесь позже, помочь не могла бы.

Ошибка Хеш-сумма не совпадает: откуда ноги растут?

Очень похоже, что причиной послужил обновлённый пакет libgcrypto20, который используется APT в Линукс. Это проблема не только, кстати, у Кали. С подобными ошибками встречаются почти все пользователи, пытающиеся установить или запустить виртуальную Линукс на хозяйской Windows 10. Ошибка почти гарантийно выскакивает на активированной недавно по всем версиям Windows 10 WSL2. Последний пакет настроек призван улучшить предыдущую фишку Hyper-V, без которой, как вы помните, мы, в числе прочего, даже не могли 64-х битные версии виртуальных систем установить. Однако в самой виртуальной Линукс для единственного файла «было замечено» сразу три разных хеша. Неверный генерировался как-раз APT, и какой-то «посторонний» появлялся всякий раз после скачивания файла через wget, используя тот же адрес, что и в браузере…

Решаем ошибку Хеш-сумма не совпадает.

В связи с этим по сети гуляют два неоформленных до конечного исправления решения. Первый из них — перед запуском команды на обновление виртуальной Кали создать файл, который будет пресекать оптимизацию метода sha256 от библиотеки libgcrypto20. В конечном итоге единожды вводимые команды по сети гуляют в таком виде (работаю из root):

Вариант второй: подправим Windows 10.

Попробуйте отключить WSL2 (платформу Windows Hypervisor) и проверить возможность виртуальной Линукс обновиться. Для этого

• выключаем все виртуальные ОС и закрываем саму VirtualBox.
• запускаем в Windows консоль команд cmd от имени администратора
• вводим команду

• перезагружаем Windows.

Проверьте теперь функции VirtualBox. Если всё вас устраивает, оставляем так. В противном случае откатитесь назад:

Источник

несоответствие хэш-суммы пакетов debian apt

из командной строки Debian я получаю несоответствие хэш-суммы после выполнения aptitude update; aptitude upgrade . Ниже приведен вывод командной строки. Я пробовал aptitude clean , но это похоже не помогло. Я также сделал несколько поисков в google, но ничего не помогает. Я получаю ошибку несоответствия в течение нескольких дней.

любая помощь приветствуется.

8 ответов

попробуйте использовать apt-get :

Если удалить /var/lib/apt/lists/* не работает.
(экстрасенсорное восприятие. если вы за прокси),исправить «несоответствие хэш-суммы», как это:

создать файл /и т. д./кв/АПТ.conf.d / 99fixbadproxy
с этим содержанием

В моем случае такое решение не работает для меня:

• /var/lib/apt/lists/*
• изменение серверов на «основной сервер» (или какой-либо другой сервер foreing)

у меня все еще был тот же репозиторий, дающий мне ошибку «несоответствие хэш-суммы».

я решил попробовать это решение:

1. перейдите в раздел «программное обеспечение и обновления»
2. снимите все репозитории из раздела «программное обеспечение Ubuntu»
3. выберите Раздел «аутентификация»
4. удалить все записи
5. сделать sudo apt update (без репозиториев это должно закончиться очень скоро)
6. повторно откройте «программное обеспечение и обновления» — > «Ubuntu Software» и повторно проверьте все необходимые репозитории
7. С sudo apt update

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

Хеш сумма не совпадает

Хеш сумма не совпадает

Сообщение RDV1984 » 19.07.2012 20:03

Re: Хеш сумма не совпадает

Сообщение SLEDopit » 19.07.2012 20:04

Re: Хеш сумма не совпадает

Сообщение sgfault » 19.07.2012 22:04

Re: Хеш сумма не совпадает

Сообщение taaroa » 19.07.2012 22:19

ещё раз запустить процесс обновления.
sudo apt-get update
sudo apt-get upgrade

Re: Хеш сумма не совпадает

Сообщение RDV1984 » 24.07.2012 23:17

ещё раз запустить процесс обновления.
sudo apt-get update
sudo apt-get upgrade

Re: Хеш сумма не совпадает

Сообщение sash-kan » 25.07.2012 13:44

скачал файл и список пакетов, в котором файл упоминается·
все три контрольные суммы сходятся·

совет: удалите файл из кэша·
либо вручную — см. в /var/cache/apt/archives/ и в /var/cache/apt/archives/partial/
либо полностью очистите весь кэш — командой sudo aptitude clean

Re: Хеш сумма не совпадает

Сообщение taaroa » 26.07.2012 10:43

Re: Хеш сумма не совпадает

Сообщение sgfault » 26.07.2012 13:05

Re: Хеш сумма не совпадает

Сообщение taaroa » 26.07.2012 13:43

Re: Хеш сумма не совпадает

Сообщение RDV1984 » 26.07.2012 18:00

Re: Хеш сумма не совпадает

Сообщение sgfault » 26.07.2012 18:56

Re: Хеш сумма не совпадает

Сообщение RDV1984 » 27.07.2012 18:20

Re: Хеш сумма не совпадает

Сообщение sgfault » 27.07.2012 20:22

А также повторите установку с таким файлом:

Ну, и, естественно, весь вывод сюда.

Re: Хеш сумма не совпадает

Сообщение RDV1984 » 27.07.2012 22:27

Re: Хеш сумма не совпадает

Сообщение sgfault » 28.07.2012 00:15

Я тут посмотрел..
deb-multimedia.org новость от 04/07/2012. Весьма похожая ситуация, и весьма похоже на «nobody cares».
bugs.debian.org/679841 — примерно то же самое. Естественно, тоже без ответов (это ж deb-multimedia).

Тем не менее, в новости на deb-multimedia написано, что apt-get все еще работает..

Если же вы абсолютно уверены, что он тоже не работает, то.. честно говоря, я не верю, что что-то получится, но, если очень хочется, начните с того, что вручную проверьте, что хеш сумма файла в /var/cache/apt/archives совпадает (должна быть такая):

Впрочем, я уверен, что тут все будет правильно. А вот, что дальше, я не знаю

Источник