Как исправить неожиданное отключение работы MX Linux?

Question

[Runis]

В том году решил попробовать из линуксов MX Linux, один из не многих без systemd. Установил, диск зашифровал, чётки создал, всё как очно.

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





Как видите какой результат. Помогите пожалуйста разораться мне как пользователю, что это, как это исправить? Пробовал через live CD образ зайти на диск и тоже не получается зайти.

Comments

[Everything_is_bad]

чётки создал, всё как очно.

чё?

без systemd

и в чем для тебя проблема systemd?

[Runis]

Everything_is_bad, * учётки создал, всё как обычно.
Пишу со сломанной клавиатуры.

и в чем для тебя проблема systemd?

Хочется без него, это плохо?

[Adamos]

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

На втором скрине он банально жалуется на ошибку ФС и просит запустить fsck вручную. Английским по черному.

[SunTechnik]

Сейчас система ругается, что повреждена файловая система и требуется выполнить fsck.
Примерно так:
fsck /

Но, так как у Вас используется шифрование, то использование livecd итд будет связано с трудностями. (от кого шифруетесь?)

Кстати, фото загрузки с livecd нет. Там какой-то пример неудачной попытки попасть в uefi загрузчик.

[Everything_is_bad]

Runis,

Хочется без него, это плохо?

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

[rPman]

чем и ка шифровали то?
если биос не видит EFI раздел, может его и нет? проверьте, диск то на месте? может проблема аппаратная?

[Runis]

Adamos, а можно чуточку по подробнее, дас ис дас? В том режиме, в который выкидывает исправить можно или через live cd?

[Runis]

Everything_is_bad, а какая разница то? Предпочитаю так, много аргументов против данной инициализации видел.

А по сути моей проблемы найдётся какое решение?

[Runis]

SunTechnik, а можно по подробнее с примерами команд?

Разве шифрование это не очевидное действие в плане личной безопасности?

С livecd таки удалось спокойно запуститься.

[Runis]

rPman, шифровал в момент установки операционки с режима установки.

Диск на месте, с livecd удалось запуститься и увидеть его. Даже удалось путём сложных манипуляций (для меня) и неизвестных мне ранее команд открыть его. Вот сейчас сперва спасаю нужные файлы. Правда пока что это не решение моей проблемы.

[Everything_is_bad]

Runis,

много аргументов против данной инициализации видел.

я видел аргументы только альтернативно одаренных, ты можешь предоставить реальные аргументы?

А по сути моей проблемы найдётся какое решение?

я пишу в комменах, а не в ответах, с чего ты решил что я тут должен писать решение?

Разве шифрование это не очевидное действие в плане личной безопасности?

в большинстве случаев оно не нужно, а часто и вредно, в случае с тобой.

[rPman]

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

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

Шифрование бывает разное:
- полнодисковое шифрование LUKS красиво работает только если поддерживается биосом (вроде бы машины с TPM это позволяют, т.е. не сильно старые).. только этот вариант в теории спасет от злодея (правда умный злодей может тупо подложить кейлогер в вашу клавиатуру и украсть пароль.. ну и еще 100500 методов), а точнее сильно усложнит ему жизнь.
- шифрование на уровне файлов fscrypt/zfs/ecryptfs (это называется зашифровать домашнюю директорию, можно настроить вручную после установки в любой момент), защищает только ваши данные, но не файлы операционной системы при физическом доступе.

второй метод гораздо проще, удобнее, и дает достаточны уровень защиты большинству (а так же не ломает к примеру trim на ssd дисках, точнее это можно включить и на luks но идеологически понижает уровень защиты)
p.s. а еще шифрование заметно понижает скорость записи, а если и не заметно, то повысит нагрузку на процессор... особенно если вы хотите 'гигабайты в секунду' а на вашем процессоре только шифрование в лучшем даст гигабайт. Оценить можно командой: cryptsetup benchmark

[Runis]

rPman, скорее всего у меня полнодисковое шифрование, тк старался обезопасить по достойному для меня максимому. Да и опыт потери флешек с личными данными имею, и хоть от кражи это не спасёт, но мне будет спокойно на будущее, да и флешками нынче я почти не пользуюсь. Но всё же, зачем облегчать злодеям жизнь?))

К слову, а можно в операционке, или даже в live cd сменить пароль шифрования?

И как быть с fsck не подскажите?

[Adamos]

Runis, вам уже подсказали про fsck, зачем вообще хвататься за линукс, если не можете сами погуглить, например, "initramfs запустить fsck" и получить инструкцию даже от ИИ?

[shurshur]

Runis,

Предпочитаю так, много аргументов против данной инициализации видел.

У systemd было много проблем на ранней стадии его развития. Плюс много поспешных не очень продуманных изнчально архитектурных решений и наплевательское отношение к работе с разработчиками конкретных дистрибутивов, кроме RedHat, под который оно собственно и разрабатывалось.

Вся обоснованная критика была из тех времён. Эти времена давно прошли. systemd работает, работает хорошо, работает быстро, универсален и единообразен. Более того, на самом деле его необязательно использовать весь и целиком. Например, многие не используют networkd или resolvd, предпочитают NetworkManager, netplan или другие системы.

То, что systemd - большой комбайн и тянет в систему море зависимостей (например, острая зависимость от dbus, отдельные глюки в котором вызывали фейерверк эффектов в Centos 7), часто относят к некоторым недостаткам systemd. Однако, по большому счёту, это проблема не для рядового пользователя, а для специфических условий. Например, для легковесных дистрибутивов с крайне ограниченными ресурсами программно-аппаратной среды (всякие одноплатники, промышленные компьютеры итд). Но для таких специальных случаев часто берут что-то суперлёгкое типо runit или даже колхозят свою специальную систему инициализации. Это не про пользователя современного довольно мощного компьютера (даже офисная пищущая машинка - суперкомпьютер по меркам 90-х).

Та самая "классическая" система инициализации - это образец "очень просто и одновременно ужасно". В sysvinit у системы есть 7 состояний, "уровней выполнения" (runlevel), из которых 0 и 6 соответствуют выключению и перезагрузке, остальные - реальному фунционированию (и чаще всего используется лишь один из них, какой именно - в разных дистрибах немного разный подход). Причём на словах они что-то там означают, в реальности же это означало просто запуск некоего скрипта при переходе в этот runlevel. Этот скрипт В КАЖДЫЙ СИСТЕМЕ БЫЛ СВОЙ и никакого стандарта не было. Для каждого приложения в каждом дистрибутиве нужно было писать свой скрипт, который умел запускать сервис, останавливать, проверять состояние - с учётом особенностей дистриба. Если нужно было обеспечить контроль запущенности и перезапуск в случае падения - это надо было колхозить мейнтейнеру конкретного приложения в этом дистрибе. Всякие особые условия (запуск в chroot, использование cgroups, кастомизация запуска итд) - часто колхозить приходилось уже самому пользователю, вникая во множество нюансов приложения и дистрибутива.

Использование systemd не противоречит использованию приложений с скриптами запуска "по-старому", так назывваемых "sysvinit-сервисов". Их systemd автоматом обнаруживает и интегрируеют в себя, благодаря чему их можно запускать и средствами systemd (systemctl start имя_сервиса приведёт к выполнению /etc/init.d/имя_сервиса start). Но полагаться на такие скрипты так себе затея и это в основном используется для работы совсем легаси приложений или приложений, где разраб - всё ещё ленивая задница даже в наше время.

Альтернативные системы (типа openrc) так и не смогли дорасти до уровня systemd по качеству, стабильности и возможностям кастомизации. Например, у openrc годами не могли добиться стабильного запуска сервисов в параллельном режиме - все использовали последовательный, ибо иначе могло случиться что угодно где угодно и состояние системы оказывалось попросту непредсказуемым.

В общем, обычному пользователю нет никакого смысла отказываться от преимуществ systemd. Проблемы словить почти нереально - больше шансов словить их в альтернативных системах инициализации - а причины от него отказываться для обычного домашнего пользователя попросту отсутствуют.

... Разумеется, я не призываю срочно форматировать диск и ставить другую систему. Это личное дело каждого, да и ломать уже используемую систему, настроенную, с софтом и уже имеющимися там личными данными, по первому же чиху точно не стоит.