Личинка, загружающаяся медленно с SSD
--in-place опция к sed не может действительно отредактировать файл на месте, таким образом, это на самом деле делает эквивалент:
if sed ... input > /tmp/output$$ ; then
mv /tmp/output$$ input
else
rm /tmp/output$$
fi
что означает до mv команда можно удвоить (или хуже) размер входного файла на диске. Когда файловые системы достигают почти полный, они становятся ужасно менее эффективными.
Это кажется, что большая проблема состоит в том, что Вы просто вне дискового пространства, или у Вас есть/var/log и/tmp, смонтированный на том же разделе как / и если / будет на небольшом разделе, то Вы переполните его теперь и на следующей неделе и через неделю после этого и т.д.
Посмотрите на mount и df /tmp и df /var/log видеть, как Ваш диск настраивается. Вы любой должны:
- зафиксируйте дисковое монтирование
- получите больший диск
- изучить
logrotate - прекратите регистрироваться так
- или некоторая комбинация вышеупомянутого
Попытайтесь включить SSD в первом порте SATA и выбрать его как первое устройство загрузки в BIOS. Иначе это обычно - вопрос игры с дисками и проверки GRUB конфигурация соответствует фактической нумерации дисков, т.е. hd0 определяет HD0 в BIOS и т.д.
Я почти уверен, что знаю первопричину и исправление этой проблемы, так как у меня есть то же самое на одном из моих ноутбуков, однако я не нашел достойного долгосрочного исправления.
Пожалуйста, проверьте папку /boot/grub2, в которой находится grub.cfg. Если я прав, у grub.cfg действительно огромный размер файла. Для информации: обычный grub.cfg имеет размер около 10 КБ (при реальной тяжелой мультизагрузке, это может быть до 50 КБ ), но размеры файлов в мегабайтах или выше определенно являются признаком повреждения.
Основная причина заключается в том, что :после установки или серьезного обновления последним шагом является запуск grub2 -mkconfig, который регенерирует файл grub.cfg. Это серьезный процесс, который сканирует все диски и т. д., поэтому он занимает некоторое время. После записи этого файла система почти всегда делает прямую перезагрузку, чтобы все ваши изменения вступили в силу. Что происходит с SSD-дисками, так это то, что диск получает полный сброс из-за перезагрузки, в то время как записанные данные в grub.cfg еще не были безопасно зафиксированы в его ячейках NAND. В большинстве случаев данные есть, но закрытия файла (, которое устанавливает длину файла и т. д. ), не произошло, что приводит к огромному пустому пространству (или старым данным на диске ), которые следуют за обычный файл grub.cfg.
Эффект от этого действия следующий: :grub2 читает файл grub.cfg, но после обычных данных (, которые представляют собой список доступных загрузочных систем, )это занимает некоторое время (до 30 секунд )просто для анализа фиктивных данных (часто 0x00 байт или подобных ), иногда выдавая ошибки. Но в итоге он находит конец файла и выдает правильный список найденных ОС.
Исправить :Убедитесь, что все диски доступны, и вручную запустите grub2 -mkconfig с выводом в файл grub.cfg. В качестве альтернативы используйте шестнадцатеричный редактор, чтобы найти настоящий конец данных, а затем используйте инструмент копирования, чтобы скопировать точно нужное количество байтов в новый файл, а затем замените неисправный grub.cfg на исправный.
Но должно быть более постоянное исправление, так как при каждом обновлении системы может появляться одна и та же проблема. Это означает, что завершение работы системы должно гарантировать, что ВСЕ SSD-диски сохранят все данные.