карающий дух HURD настиг меня

где теперь, после ребута, можно посмотреть какие-нибудь логи, при условии, что у меня systemd?

при инит-скриптах такого не было! :)

Микроядро решит эту проблему?

ну, если затык случился в подсистеме usb или в кривом модуле, то да

И что микроядро сделает с кривым модулем?

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

Да, но подсистема при этом накроется.

но зато не всё ядро, как с Линуксом это происходит

А какая практическая польза от того, что ядро живое но диски, сеть и т.д. накрылись?

journalctl -b -1 ?

почему «диски, сеть и т.д.»? накрылось то, что накрылось, остальное продолжает работать

Накрывается только один драйвер. Ты его убиваешь, перезапускаешь и работаешь дальше.

А может быть проще не писать кривые модули?

Ну так если он сидит не с LiveUSB, то отказ подсистемы USB не приведёт к краху - можно будет перезагрузить драйвер с HDD. И уж тем более не будет проблемой перезагрузить сетевую подсистему. А если сделать кеширование критичных модулей в ОЗУ, то и драйвер HDD можно будет перезагрузить. Главное чтобы не упала перезагружалка, но она будет маленькая, а значит её можно отладить до идеального состояния.

там какая-то левая фигня с участием старых ядер и юнитов

Практика показывает, что после определённой «критической массы» любая программа начинает содержать хоть немного багов. Исключений нет - баги есть хоть в MacOS, хоть в винде, хоть в онтопике. И во всех офисах, графических редакторах сложнее Paint и играх сложнее «сапёра». Идея микроядра в том, чтобы разбить ядро на кучу мелких частей. Во-первых, маленькую программу проще написать без ошибок, во-вторых, если ошибки всё же будут - обрушится только этот модуль, а не вся система.

Например упавший модуль ФС сделает неработоспособной всю систему (я с этим сталкивался). Единственная польза от микро(пико и т.д.)ядра это разное адресное пространство. Насколько понимаю, это актуальней для закрытых модулей

только вот почему то мак перешёл га гибридное ядро...

Это не зависший модуль, это кэш на запись размером в одну четверть свободной памяти. С т. з. ядра — штатная ситуация. В логах ничего не будет, тупо сиди и жди, пока весь кэш сбросится.

Микроядерность здесь как бы ни при чём. См. vm_dirty_{background_,}bytes.

/var/log/messages глянь, я там как то открыл проблему, почему ось(в виртуалке) в kvm не пахала нормально. а вообще поставь syslog, на будущее.

какой кэш после окончания sync?

А ты делал sync?

его делает виджет монтирования в kde

А ты уверен, что оно досинкалось к тому моменту, когда у тебя система раком встала?

да, лампочка на флэшке перестала мигать, а виджет сообщил, что можно вынимать

А. Тогда сорри, я какую-то хрень сказал.

Это ещё что, у меня вот при вытаскивании флешки с поврежденной FAT случался kernel panic, причем стабильно. Обновление ядра из транка вроде решило проблему.

Насколько я помню, крэшился код из blk/чё-то там