Сбой загрузки АРМ после обновления агента администрирования

[CescaAdmin]

Добрый день, коллеги.

Прошу оказать помощь в решении кейса и анализа возможных причин.

В организации имеется парк ПК с ОС Альт СП 10. Была миграция со старого сервера KSC на новый.

На новом сервере была инициирована задача по обновлению агентов администрирования с версий 11-12 до последней 15.4.
При попытке обновить с помощью агента администрирования - получал ошибки доступа в /tmp на конечных устройствах, хотя в настройках задачи прописывал путь до каталогов с разрешенными правами чтения/записи.
Далее изменил способ загрузки и установки на SSH с указанием кредов локального администратора - процесс пошёл, однако из 41 ПК задача успешно завершилась на 6, на остальных выдало ошибку установочного скрипта.
А теперь главная проблема - на тех 6 ПК, где обновление завершилось после перезагрузки повредилась initramfs и теперь эти ПК не загружаются. Попытки что-либо исправить с помощью Rescue Live CD пока ни к чему не приводят (и fsck, и make-initrd, и grub-install).

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

[durtuno]

47 минут назад, CescaAdmin сказал:

А теперь главная проблема - на тех 6 ПК, где обновление завершилось после перезагрузки повредилась initramfs и теперь эти ПК не загружаются.

Вы уверены в этом, а не в то, что это совпадение? 

С чего бы сетевому агенту трогать initramfs? Как вариант изучите сценарии установленного пакета и убедиться в этом, что там ничего подобного нет;

51 минуту назад, CescaAdmin сказал:

Попытки что-либо исправить с помощью Rescue Live CD пока ни к чему не приводят (и fsck, и make-initrd, и grub-install).

Изучите системный журнал до события падения системы, может там окажется подсказка.

[CescaAdmin]

3 минуты назад, durtuno сказал:

Вы уверены в этом, а не в то, что это совпадение? 

Абсолютно точно уверен, отвал случился именно на тех машинах, где задача обновления агента завершилась успехом и они были перезагружены.

[durtuno]

17 минут назад, CescaAdmin сказал:

Абсолютно точно уверен

Без анализа и какой-либо дополнительной информации, на одной только уверенности, Вы всяко не продвинетесь.

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

[mike 1]

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

[CescaAdmin]

В 20.08.2025 в 12:10, durtuno сказал:

Без анализа и какой-либо дополнительной информации, на одной только уверенности, Вы всяко не продвинетесь.

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

Предварительный анализ системного лога и логов установки klnagent позволяет предположить следующую связь:

После обновления klnagent в ОС добавились новые зависимости по fanotify, eBPF и, возможно, kernel-модули или хуки. Initramfs не был перегенерирован, поэтому на загрузке Initramfs ожидает root-устройство (rdshell-locked — таймаут в rdshell, часть make-initrd).

В документации к KSC и к агенту на Linux не было найдено явных инструкций по установке на Alt SP 10, однако, в документации к Astra Linux (https://support.kaspersky.ru/KSC/14/ru-RU/251798.htm) был замечен следующий пункт:

Обновите оперативную память дисков:
update-initramfs -u -k all

В связи с чем есть предположение, что при обновлении агентов на ПК с ОС Alt SP 10 не был обновлён initramfs, что повлекло за собой сбой загрузки ОС. 
Тем не менее, пересборка через make-initrd результатов не принесла.