Replace the power key fpcb что значит

При включении ноутбука вылезает какое-то предупреждение

Регистрация 13.01.2012 Адрес Ачинск, Красноярский край Сообщений 280 Репутация 10

Привет всем. У жены на ноуте Dell Inspiron при включении вылезает какое-то предупредупреждение белыми буквами на чёрном экране. Текст следующий:

The AC power adapter wattage and type cannot be determined.
The battery not charge.
The system will adjust the performance to match the power available/

Please connect a Dell 90 W AC adapter or greater for the best system performance.
Strike the F3 key (before F1 or F2 key) if you do not want to see power warning message again.
Strike the F1 key to continue, F2 to run setup utillity

До этого пару раз было такое. Но ноут использовался без батареи от сети. При появлении этого предупреждения она нажимала F1. При следующем включении это так же появлялось. Я попробовал тогда вариант просто тупо выдергивал шнур из ноута, при следующем включении оно уже не вылазило. После этого вставляли батарейку, всё нормально работало, батарея заряжалась уровень заряда показывался. То есть после выдергивания шнура всё становилось норм. И вот за пол года третий раз это сообщение появилось, решил разобраться.
В общем нажал я F1 комп включился (стоит батарея сейчас и ноут от сети работает, причём комп стали использовать от сети с батареей уже как несколько дней). Значит включился ноут. Батарея показывает уровень заряда 100%. Вытаскиваю шнур, показывает 99%. Решил немного подсадить её и посмотреть будет ли она заряжаться. Разрядил батарею до 97%. Воткнул шнур, показывает батарея заряжена на 100%. Выключил ноут. Включил, это предупреждение не появлялось. Батарея пишет 100% заряжена. Вытащил шнур, пишет 97%. Разрядил до 96%, воткнул шнур, пишет 100%. То есть батарея не заряжается. Что это за ерунда? И почему не зяряжается батарея а сообщение не выдаётся больше? Ведь раньше когда батарея не стояла, при появлении этой ошибки я тупо выдирал шнур и потом опять включал комп. Комп какое-то время работал от сети, когда надо было жена вставляла батарею и работала от неё. При необходимости заряжала её. Что делать?))

Источник

Системное администрирование и мониторинг Linux/Windows серверов и видео CDN

Статьи по настройке и администрированию Windows/Linux систем

• Полезное
  • Карта сайта
  • Мой сайт-визитка
• Рубрики
  • Linux
    • VoIP
    • Безопасность
    • Видеопотоки
    • Системы виртуализации
    • Системы мониторинга
  • Windows
  • Интересное
  • Сеть и Интернет
• Мета
  • Войти
  • RSS Feed

S.M.A.R.T. (часть 2). Мониторинг BBU RAID контроллеров

В предыдущей статье шла речь об установки megacli для мониторинга дисков под LSI 2108 Megaraid контроллеров. Сейчас же я хочу немного описать мониторинг батареи (BBU) для RAID контроллеров в целом. Какие шаги нужно предпринимать и как не наделать лишних проблем для себя при возникновении ошибок или неполадок с BBU (Battery Backup Unit).
Состояние батареи нужно периодически проверять. Для RAID контроллеров этот компонент вообще может отсутствовать, так как его основное предназначение — это держать в кэше данные, которые еще не записались на диск, т.е. сохранение целостности данных при сбое питания (внезапное отключения подачи электричества).
На данный момент, почти все рейд контроллеры поддерживают кэширование данных на уровне контроллера. Т.е. каждый физический диск имеет свой кэш плюс кэш контроллера. Такой подход повышает производительность системы при сохранение большого количества данных или же при очень высоком уровне отдачи контента конечным пользователям.
Если рейд контроллер умеет кэшировать данные, то на нем можно настроить политику считывания, записи и буферизации данных.

Read Policy: Политика считывания указывает каким образом контроллеру нужно считывать сектора логических устройств при поиске нужной информации.

• Read-Ahead. Когда используется политика упреждающего (на перед) чтение, контроллер включает режим последовательного считывания секторов с логических дисков при поиске данных. Производительность повышается, если данных записаны последовательно, сектор за сектором на логические диски.
• No-Read-Ahead. Режим отключения политика последовательного считывания данных на контроллере.
• Adaptive Read-Ahead. Когда включена адаптивная политика упреждающего чтение, контроллер инициализирует упреждающее чтение только если пришел запрос на очень часто считываемые данные, которые записаны последовательно на логический диск. Если же запрашиваются рендомные(записанные в случайной последовательности) данные — контроллер переходит в режим no-read-ahead.

Про политику записи и буферизации лучше читать в оригинале.
Write Policy: The write policies specify whether the controller sends a write-request completion signal as soon as the data is in the cache or after it has been written to disk.

• Write-Back. When using write-back caching, the controller sends a write-request completion signal as soon as the data is in the controller cache but has not yet been written to disk. Write-back caching may provide improved performance since subsequent read requests can more quickly retrieve data from the controller cache than they could from the disk. Write-back caching also entails a data security risk, however, since a system failure could prevent the data from being written to disk even though the controller has sent a write-request completion signal. In this case, data may be lost. Other applications may also experience problems when taking actions that assume the data is available on the disk.

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

• Write-Through. When using write-through caching, the controller sends a write-request completion signal only after the data is written to the disk. Write-through caching provides better data security than write-back caching, since the system assumes the data is available only after it has been safely written to the disk.

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

Cache Policy: The Direct I/O and Cache I/O cache policies apply to reads on a specific virtual disk. These settings do not affect the read-ahead policy. The cache policies are as follows:

• Cache I/O. Specifies that all reads are buffered in cache memory.

Все считанные данные буферизируются в кэше.

• Direct I/O. Specifies that reads are not buffered in cache memory. When using direct I/O, data is transferred to the controller cache and the host system simultaneously during a read request. If a subsequent read request requires data from the same data block, it can be read directly from the controller cache. The direct I/O setting does not override the cache policy settings. Direct I/O is also the default setting.

Данные не буферизируются в кэше.

Теперь перейдем к практике на примере мегарейд контроллера.
Для начала нужно проверить логи:

Если вывелась куча строк типа:

… первым делом проверяем статус BBU установленной тулзой:

Убеждаемся, что проблема есть по параметрам — Battery Replacement required : Yes и Battery State: Failed. Перед паникой и заменой, нужно дополнительно посмотреть параметр Run time to empty: Battery is not being charged. — Это означает, что нужно ее зарядить, так как она еще ни разу не заряжалась и состояние заряда :
Relative State of Charge: 96 %
Absolute State of charge: 5161 %

Значит первым делом нужно попробовать зарядить BBU и если не помогло — проверить все ли правильно подсоединено. Если проблема не решилась — нужно проводить замену.
Можно пользоваться этими шагами для определения и решения проблемы с BBU:

Num	Type	Description	Indication	Actions
2	F	Unable to recover cache data from TBBU	A,B	1
10	F	Controller cache discarded due to memory/battery problems	A,B	1
11	F	Unable to recover cache data due to configuration mismatch	A,B,C	1
146	W	Battery voltage low	N/A	1,2
162	W	Current capacity of the battery is below threshold	B	1,2
150	F	Battery needs replacement — SOH Bad	D	1,2
154	W	Battery relearn timed out	D	1,2
161	W	Battery removed	D	1,2
200	C	Battery/charger problems detected: SOH Bad	D	1,2
211	C	BBU Retention test failed!	G	1,2
142	W	Battery Not Present	N/A	1,2
253	W	Battery requires reconditioning: please initiate a LEARN cycle	N/A	3
307	W	Periodic Battery Relearn is pending. Please initiate manual leam cycle as Automatic leam is not enabled	H	3
195	W	BBU disabled: changing WB to WT	E, F	4,5
330	W	Detected error with the remote battery connector cable	N/A	6

Type:
F= Fatal. W=Warning. C=Critical.

Indication:
A) Sudden power loss or system hang, when BBU is not fully charged and Write Back mode is forcefully enabled
B) The extended power loss to the system has resulted in the BBU being thoroughly discharged before power recovery.
C) The specific virtual drive configuration may have changed, so that previous virtual drive information cannot be recovered from BBU data
D) BBU failure or it is installed or connected incorrectly.
E) BBU not connected or not fully charged.
F) If WB mode was enabled before BBU charge, then it will be automatically re-enabled after the charge
G) BBU not able to keep cache data long enough during system power off.
H) The battery requires a relearn cycle to re-calibrate itself.

Action
1) Check the BBU status to see if the BBU should be charged or replaced.
2) Check the cable, power connection, backplane, SATA/SAS port, and make sure the BBU is installed and connected correctly.
3) Use RAID Web Console 2 or RAID BIOS Console to initiate a battery re-learn cycle.
4) Wait until the BBU is fully charged before rebooting the system.
5) WB can still be used through Bad BBU mode under RAID Web Console 2 but unexpected
power failure may cause data loss.
6) Check if the remote battery connector cable is properly connected and functional.

Источник

Укрощаем UEFI SecureBoot

Введение

С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM’ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.

Тестовая конфигурация

Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:

1. AMI, они же «треугольные«: congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)

2. Insyde, они же «квадратные«: Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)

3. Phoenix, они же «полукруглые«: Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)

Об интерфейсах для настройки SecureBoot

Готовим плацдарм

Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM’ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.

Генерируем собственные ключи для SecureBoot

Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.

Генерируем ключевые пары

Конвертируем открытые ключи в формат ESL

Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.

Подписываем ESL-файлы

С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:

Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:

Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.

Подписываем загрузчик

Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.

В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.

Укрощение строптивого

AMI AptioV

У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:

Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:

Выбираем нужную нам переменную, после чего сначала предлагают выбрать между установкой нового ключа и добавлением к уже имеющимся, выбираем первое:

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

Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:

Затем нужно подтвердить обновление файла, и если все до этого шло хорошо, в результате получим лаконичное сообщение:

Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:

Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:

Готово, сохраняем настройки и выходим с перезагрузкой, после чего пытаемся загрузиться с нашей флешки и видим вот такую картину:

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

Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.

Insyde H2O

Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.
Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:

После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:

Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool‘а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:

Выбираем Edit Keys, попадаем в меню выбора хранилища:

Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:

Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):

Ну вот, одна часть SecureBoot’а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.

Phoenix SCT

Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:

Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool‘а, иначе на этой платформе его запустить не получится:

Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool‘а заканчивается вот так:

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

Заключение

В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.

Источник