четверг, 30 апреля 2015 г.

Не загружается 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", перегружаемся.

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

воскресенье, 26 апреля 2015 г.

Вышел Debian 8 Jessie


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

пятница, 17 апреля 2015 г.

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

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

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

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

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

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


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

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

четверг, 16 апреля 2015 г.

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);

среда, 15 апреля 2015 г.

Не обновляйте 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 пока не знаю. С интересом жду, когда выложат разбор заданий.

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

https://root.yandex.com/team/view/blackice

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

суббота, 11 апреля 2015 г.

Разбор заданий с 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

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

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

четверг, 9 апреля 2015 г.

Yandex.Root сегодня

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

воскресенье, 5 апреля 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 все пришло в норму.

четверг, 2 апреля 2015 г.

Бывает и так

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


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

среда, 1 апреля 2015 г.

Удаление 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