'Очищая осиротевший inodes' и состояние, потерянное на резюме спящего режима

Я просто "решил" ТОЧНО ту же проблему и таким образом предоставлю мое решение здесь, даже если Ваша проблема отличается.

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

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

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

Затем я попробовал другой материал как понижение ядра, установка bootlogd, но ничто не предложило ничего специального.

На данном этапе я начал искать больше справки. Я схватил весь - не совсем читаемый - информация здесь по kernel.org. Я попробовал это, и что, я не совсем помню то, что я сделал точно, но эй.

Снова это иногда работало, с другой стороны это не сделало.

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

В этих поисках - сегодня вечером - мне удалось найти этот сайт: https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues. Отсюда, я добавил параметры в 2,1 initcall_debug, 2,3 ignore_loglevel и 2,4 динамических отладках к моему grub.cfg как параметры начальной загрузки ядра.

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

Но теперь я был более внимательным. Я заметил, что мой "осиротевший inode" материал происходит из-за "Суперблока, прошлое время записи находится в будущем". Я провел несколько часов, находя что случилось тогда, приблизительно за половину года до этого, снова напрасно. Я просто предположил, что это связано с отсутствием systemd и моей привычкой к использованию localtime как hwclock (из-за случайной двойной загрузки с W7), таким образом, это должно быть в интервале 6-10 минут (неточный источник часов) максимум к 2 часов (я нахожусь в DST GMT+1).

Как бы не так.

Это так произошло, что теперь, с ignore_loglevel добавленным параметром ядра, нелегальный выпуск содержал Точную дату, в которой были мои часы во время начальной загрузки, а также время изменения.

Мои часы были на самом деле установлены до 06 июня 2013, который является, по-видимому, датой выпуска BIOS или чем-то подобным. Вот в чем разница трех лет (97 010 350,488716 секунды согласно ntpdate).

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

tl; доктор:

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

1. (дополнительный при использовании установки по умолчанию Гостеприимных 16.04 Вам не нужно это), устанавливают и настраивают bootlogd, так, чтобы Вы нашли свой нелегальный выпуск в/var/log/boot. (С systemd Вы просто работаете journalctl -b получить нелегальный выпуск.)

2. Отредактируйте Ваш /boot/grub/grub.cfg файл, и добавляет initcall_debug ignore_loglevel в конце первой строки, запускающейся с linux /boot/vmlinuz... под первой строкой, запускающейся с menuentry.

3. Перезагрузите теперь. Это очень важно, так, чтобы Вы были в спящем режиме с новыми активированными настройками.

4. Будьте в спящем режиме, оставьте машину для значительного количества времени, как часы, по крайней мере, затем возобновитесь.

5. Наконец, любое выполнение journalctl -b > /var/log/boot если Вы не помнили удалить что-то позвонившее systemd и/или установка чего-то позвонившего upstart, openrc, или sysvinit.

Для всех этих шагов необходимо быть корнем, таким образом, рекомендуется запустить с a sudo -s команда после каждого перезапуска и установки что-то как Полуночный Командующий (apt install mc или Центр программного обеспечения) сначала и использование это (mc) работать с конфигурациями и журналами.

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