Не загружается Windows 7 после установки обновления KB3045999

После установки обновления KB3045999 перестает запускаться Windows 7. При этом показывает BSOD с сообщением:

STOP: c0000145 {Application Error}
The application was unable to start correctly (0xc000000d). Click OK to close the application.

Если верить этому, то проблема касается AMD64 инсталляций и активатора ODIN.

Можно попробовать откатиться на точку восстановления, а можно удалить само обновление. Тут нашлась инструкция под это дело. На всякий случай продублирую последовательность действий себе:

• Загружаемся в режиме "Устранение неполадок компьютера" (нажать F8 в самом начале загрузки) и запустить консоль
• Просматриваем список пакетов обновлений:

  DISM /Image:E:\ /Get-Packages

  где "E:\" – буква диска, на котором установлена система
• Находим и копируем название нашего пакета "KB3045999". Выделяем и копируем комбинацией Ctrl+C (Package_for_KB3045999~31bf3856ad364e35~amd64~~6.1.1.1)
• Удаляем его:

  DISM /Image:E:\ /Remove-Package /PackageName:Package_for_KB3045999~31bf3856ad364e35~amd64~~6.1.1.1

• Жмем Enter, наблюдаем прогресс 100%, дожидаемся надписи "the operation completed successfully", перегружаемся.

Странно, что не получается почитать описание обновления.

Вышел Debian 8 Jessie

Вчера вышел Debian 8 Jessie. Теперь стою перед выбором: обновляться или поставить систему с нуля, чтобы заодно перейти на amd64. Дело в том, что система, установленная на моем ноутбуке берет свое начало еще с Debian Etch и уже пережила несколько замен железа. Наверняка найдется много мелочей к которым я уже привык, но они потеряются после свежей установки. Хотя с другой стороны это хороший повод наконец-то задокументировать все эти кастомизации.

Обновление прошивки штатной магнитолы Renault Sandero Stepway

Сегодня обновил прошивку штатной магнитолы, которой комплектуется Sandero Stepway первого поколения. Модель магнитолы Daewoo AGC-1220RF-A и с прошлой прошивкой у магнитолы были проблемы с поддержкой кириллицы в телефонной книге. В MP3 тегах и файловой системе кириллицу отображало, а в телефонной книге - кракозябли вместо имен.

Перебивать контакты на латиницу желания не было и как раз подвернулось видео, где показан процесс обновления прошивки магнитолы в Lada Largus. Насколько я знаю там стоит такая же магнитола.

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

На всякий случай отформатировал заново флешку в fat32, скопировал файл Renault_A1130902_V0057.cab (md5: 59be0af5420caa2a1499ff2dfd714ec8) в корень флешки и приступил к обновлению.

Как и на видео версия текущей прошивки в моей магнитоле была "00039", что придало больше уверенности в успехе. На 50% процентах процесс обновления призадумался, но секунд через 10 пошел дальше.

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

С новой прошивкой записи в телефонной книге стало показывать правильно. На всякий случай проверил кириллицу в навигаторе и тегах - все работает.

ldap_bind(): Unable to bind to server: Protocol error

Делаю страничку для показа информации о сотрудниках из OpenLDAP. Столкнулся с тем, что простейший код не может подключиться к LDAP серверу, хотя binddn и bindpw верные - это было проверено через ldapsearch. Как оказалось по-умолчанию php-ldap использует LDAPv2, а наш LDAP сервер настроен на LDAPv3. Чтобы решить эту проблему достаточно добавить в код:

ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3);

Не обновляйте ploop на 1.13-1

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

# vzctl snapshot-delete 1101 --id 9c585491-c98b-42a5-8002-2387eee11aa1
Deleting snapshot {9c585491-c98b-42a5-8002-2387eee11aa1}
Storing /vz/private/1101/Snapshots.xml.tmp
Error in check_snapshot_mount (ploop.c:3722): Snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41} is busy by device(s): /dev/ploop17343 
Failed to delete snapshot: Error in check_snapshot_mount (ploop.c:3722): Snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41} is busy by device(s): /dev/ploop17343  [17]
Failed to delete snapshot {9c585491-c98b-42a5-8002-2387eee11aa1}

Версия ploop:

# rpm -qa \*ploop\*
ploop-lib-1.13-1.x86_64
ploop-1.13-1.x86_64

Если контейнер предварительно остановить, то снапшот удалится. Похоже это связано с неудачным фиксом #2887. Для решения проблемы достаточно откатиться на ploop 1.12.2:

# wget http://download.openvz.org/current/prev/ploop-1.12.2-1.x86_64.rpm http://download.openvz.org/current/prev/ploop-lib-1.12.2-1.x86_64.rpm
# yum downgrade ploop*1.12.2*.rpm

UPDATE: Запостил баг.

Закончился второй этап Yandex.Root 2015

Вчера участвовал во втором этапе Yandex.Root 2015. Задания были сложнее, но и интереснее одновременно. Особенно меня порадовало задание "Exec", где нужно было запустить два бинарника, скомпилированных про разные архитектуры: sparc и powerpc. И при этом нужно создать видимость, что процессы работают в одной системе (один процесс слушает tcp порт, а второй unix сокет). В этом задании много времени потратил на поиск правильного qemu под centos 7. В итоге поставил chroot с debian wheezy и доделал задание в нем.

Пришлось повозиться над восстановлением ejabberd и прикручиванием к нему логов (делал через mod_log_chat).

Почтовые задания и couchdb не трогал, т.к. уже хотелось спать, да и времени почти не осталось. А вот задание про Git делать начал, но как нарисовать hook для реализации appendonly пока не знаю. С интересом жду, когда выложат разбор заданий.

В итоге по двум играм мой результат:

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

Разбор заданий с Yandex.Root 2015

В четверг принял участие в Yandex.Root 2015. Команду собрать не удалось, так что играл в одиночку. Не понравилось, что игра проводится в будний день - пришлось играть короткими урывками. В самом начале игры были проблемы с инфраструктурой Yandex'а: не было возможности получить список заданий, рвалось подключение к VPN и не работала проверка результатов.

У меня получилось выполнить все кроме "Binary", "Strange protocol" и "MongoDB". С mongodb я не знаком и времени разбираться не было, а вот Binary и Strange protocol были действительно интересными.

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

При выполнении "strange protocol" я быстро поднял echo сервер через xinetd и завис на попытке дебажить отказ. Для тестирования я пользовался netcat:

$ nc -u localhost 13000

Но при попытке увидеть эхо ответ был только таймаут.

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

Yandex.Root сегодня

Сегодня в 09:00 UTC начинается квалификационный этап Yandex.Root 2015 - попробую сыграть, хотя и слишком поздно вспомнил об этом.

Перестала работать проверка https в zabbix-proxy для некоторых хостов после апгрейда на Debian Wheezy

После обновления одного из серверов до debian wheezy (раньше там был squeeze-lts) появилась проблема в работе zabbix-proxy, который установлен на этом сервере. После обновления системы и перезагрузки zabbix отрапортовал о проблемах с https на двух хостах, которые мониторились с помощью zabbix-proxy.

Проверил браузером работу https на этих хостах - все в порядке. Zabbix-proxy проверяет больше десятка хостов, на которых есть https, но ложные срабатывания есть только на двух. Причем сами хосты не обновлялись и все было в порядке, пока zabbix-proxy работал на squeeze-lts.

Поискал в гугле и наткнулся на ветку в форуме, где описана аналогичная проблема. Включил DebugLevel=4 в zabbix-proxy и выловил описание проблемы в логе zabbix-proxy:

27111:20150405:124028.523 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error
27109:20150405:124127.938 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error
27111:20150405:124128.978 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error
27108:20150405:124227.737 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error

Пробую натравить wget на один из проблемных хостов:

$ wget --no-check-certificate -O /dev/null  https://example.com/
--2015-04-05 14:59:49--  https://example.com/
Resolving example.com (example.com)... 192.168.1.14
Connecting to example.com (example.com)|192.168.1.14|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

Поиск по фразе "GnuTLS: A TLS warning alert has been received." привел меня к двум багрепортам в debian: #738625 и #686837.

Как оказалось на обоих хостах отсутствовала конфигурация ServerName или ServerAlias для example.com и example.net. Поскольку используются *.*.example.com и *.example.net, то проблема оставалась незамеченной, а после обновления сервера - выплыла наружу. После добавления конфигурации для example.com и example.net все пришло в норму.

Бывает и так

Первый раз встречаю кабель в котором отметки длины идут не относительно длины бухты:

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

Удаление systemd в Debian Jessie/Sid

В одном из контейнеров OpenVZ, недавно обновленном до Jessie, начались проблемы со временем захода в контейнер по SSH. Почитал логи и нашел:

$ egrep 'time.*out' /var/log/auth.log
Apr  1 09:49:27 debian8 sshd[16956]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 10:46:52 debian8 sshd[16986]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 10:46:52 debian8 systemd-logind[172]: Failed to start user service: Connection timed out
Apr  1 10:47:17 debian8 systemd-logind[172]: Failed to start session scope session-10.scope: Connection timed out (null)
Apr  1 11:03:19 debian8 sshd[16998]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 11:50:56 debian8 sshd[17019]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Apr  1 11:51:13 debian8 sshd[17024]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Началось после suspend'а контейнера. Скорее всего какая-то нестыковка OpenVZ и systemd, но разбираться в этих нюансах нету времени.

Тут нашлась инструкцию по удалению systemd из Jessie/Sid. На всякий случай задублирую ее себе:

Установить SysV init

$ sudo aptitude install --without-recommends sysvinit-core sysvinit sysvinit-utils

Теперь важно сначала перезагрузить систему, чтобы инициализация прошла через SysV init. Затем удалить пакет systemd и запретить его установку в будущем

$ sudo aptitude purge systemd
$ echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' | sudo tee /etc/apt/preferences.d/no-systemd

После удаления systemd контейнер пришел в норму.

UPDATE: Если попытаться удалить systemd из десктопной инсталляции, то по зависимостям предложит удалить много чего. Чтобы избежать этого нужно установить пакет sysvinit-core и перезагрузиться.

$ sudo apt-get install sysvinit-core
$ sudo reboot