Жене надоело, что компьютер постоянно выключается, попросила меня или починить его или перенести все данные на ноутбук, который я по лету сдавал в ремонт, но так и не добрался его проверить. Поработав с компьютером, пришел к заключению, что виной внезапных отключений является блок питания. Посмотрел характеристики ноутбука — оказалось, что он намного мощней компьютера, поэтому предпочел перенести систему на него. Но железо этих двух компьютеров сильно различалось, поэтому обойтись «малой» кровью не удалось. К счастью в интернете на сайте «мелкомягких» попалась статья, где подробно разъяснялось как это сделать при помощи программы Sysprep. Попробовал — все прошло успешно. Ровно до того момента, пока я не вставил жесткий диск в ноутбук. Система просто отказалась загружаться. Точнее будет сказать, что она загружалась, но на одном из этапов подготовки к работе сообщала, что у нее не получается его выполнить и, мол, давай перезагрузимся. И так по кругу.
\nДальнейший поиск в интернете показал, что одной из причин такого поведения может быть антивирус. И верно, я его не удалял перед подготовкой системы к переносу. И корректно удалить его уже не получится. Хм, если не получается «по хорошему», будем пробовать «по плохому». Удалил папки с файлами антивируса, внес изменения в реестр, перезагрузил ноутбук. На этот раз все этапы были завершены корректно.
\nНо это были «мелочи», по сравнению со следующими проблемами. Старая проблема с видеокартой осталась: при установке драйверов на Windows 7 x64 система «падала» в BSOD. При этом, работая в Linux на этом ноутбуке, проблем не возникало.
\nНа следующий день, уже на работе, решил попробовать другую ОС. Поставил «десятку», несмотря на мое крайне плохое к ней отношение. После того, как она скачала и установила драйверы для видеокарты, Windows снова «словила» BSOD. Перезагрузила ноутбук и попробовала исправить проблему. Так как я уже потерял надежду, что проблем с ноутбуком не будет, то не стал прерывать процесс. Неожиданно, но после очередной перезагрузки система заработала. Зашел в диспетчер устройств, посмотрел на используемый драйвер для видеокарты — нет, не стандартный, а ATI. Хм, интересно...
\nВ общем, система пока ставит все обновления, потом буду накатывать все нужные программы.<\/p>\n",
"date_published": "2018-10-02T10:42:11+07:00",
"date_modified": "2018-10-02T10:42:02+07:00",
"tags": [
"10",
"sysprep",
"windows",
"видеокарта",
"исправление",
"перенос",
"проблема",
"система",
"тест"
],
"_date_published_rfc2822": "Tue, 02 Oct 2018 10:42:11 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "221",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "209",
"url": "https:\/\/www.kini24.ru\/all\/delo-dvizhetsya\/",
"title": "Дело движется",
"content_html": "
«Облако» было починено очень просто — изменением прав доступа к каталогу с файлами. Следом возникла другая ошибка — невозможность загрузить любой файл в него. Логи показали, что в этом повинен модуль защиты, который не пропускал файлы размером более 128 Кб. Исправил.
\nЗеркало баз NOD32, к сожалению, пока что починить не получилось. Но, похоже, что я наткнулся на возможную причину некорректной проверки ключей. Надо списаться с автором скрипта.
\nЕще один момент, который я поначалу упустил из вида: сервер с контактами и задачами. С ним пришлось повозиться. В итоге все дело оказалось в том, что php-fpm не передает заголовки авторизации и, соответственно, не отправляет данные (логин пользователя и пароль). Этот момент оказался описан в документации к baikal, поэтому на исправление ошибки ушло немного времени. Возможно, что примерно такая же ситуация обстоит и с проверкой ключей NOD32 на их серверах.
\nДолжен отметить, что связка apache-mpm-worker + FastCGI меня очень радует скоростью работы. Если раньше при работе с клиентом Nextcloud на телефоне приходилось ждать пока обновится\/загрузится содержимое каталога, то теперь это происходит едва не мгновенно. Видимо, сказывается «тлетворное» влияние HTTP\/2 :-)<\/p>\n",
"date_published": "2018-08-16T14:45:57+07:00",
"date_modified": "2018-08-16T14:45:54+07:00",
"tags": [
"apache",
"fastcgi",
"http\/2",
"исправление",
"ошибка",
"сервер",
"скорость"
],
"_date_published_rfc2822": "Thu, 16 Aug 2018 14:45:57 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "209",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "123",
"url": "https:\/\/www.kini24.ru\/all\/oshibka-v-transporte-mrim\/",
"title": "Ошибка в транспорте mrim",
"content_html": "
После обновления системы и перезагрузки сервера транспорт агента mail.ru не «завелся». После недолгих поисков обнаружилось, что Openfire по какой-то причине слушает порты по TCPv6, а на «четверку» он забил. Пришлось внести маленькую корректировку в файл конфигурации mrim.conf:<\/p>\n
server = 127.0.0.1<\/code><\/pre>заменить на<\/p>\n
server = localhost<\/code><\/pre>Ключ -d тоже не сработал, пришлось снова перезагружать сервер для запуска транспорта. Надо как-то это исправить — не буду же я каждый раз для перезапуска транспорта перезагружать систему.<\/p>\n",
"date_published": "2017-11-16T10:43:59+07:00",
"date_modified": "2017-11-16T10:43:50+07:00",
"tags": [
"mrim",
"openfire",
"исправление",
"ошибка",
"транспорт"
],
"_date_published_rfc2822": "Thu, 16 Nov 2017 10:43:59 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "123",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "97",
"url": "https:\/\/www.kini24.ru\/all\/syslog-prodolzhaem-nablyudenie\/",
"title": "Syslog. Продолжаем наблюдение",
"content_html": "
Наблюдение показало, что «валится» syslogd в очень определенное время — в момент окончания работы logrotate. Пройдя через цепочку файлов, наткнулся на упоминание reload-syslog в папке \/sbin. Полез посмотреть что это за файл, а он представляет собой обычный скрипт, в котором есть такая строчка:<\/p>\n
\/sbin\/service $n reload && break<\/code><\/pre>Мелькнула «шальная» мысль, которая заставила меня заменить reload<\/i> на restart<\/i>. Следом я удалил скрипт, который перезапускал syslogd через 1 час, после того, как он «вешался». День первый — полет нормальный. Продолжаем наблюдение...<\/p>\n",
"date_published": "2017-10-03T17:43:19+07:00",
"date_modified": "2017-10-03T17:43:14+07:00",
"tags": [
"syslogd",
"исправление",
"наблюдение",
"ошибка"
],
"_date_published_rfc2822": "Tue, 03 Oct 2017 17:43:19 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "97",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "85",
"url": "https:\/\/www.kini24.ru\/all\/obnovlenie-bloga\/",
"title": "Обновление блога",
"content_html": "
Давно мучил вопрос почему у меня в блоге перестали вставляться картинки. После обновления блога и нескольких экспериментов выяснилось, что во всем виновата тема, которую я создал. Смена темы на стандартную позволила снова вставлять картинки. Снес все файлы блога, переустановил движок. Вернул на место картинки и... Некоторые из них не вернулись в заметки. Пришлось входить в редактирование и заново сохранять их, после этого все пришло в норму. Надеюсь, что ничего не пропустил. Если что-то найдете — напишите мне, исправлю<\/p>\n",
"date_published": "2017-09-06T10:43:17+07:00",
"date_modified": "2017-09-06T10:43:15+07:00",
"tags": [
"блог",
"исправление",
"картинки",
"обновление"
],
"_date_published_rfc2822": "Wed, 06 Sep 2017 10:43:17 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "85",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "73",
"url": "https:\/\/www.kini24.ru\/all\/ispravlenie-oshibok\/",
"title": "Исправление ошибок",
"content_html": "
Уже вечером исправил косяки с новой станцией. После переброса на другую линию питания датчика ds18b20 он заработал. Это радует.
\nТакже вроде бы решил проблему со скриптом отправки данных. Вместо накопления данных в нескольких файлах, размер каждого из которых не превышает 4 кБ, сделал обработу ответа «ERROR NO CHANGES». Если скрипт получает такой ответ, то просто стирается содержимое временного файла. Иными словами, он реагирует так же, как будто получил ответ «ОК». Это, конечно, не решает вопроса длительного отсутствия связи с сервером. Так что будем думать дальше.
\nНе могу пока что придумать как разместить станцию. По хорошему ее нужно разместить подальше от стены, чтобы исключить ее влияние на показания. Но тут встает вопрос как закрепить круглую металлическую трубку на стене. С другой стороны, самый простой вариант — разместить станцию, прикрутив с наружной стороны лоджии, просто на саморезы. На решение времени осталось не так уж и много — скоро наступят холода, работать будет не очень комфортно.<\/p>\n",
"date_published": "2017-07-09T17:15:40+07:00",
"date_modified": "2017-07-09T17:21:22+07:00",
"tags": [
"ds18b20",
"исправление",
"метеостанция",
"ошибка",
"скрипт"
],
"_date_published_rfc2822": "Sun, 09 Jul 2017 17:15:40 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "73",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
}
],
"_e2_version": 4134,
"_e2_ua_string": "Aegea 11.3 (v4134)"
}