Синий экран смерти linux

После обновления ядра вместо рабочего стола синий экран

Доброго времени суток! Одолела проблема следующего характера: После обновления Ubuntu до версии 3.2.0-67-generic-pae попросил ноутбук перезагрузки. После перезагрузки после ввода пароля учетной записи появляется только синий экран, но мышка реагирует на движения и когда включаю Wifi слева появляется информационное всплывающее окошко о статусе подключено/отключено. Больше на рабочем столе ничего не отображается. При попытке вызвать терминал с помощью клавиатуры — ничего не отображается. Что это такое и как это победить? Очень нужна помощь.

очевидно, что Unity что-то не нравится. На виртуальные терминалы переключается? ctrl-f2
И наверное тебе сюда: Сегодня моя Юнити перестала загружатся.

На виртуальные терминалы не переключается. В теме сброшенной ссылки, как я поняла терминал все-таки отображается, а у меня нет.

Видео драйвер переставить? И по клавише Ctrl-Alt-F1 попробуйте.

Тогда нужно попробовать загрузиться в init 3 и смотреть логи.
Чтобы загрузиться в init 3 нужно в меню grub выбрать пункт убунты и нажать E, затем в конце строки начинающейся с linux дописать init=/sbin/init 3
P.S. не уверен, что сработает на убунте, но должно

Вошла по клавише Ctrl+Alt+f1 пробую вот это: sudo apt-get install ubuntu-desktop Надеюсь что поможет

Не поможет. Нужно копать в сторону драйверов. Кстати, какой драйвер/видеокарта?

Не могут же разрабы убунты быть такими идиотами, чтобы удалять пакеты из ubuntu-desktop во время обновления ядра!

Видеокарта nvidia Geforce 610M 1 Gb

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

*-display UNCLAIMED описание: VGA compatible controller продукт: GF119M [GeForse 610M] производительность:NVIDIA Corporation физический ID: 0 сведения о шине:pci@0000:01:00.0 версия:a1 разрядность:64 bits частота: 33MHz возможности:pm msi pciexpress vga_controller cap_list конфигурация:latency=0 ресурсы: память: f6000000-f6ffffff память: e0000000-e7ffffff память: e8000000-e9ffffff ioport:e000(размер=128) память: f7000000-f707ffff *-display описание: VGA compatible controller продукт: 2nd Generation Core Processor Family Integrated Graphics Controller производительность:Intel Corporation физический ID: 2 сведения о шине:pci@0000:00:02.0 версия:09 разрядность:64 bits частота: 33MHz возможности:msi pm vga_controller bus_master cap_list rom конфигурация: driver=i915 latency=0 ресурсы: IRQ:45 память: f7400000-f77fffff память: d0000000-dfffffff ioport:F000(размер=64)

Источник

Аналог BSOD в линуксе

Когда компьютер с виндой в возникают какие то проблемы с железом то как правило это заканчивается BSODом, а что вместо него происходит в линуксе? Просто ситуация такая, что коды ошибок из бсода не дают мне целую картину и я уже 3 дня так и не могу понять в чем причина отказа работы компьютера. Может быть какие то коды ошибок или логи из линукса дали внесли бы больше ясности. Как там это происходит?

kernel panic? сомневаюсь в информативности.

коды ошибок из бсода не дают мне целую картину

Как ты его получил, демон.

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

Так ты получил bsod на виндовс а спрашиваешь про линукс.

Если хочешь полезного ответа то полно и точно опиши проблему и что предпринималось.

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

Полный аналог BSOD-а — это kernel panic, и он встречается достаточно редко.

Во имя справедливости должен заметить, что и в винде BSOD сейчас появляется крайне редко. Если 10 лет назад он вполне мог выскакивать из-за кривизны самой винды, то сейчас это либо __фатально__ кривое железо, либо сторонние драйвера с явными багами.

Лично я последний раз BSOD в винде видел, когда попытался через Ext2FS скопировать в ФС с локалью KOI-8r файл, имя которого содержало символы, отсутствующие в этом самом KOI-8r (то ли украинские буквы, то ли параграф. ). В общем, практически ССЗБ. А предпоследний. предпоследний был вообще не помню сколько лет назад. Правда, винда у меня только на работе, и запускаю я её только когда надо документацию править — в общем, мой пример не совсем типичный.

Ну а ТСу я всё же посоветую сходить на винфак. ну к примеру, на iXBT.com, и там поделиться BSODом. Просто из сообщения ТСа я так и не понял, стоит ли на подопытном компе линукс вообще, и если стоит, нормально ли работает. Если нормально — то может, и хрен бы с ней, с этой виндой? Или же ТС хочет поставить линукс только для того, чтобы диагностировать проблему? 🙂

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

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

Если в безопаске тоже не грузится, отключай устройства по одному, пока не загрузится

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

Источник

Исправляем синий экран с кодом ACPI BIOS ERROR на Windows, Linux

«Синий экран смерти» с кодом ACPI BIOS ERROR может указывать на довольно сложные неполадки. Не особо положительный прогноз связан с тем, что в значительной части случае дело в аппаратных поломках. Однако часто проблема и в системных сбоях, которые можно попробовать исправить. По крайней мере попробовать устранить BSOD вручную – вы просто обязаны.

Причины ошибки ACPI_BIOS_ERROR

Первоисточников сбоя очень много, при чем они разносторонние:

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

Что характерно ошибке ACPI_BIOS_ERROR, так это мультиплатформенность. Она может появляться во всех версиях Windows, а также на Linux, Ubuntu. Ошибка может сопровождаться кодом 0x000000A5 или нет. Известны случаи, когда сбой проявлялся один раз и после перезагрузки исчезал, но бывает, что после каждого запуска появляется BSOD и не пускает в систему.

Как исправить BSOD ACPI BIOS ERROR?

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

Обновить и переустановить драйвера

«Синие экраны смерти» с различными кодами часто появляются из-за проблем с драйверами. Поломки могут вызывать устаревшие, обновленные, но проблемные, и несовместимые драйвера устройств. Стоит обновить их. Если есть подозрение, что ошибка начала появляться после апдейта какого-то конкретного ПО или подключения нового устройства, стоит попробовать выполнить откат.

Автономное просканировать систему

Несколько пользователей положительно откликнулись о данном способе, им удалось исправить свой BSOD с помощью «Защитника Windows». Чтобы реализовать задуманное, нужно загрузить систему в «Безопасном режиме», открыть «Параметры» – «Безопасность» и выбрать «Сканировать в автономном режиме». Есть неплохая вероятность, что это сработает.

Восстановить систему

Еще один способ, получивший положительные отклик пользователей. Он применим к ноутбукам, в частности к Samsung-устройствам. Суть заключается в следующем:

1. Выключить ноутбук и отключить накопитель.
2. Запустить компьютер и перейти в «Режим восстановления» (чаще всего клавишей F4).
3. Подключить SSD-накопитель и выбрать подходящий вариант восстановления.
4. Запустить SW Update и обновить BIOS.

Удалить недавно установленные программы

Если в недавнем прошлом было установлено программное обеспечение, способное нанести вред BIOS, стоит его удалить. В общем-то стоит убрать все сомнительные программы, а также те, которые активно работают или управляют системными файлами.

Настроить ACPI и AHCI

Нужно предупредить, что стандарт ACPI на самом деле нужен Windows и его отключение нежелательно. Компьютер после этого не сможет загрузиться, так как ACPI автоматизирует управление электропитанием компонентов ПК. Однако нередко срабатывает переключение его в режим уменьшенного энергопотребления. Пункт ACPI можно найти в BIOS и установить для него значение S1. Это решение особенно актуально для тех, у кого ошибка появляется после выхода из спящего режима. Еще может сработать выключение AHCI тоже через BIOS.

Деактивировать внешнее оборудование

В момент запуска системы после появления BSOD ACPI_BIOS_ERROR к нему должно быть подключено минимум оборудования. Лучше отключить практически все постороннее и уже подключать после полного запуска. Будет установлено необходимое программное обеспечение, а ошибка появляться не должна.

Отключить разгон

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

Проверка состояния оперативной памяти

Выход из строя одной из планок ОЗУ может стать причиной проблемы. Лучше продиагностировать оперативную память, это можно сделать как встроенными инструментами операционной системы, так и утилитой MemTest86. Рекомендуется использовать второй вариант, создав флешку с автозагрузкой.

Переустановить операционную систему

Если ошибка ACPI BIOS ERROR появилась в результате попытки установки системы, стоит изменить режим. К примеру, если инсталляция проходила в режиме совместимости, стоит опробовать Legacy и наоборот.

Большинство из перечисленных выше действий применимы Windows, Linux, Ubuntu и др. Unix-системам, поэтому скорее всего сработают везде. Если же ничего из перечисленного не помогло улучшить ситуацию, ошибка ACPI BIOS ERROR вызвана выходом из строя какого-то комплектующего. Чаще всего пользователи сталкиваются с поломкой оперативной памяти и процессоров. Стоит их продиагностировать в сервисном центре.

Источник

Настраиваем пользовательский синий экран смерти

Он посинел, ему плохо?

BSOD – реакция ядра на неразрешимую исключительную ситуацию. Если вы его видите, то это значит, что случилось что-то определенно нехорошее.

Среда ядра накладывает множество ограничений на свободу действий программиста: учитывай IRQL, синхронизируй доступ к разделяемым переменным, не задерживайся в ISR, проверяй любые данные из «юзерленда»… Нарушив хотя бы одно из правил, вы получите настоящий выговор из штампованных фраз в стандартном VGA-видеорежиме с худой палитрой.

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

В кернелмоде все иначе. Во-первых, кернелмодные соседи – уже соседи не по квартире, но по комнате. Между ними нет прочных стен, которые бы защитили одних жильцов от нетрезвых выходок других. При этом взаимосвязи кернелмодных модулей тонки и хрупки. Ядро и его компоненты – гигантские часы, с огромным количеством компонентов. И в этом соль: если один винтик поврежден, останавливается вся система. Конечно, есть модули, сбои которых логически никак не влияют на работу ОС. Можно было бы изолировать сбойный модуль – кое-где так делают, ну, вы знаете. Однако логика заключается в том, что ядерный компонент активно взаимодействует с другими компонентами и ядром ОС, следовательно, сбой в одном компоненте может привести к цепочке сбоев в других, в конечном счете разрушив все ядерные структуры, или, что еще хуже, повредить пользовательские данные. Кроме того, отлаживать такие затаившиеся баги крайне тяжело.

Тем не менее, допустим, вы – пользователь уровня «чайник». Какая вероятная реакция будет у вас при виде синего экрана?

Допустим теперь, что вы – системный администратор. Какая у вас реакция на «синяк»? Ну, до того, как вы начинаете читать код ошибки и все такое.

Пусть вы кернелкодер, и вам кучу раз приходилось видеть этот изощренный отладочный вывод. Что вам приходит в голову, когда вы видите его снова? Ну, кроме междометий.

А имеем за сим, с одной стороны, невозможность продолжить нормальное функционирование системы, с другой, – бесценные невосстанавливающиеся нервные клетки. Как быть? Перехват KeBugCheck не предлагать – мы все знаем, что из этого выйдет. До релиза Windows 8 с ее душевным DirectX BSOD’ом нужно еще подождать какое-то время. А пока что…

Сам себе Руссинович

Думаю, всем знакомо это имя. Руссинович классный, хоть и хитрит. Среди кучи полезных утилит от Sysinternals есть одна интересная – NotMyFault. Она может искусственно генерировать различные ошибки в режиме ядра, что, конечно же, отобразит BSOD. Кроме того, в ней есть интересная возможность – изменить цвет фона и шрифта экрана смерти. Эта утилита настолько крута, что даже поставляется вместе с исходником! Однако, как я уже говорил, Руссинович классный…

Я какое-то время не мог понять, что происходит: в заголовочном файле ioctlcmd.h есть такой код:

#define IOCTL_BSOD_COLOR (ULONG) CTL_CODE(FILE_DEVICE_MYFAULT, 0x10, METHOD_BUFFERED, FILE_ANY_ACCESS)

Но это единственное место, где есть след кода, отвечающего за изменение цвета экрана смерти. Файл драйвера myfault.c содержит в себе кулинарную книгу ядерных извращений без главного блюда! Но! Собранный драйвер, по-видимому, нужный код все-таки имеет, поскольку отрабатывает на ура. «Окей», – подумал я.

Отвлечемся на минутку. Прежде, чем вы задумаете что-то сплайсить в ядре, не поленитесь заглянуть на MDSN, поскольку callback-функций (функций обратного вызова) в ядре предостаточно. Так и с синим экраном: есть callback-функция, вызов которой происходит сразу после отображения синего экрана. Регистрируется она следующей функцией:

BOOLEAN KeRegisterBugCheckReasonCallback(
__out PKBUGCHECK_REASON_CALLBACK_RECORD CallbackRecord,
__in PKBUGCHECK_REASON_CALLBACK_ROUTINE CallbackRoutine,
__in KBUGCHECK_CALLBACK_REASON Reason,
__in PUCHAR Component
);

Эта callback-функция указывает причину своей регистрации: либо ей необходимо дописать что-то в дамп, либо отследить момент, когда дамп уже записан, либо, указав в качестве причины KbCallbackReserved1, мы можем быть вызваны «просто так». Параметр KbCallbackReserved1 является приватным и вызывается раньше всех остальных callback-функций при возникновении критических ошибок.

Кроме этой callback-функции есть и другая, похожая, которая регистрируется следующей функцией:

BOOLEAN KeRegisterBugCheckCallback(
__out PKBUGCHECK_CALLBACK_RECORD CallbackRecord,
__in PKBUGCHECK_CALLBACK_ROUTINE CallbackRoutine,
__in_opt PVOID Buffer,
__in ULONG Length,
__in PUCHAR Component
);

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

Снова к делу. Увидев в дизассемблерном листинге автоматически назначенное имя функции «CallbackRoutine», я даже и не знал, куда еще можно отправиться в поисках волшебного кода. И вот же он! … Стойте, что это? «Mov – out, mov – out». Не знаю, как у вас, а у меня было такое чувство, что меня обманули. Я ждал чудес и сказки. А тут Марк берет VGA-порты и через них меняет палитру. Именно палитру! Т. е. делает синий цвет, например, зеленым, так что фон окрашивается в зеленый цвет:

mov edx, 3C8h ; порт, в который записывается индекс цвета в палитре ЦАП
mov al, 4 ; был синий
out dx, al
mov al, 0x00003F00 ; станет зеленый (6 бит на цвет)
lea ecx, [edx+1] ; edx = 0x3C9 – порт для записи цветовых компонент
mov edx, ecx
out dx, al ; установить Red-составляющую
mov eax, 0x00003F00
shr eax, 8
out dx, al ; Green
mov eax, 0x00003F00
shr eax, 10h
out dx, al ; Blue

Ну что ж, в принципе тоже сойдет. Но хочется большего.

Наслаждайтесь мелочами

Анимированный экран загрузки ОС, в принципе, дает хорошее представление о том, что можно выжать из VGA-видеорежима. Можно даже догадаться о том, что код для отрисовки графики уже есть готовый где-то в ядре. Не буду томить: нас интересует семейство функций Inbv*. Обратите внимание на то, что некоторые из них даже являются экспортируемыми из ядра. На примере реверса KiDisplayBlueScreen можно разобраться, как пользоваться такими функциями:

if (InbvIsBootDriverInstalled())
<
InbvAcquireDisplayOwnership(); // теперь мы командуем
InbvResetDisplay(); // очищаем экран, переинициализируем палитру
InbvSolidColorFill(0, 0, 639, 479, 4); // заливаем все синей краской
InbvSetTextColor(15); // а пишем белой
InbvInstallDisplayStringFilter(0); // сбрасываем callback-функцию на отображение текстовой строки
InbvEnableDisplayString(TRUE); // разрешаем писать строки
InbvSetScrollRegion(0, 0, 639, 475); // сужаем рамки экрана
…
InbvDisplayString( «Hello world!» ); // выводим текст
…
>;

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

Но самая примечательная функция – InbvBitBlt:

VOID NTAPI InbvBitBlt(IN PUCHAR Buffer, IN ULONG X, IN ULONG Y)

Догадываетесь? Да, она непосредственно отрисовывает BMP-изображение (читай, BMP-файл с 256 цветами без файлового заголовка)! Проблема только в том, что она неэкспортируемая. К счастью, она – всего лишь обертка аналогичной функции VidBitBlt. Роль обертки заключается только в синхронизации отрисовки, что, в общем-то, нас не сильно интересует. А VidBitBlt экспортируется из модуля bootvid.dll, который, как можно догадаться по названию, развлекает пользователя загрузочной анимацией. Так что в путь, мои дорогие! Абсолютно легально ищем загруженные модули, парсим таблицу экспорта и получаем указатель на эту волшебную функцию. А дальше вы ограничены только своей фантазией.

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

Источник