dirty bit 0x25

Как вы думаете, чего я хотел в пятницу вечером, приехав в час ночи с работы? Не знаю, чего хотели бы вы, а вот мне подарили 1.5 часа изысканнейшего удовольствия: мой ноутбук напрочь отказался включаться.
Постик про конкретную нетривиальную проблему с ноутом и dirty bit 0x25 - вдруг кому-нибудь поможет.

Итак, дано. Ноутбук с операционкой openSUSE. В консольном режиме были установлены обновления cron, после чего ноутбук был выключен. При попытке включения показывает экран загрузки KDE, после чего в какой-то момент падает в консоль. Графическая подсистема не стартует вообще.

В консоли при попытке ввести хоть какую-то команду с записью в файловую систему (например, sudo init 5) sudo выдаёт ошибку, что такой-то файл read-only, однако команда таки уходит на исполнение с правами root.
То есть KDE не грузилась, потому что ей что-то там надо было записать на диск - например, логи.

Путём нехитрых манипуляций (df -k) было установлено, что система нормально видит жёсткий диск. При попытке прогона fsck, мне было выдано, что bios is corrupted. В этот момент лёгкое недоумение перешло в отчётливое ощущение "абзац барсику". Ну ничего, загрузился в bios, сбросил в default. Загружаем систему, подтверждаем доверие биоса сертификату операционной системы (я удалил все настройки secure boot).

Картина была неизменна, как земля в иллюминаторе. Ок, начинаем пробивать с fsck все логические диски по одному. И - опачки: в разделе /boot/efi=/dev/sda1 она заявляет, что у него стоит dirty bit 0x25.

Казалось бы, секундное дело, лечится той же стандартной утилитой fsck. Но я перепробовал команды (из-под root):

> fsck -trawl /dev/sda1
> fsck.vfat -a -w -r /dev/sda1
> fsck.fat -a -w -r /dev/sda1
> dosfsck -trawl /dev/sda1

и всевозможные неописанные комбинации ключей. mount/umount диска делал, да. Итог один - утилита пишет, что "хозяин, я смогла" (changes were performed), и, вроде как, если сделать fsck /dev/sda1, всё будет ок. Но при перезагрузке компьютера или ещё одной umount-mount раздела та же fsck пишет про dirty bit.

Помогло только одно. Моя умничка opensuse пишет read-only snapshots предыдущих успешных конфигураций системы. Пишем команду: sudo snapper rollback [snaphot number]. Перезагружаемся - и вуаля, графическая подсистема грузится и никаких больше read-only!

После этого я ещё раз накатил то же обновление cron - и всё работает.

Честно сказать, не вполне понимаю, что это было. Скорее всего, какой-то софтовый козлизм, чем аппаратная проблема - я даже не вполне верю в то, что этот dirty bit 0x25 реально был - на это указывает и то, что snapper успешно откатил версию загрузчика..

Скорее всего, при обновлении загрузчика ОС (что выполнялось при накатывании обновления cron) что-то там перемкнуло в bootloader.