«Очистка осиротевших инодов» и состояние, потерянное в спящем режиме

Я просто «исправил» ТОЧНО ту же проблему и, таким образом, предоставил бы мое решение здесь, даже если ваша проблема другая.

Я сначала повторил по by-uuid вопросам (поскольку я удалил systemd, я думал, что sysvinit может привести к тому, что порядок устройства будет испорчен, как это было предложено в другом месте, и ссылка на uuid должна была решить проблему. Или так я подумал.

Кажется, что это хорошо в течение недели или даже двух,

После этого я вспомнил, какие проблемы у меня были с Gentoo, где я должен был явно установить resume=/dev/disk/by-uuid/{} в grub.cfg, иначе он не возобновился, несмотря ни на что. , я исправил свою проблему.Я даже установил dracut для управления моими initramfs.Он снова работал некоторое время, тогда это не так.

Тогда я пробовал разные вещи, такие как понижение ядра, установка bootlogd, но ничто не предлагало ничего особенного.

На этом этапе я начал искать дополнительную помощь. Я понял всю (не вполне читаемую) информацию здесь, на kernel.org. Я пробовал это, и это я не совсем remem

Снова это сработало, а потом опять не получилось.

Теперь вот где я на самом деле пошел параноиком, ища скрытые модули в ядре и предполагая атаки на холодную загрузку, полагая, что кто-то, вероятно, получил мое утверждение BIOS, возобновляет спящий режим, затем сбрасывает компьютер и сбрасывает загрузку памяти из какой-либо внешней системы обработки изображений. (Пожалуйста, обратите внимание, что все это абсолютно не надуманно, просто - как оказалось - совершенно не связано.)

В этом квесте - сегодня вечером - мне удалось найти этот сайт: здесь, в kernel.org . Отсюда я добавил параметры в 2.1 initcall_debug, 2.3 ignore_loglevel и 2.4 динамический отладчик для моего grub.cfg в качестве параметров загрузки ядра.

Затем это произошло снова.

Но теперь Я был более внимателен. Я заметил, что мой «потерянный inode» материал вызван « 2.1 initcall_debug ». Я провел несколько часов, узнав, что случилось тогда, полгода назад, снова безрезультатно. Я просто предположил, что это связано с отсутствием systemd и моей привычкой использовать localtime как hwclock (из-за случайной двойной загрузки с W7), поэтому он должен находиться в интервале 6-10 минут (неточный источник синхронизации) до 2

Мальчик, я был не прав.

Так получилось, что теперь, когда добавлен параметр ядра ignore_loglevel, в bootlog содержался EXACT

Мальчик, был ли я неправ. Это разница в три года (97010350.488716 секунд в соответствии с ntpdate). .

Таким образом, я, наконец, понял, что моя батарея CMOS разорена. Это может быть любопытное обвинение - даже если оно не перезаряжаемо - и, когда я оставил компьютер в течение длительного времени, он мог бы получить достаточно заряда, чтобы «выжить» в течение 1-2 дней - или это была, может быть, только температура , кто знает. (Это не мой основной компьютер, поэтому он проводил несколько дней подряд без питания каждую неделю.)

моя батарея CMOS разрядилась :

Это сказало , Я либо рекомендую поменять вашу батарею CMOS, либо - если это портативный компьютер или аналогичный -, тогда

Для всех этих шагов вам нужно быть root, поэтому вам рекомендуется начинать с команды sudo -s после каждого перезапуска и сначала устанавливать что-то наподобие Midnight Commander (apt install mc или Software Center) и используйте это (mc) для работы с конфигурациями и журналами.

Теперь у вас есть вход в систему /var/log/boot, в котором вы можете искать события при загрузке, как фактическая причина для «потерянных inodes ». Если вы обнаружите, что проблема с «изменением времени в будущем» с разницей в несколько часов или больше, то у вас определенно есть и ваша батарея CMOS / RTC, и ее нужно будет заменить.