Обновление Xiaomi Mi4c до LineageOS 14.1

Решил поделиться впечатлениями от обновления своего Xiaomi Mi4c с CyanogenMod 13.1 до LineageOS 14.1. Основная причина обновления - попытка решить проблему с внезапным отключением телефона при заряде батареи 20-30%.

Для обновления использовал вариант прошивки LineageOS от Team Superluminal, firmware от miui 8.2.3.0 и заодно обновил TWRP до 3.1.1 (пришлось откатить TWRP на 3.0.2-0, т.к. первый же OTA update привел к boot loop) . Уже прошло две недели с момента обновления и можно подвести итог:

• Решилась главная проблема с отключением телефона при заряде батареи ниже 30%. Как и положено на 15% я получаю всплывающее уведомление, которое повторяется на 5% и потом телефон разряжается до нуля и выключается.
• Работает активация/деактивация второй симки. В CyanogenMod 13.1 не было возможности деактивировать вторую симку и она постоянно оставалась активной. В качестве второй симки у меня установлена туристическая симка от GoodLine и не хочется "случайно" звонить через нее.

Теперь касательно плюшек новой версии Android

• Я получил последнюю стабильную версию Android 7.1.2 (security patch level: June 5, 2017).
• Теперь при звонке телефон автоматически включает режим "Do not disturb" и новые смски или уведомления от aNag более не жужжат в ухо во время разговора.

P.S. Заметил что если включить русский язык в настройках интерфейса, то Mi Fit не показывает контакт при входящем звонке или SMS. В этом случае в Mi Fit просто нет нужного пункта. Все приходит в норму, если выбрать английский язык.

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

Прошляпил обновление signing key для моего репозитария

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

В APT ошибка выглядит так:

Сущ:10 http://www.tataranovich.com/debian jessie Release
Ошк:13 http://www.tataranovich.com/debian jessie Release.gpg
  Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 
Чтение списков пакетов… Готово
W: Произошла ошибка при проверке подписи. Репозиторий не обновлён и будут использованы предыдущие индексные файлы. Ошибка GPG: http://www.tataranovich.com/debian jessie Release: Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 
W: Не удалось получить http://www.tataranovich.com/debian/dists/jessie/Release.gpg  Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 

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

sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-keys 0x836CC41976FB442E
sudo apt-get update

Кроме этого можно установить пакет tataranovich-keyring отсюда. В этом случае больше шансов, что ситуация не повторится.

В процессе обновления пакета заметил, что теперь ключ нужно класть в /etc/apt/trusted.gpg.d, а не добавлять через apt-key в postinst.

Перестал подключаться PPTP через NAT

Имеется домашний сервер, который маршрутизатор домашней сети и еще много чего, работающий на Debian Jessie. После обновления ядра со штатного 3.16.43-2+deb8u1 до 4.9.30-2~bpo8+1 из backports перестало работать подключение к корпоративной сети через PPTP. Если перезагрузить сервер на старое ядро, то PPTP работает.

Нужные модули загружены:

$ grep pptp /etc/modules
nf_nat_pptp
nf_conntrack_pptp

$ lsmod | awk '/pptp/ {print $1}'
nf_nat_pptp
nf_nat_proto_gre
nf_conntrack_pptp
nf_conntrack_proto_gre
nf_nat
nf_conntrack

Помучился немного и спросил в рассылке debian-russian. Добрые люди подсказали два способа решить проблему:

Добавить дополнительное правило в netfilter:

$ sudo iptables -t raw -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp

или включить conntrack helper:

$ sudo sysctl -w net.netfilter.nf_conntrack_helper=1

Больше информации по теме можно почерпнуть тут.

Xiaomi Mi4c внезапно отключается при заряде батареи 20-30%

Не могу вспомнить когда это случилось первый раз, но похоже мой Xiaomi Mi4c взял привычку отключаться при остаточном заряде 20-30%. В произвольный момент, когда батарея показывает ниже 40% телефон вдруг решает что заряд около нуля и штатно выключается.

На графике батареи видно что с примерно 25% батарея мгновенно "разрядилась" до нуля, а после повторного включения телефона отработала еще несколько часов. Причем повторилась старая проблема с продолжающимся разрядом батареи при подключенном зарядном. Калибровка батареи не помогла - я пробовал полностью разрядить батарею, потом зарядить до 100%, калибровать, разрядить до нуля и снова зарядить до 100%.

В интернете встречаются упоминания, что такое поведение не редкость даже у новых телефонов: произвольное отключение телефона происходит при заряде батареи 20-60%. Похоже это связано с проблемами в прошивке (сейчас у меня установлен CyanogenMod 13.1 от Team Superluminal), т.к. у меня эту проблема появилась относительно недавно и скорее всего связана с последним обновлением прошивки в начале этого года.

Зайдя на форум team superluminal узнал, что теперь они предлагают LineageOS 14.1 для Mi4c - нужно будет попробовать эту прошивку при случае.

Обновлено 5/09/2017: Проблема с внезапным отключением решилась обновлением прошивки до LineageOS 14.1.

Разрядился телефон будучи подключенный к зарядному устройству

Не первый раз замечаю что мой Xiaomi Mi4c, подключенный перед сном к зарядному устройству (остаточный заряд 20-30%), к утру разряжается почти до нуля или совсем отключается.

Сегодня утром аккумулятор показывал 2% заряд и я сделал скриншот

Перед подключением зарядного было больше 20% заряда, но после отключения экрана телефон не уснул. Зарядное устройство и кабель - родные.

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

Спустя год заметил что отвалился IPv6 на сервере

В процессе прикручивания сертификата Let's Encrypt к своему сайту обнаружил что он более недоступен по IPv6 извне. Причем судя по статистике траффика в панели управления сервером это произошло еще в июне 2016. Сервер имеет IPv4/IPv6 стек и последний был настроен по принципу "пусть будет". А сейчас при валидации домена Let's Encrypt не может соединиться на IPv6 адрес сайта и проверка не проходит.

Доступность сервера по IPv4 проверяется в nagios из дома, а вот проверку доступности IPv6 пришлось добавить в виде костыля (нет у меня другого сервера с IPv6):

command['check_ipv6']=/usr/lib/nagios/plugins/check_http -6 -H google.com

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

$ ip -6 a
1: lo: <loopback> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <broadcast> mtu 1500 qlen 1000
    inet6 2a01:4f8:d13:2742::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:14ff:fe01:1dba/64 scope link 
       valid_lft forever preferred_lft forever

$ ip -6 r
2a01:4f8:d13:2742::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2a01:4f8:d13:2742::1 dev eth0  metric 1024

$ ip -6 neigh
fe80::3285:a9ff:fea4:1ff7 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE
2a01:4f8:d13:2742::1 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE

$ ping6 -c 5 2a01:4f8:d13:2742::1
PING 2a01:4f8:d13:2742::1(2a01:4f8:d13:2742::1) 56 data bytes
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=1 ttl=64 time=0.281 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=3 ttl=64 time=0.250 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=4 ttl=64 time=0.223 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=5 ttl=64 time=0.148 ms

--- 2a01:4f8:d13:2742::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.148/0.237/0.284/0.050 ms

$ ping6 -c5 ipv6.google.com
PING ipv6.google.com(waw02s06-in-x0e.1e100.net) 56 data bytes

--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4033ms

Посмотрю что завтра ответит тех. поддержка Hetzner.

UPDATE 31/05/2017

Ответ из техподдержки:

Thanks for trying a reboot first. We've now rechecked the routing of your IPv6-net and we were able to find an issue, which we fixed directly and your server is now back online using the mentioned IPv6.

IPv6 снова работает и мне удалось установить сертификат Let's Encrypt для моего сайта.

Обновление BIOS на Dell Latitude E6430

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

После публикации информации об уязвимости в Intel AMT CVE-2017-5689 (INTEL-SA-00075) отправился на сайт Dell проверить апдейты. На тот момент обновление прошивки для моего Latitude E6430 еще не было выпущено, но в планах значилось начало июня.

На днях проверил обновления еще раз - уже доступна прошивка A21 с исправлением уязвимости. Последний раз обновлял BIOS в ноутбуке сразу после покупки и потому там установлена старая версия A16.

Для обновления скачиваю все доступные прошивки от A16 до A21, которые предназначены для Latitude E6430 (A16, A17, A18, A20, A21) и создаю загрузочный образ FreeDOS, содержащий в себе скачанные прошивки (загрузочный образ можно скачать тут).

Убедидесь что ваша флешка видна в системе как /dev/sdb. В противном случае рискуете затереть системный диск!
 
Несколько команд для скачивания образа и заливки на флешку:

$ wget http://www.tataranovich.com/public/dell/{e6430_bios_update.img.gz,MD5SUMS}
$ md5sum -c MD5SUMS
$ gunzip e6430_bios_update.img.gz
$ sudo dd if=e6430_bios_update.img of=/dev/sdb

Не продолжайте обновление, если не совпадает контрольная сумма для образа диска!

Далее можно продолжать обновление по аналогии.

Посколько в installation guide для прошивки нет ничего про запрет сквозного обновления, то для ноутбука жены (у нее тоже Latitude E6430) выбрал вариант обновления с версии A16 до A21. Весь процесс обновления занял минут 5 и завершился без ошибок.

А вот с моим ноутбуком такой финт не прошел. На этапе обновления "Sending Intel(R) Management Engine Firmware Update" произошла ошибка "ME FW Update Failed: Internal error: FWU_Buffer". После этого обновление продолжилось и завершилось без ошибок.

Я пробовал гуглить ошибку, но нашел только что ее исправили в обновлении A17. Накатываю прошивку версии A17 - обновилось без проблем. Потом настает очередь A18, A20 и снова A21. В этот раз обновление "Management Engine Firmware" прошло без ошибок.

До обновления версия Intel Management Engine Firmware была 8.1.40.1416, а после установки прошивки A21 стала 8.1.71.3608.

Кстати еще нашел утилиту mei-amt-check для проверки версии AMT:

$ git clone https://github.com/mjg59/mei-amt-check.git
$ cd mei-amt-check
$ make
$ sudo ./mei-amt-check
Intel AMT is present
AMT is unprovisioned

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