Неизвестно, как будет работать виртуальная машина с 2 мониторами.

Так как создан полный клон сервера - ему сразу нужно сменить IP, чтобы не было скрытного конфликта адресов. Так как виртуалка зашифрована и защищена надёжным паролем - выставить автовход в дочернюю ОС (примерно: Пуск→Панель_управления→Система→Вход_в_систему→Дополнительно→Разрешить_автоматический_вход_в_систему), а также убрать в ней гашение и блокировку экрана.

Совсем неисправимо: учётная запись Root - не пашет. Рабочий стол прогружается - но видно только его 1/5 часть справа, ничего не работает (в т.ч. горячие клавиши).

Пока неисправимо:

- современные процессоры, обычно, имеют функцию автоматического разгона в случае высокой нагрузки (другое дело, что в части процессоров это реализовано через жопу). Но как только процессор оказался в дочерней ОС - он стал работать исключительно с номинальной скоростью. Это привело к тому, что номинальный более поточный и менее гигагерцный процессор - стал одинаковым в скорости с авторазогнанным менее поточным и более гигагерцным (при применении многопоточности). А без многопоточности - проиграл сразу вдвойне авторазогнанному более гигагерцному;

- в виртуальной машине, по неведомой причине, 1 поток оказался всегда загруженным на 100%. В родительской ОС - постоянная загруженность на определённое и расчётное количество процентов CPU (тоже 1 поток). В дочерней ОС - отображалось в виде неотключаемого процесса v86d, жрущего расчётное количество процентов CPU относительно количества выделенных ЦП (в настройках виртуалки "ЦП" - реальный поток). Прикол в том, что не загружая дочернюю ОС (просто меню выбора режимов загрузки Astra), - поток как жрался, так и жрётся. Это оказалось не шифрование диска, не виртуальная периферия, не ЦП с RAM - полная загадка. Даже если загрузиться с WinPE - всё равно 5% (~2/3 потока) всегда жрётся, даже если жёсткий диск виртуальный отключен. Это влияет только на энергопотребление и скорость работы виртуалки - вроде, не критично - а, вроде, и критично.

(добавлено 19.06.2025) Как ни странно, убийство процесса с помощью sudo kill $(pidof v86d) - не привело к каким-либо багам и полностью разгрузило поток - поместил в автозагрузку. Однако выяснился другой баг: в Astra v.1.4 неважно, включен ли пункт в меню автозагрузки или нет, - он всё равно выполнится.

Изменение разрешения с 1920x1080 на 1768x992 - привело к такому же багу, что в Root: 1/5 рабочего стола, ни 1 значка, никакой реакции на устройства ввода. Пришлось грузиться с WinPE и исправлять обратно.

Всплыл ещё баг:

- скорость копирования (и работы в целом) HDD родительской ОС - 40МБ/с. Лампа красная моргает - проблема программная;

- на сайте производителя есть вопрос на эту тему - не думал, что эти пидоры придумают такое: вопрос есть - а ответ доступен только с платной техподдержкой (wiki.astralinux.ru/kb/fajlovaya-sistema-ntfs-medlennoe-kopirovanie-238761707.html). Решил кликнуть по форме обратной связи там же, высказать все мысли вслух и с матерком, - форма обратной связи зацикливается, при каждом нажатии делая ссылку в браузере всё длиннее и длиннее, - так и оставаясь, по итогу, недоступной;

- американское ядро версии 5.15 и выше (да, они его тупо скоммуниздили) - содержит в себе хороший драйвер NTFS от Paragon, приводящий скорость работы разделов NTFS к нормальной (к примерной скорости носителя или немного меньше). Разработчики не внедрили эту технологию в свой интерфейс корректно - везде, где монтируется NTFS, вместо "ntfs" нужно писать "ntfs3". А то скорость раздела 40МБ/с вместо 200МБ/с на HDD и 110МБ/с вместо 350МБ/с на SSD - ну такое себе.

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

(добавлено 19.06.2025) Интересно: что будет, если BAD-сектор попадёт на файл виртуального жёсткого диска.

Вскрылся давно забытый баг: в Astra v.1.4 в Qt v.5.3 плохо работает скролл: при мотании вниз - примерно "вниз-вниз-вверх-вниз" получается, причем "вверх" может быть большой амплитуды. Как исправлять - традиционно, никто не знает, - самому решение искать надо; и простым x-mouse дело не обойдётся.

Виртуальный диск требует проверки на ошибки и дефрагментации, ведь это не делали более 10 лет. Т.к. в Astra v.1.4 - баги:

- утилиты есть, но их нельзя применить к примонтированному разделу, а системный раздел не размонтируется;

- fsck для ntfs - вообще отсутствует (нет ntfsfix из Astra 1.7);

- нужен именно сторонний именно линуксовый именно Live-диструбитив (были эксперименты, забыл уже: сторонние утилиты именно у Astra v.1.4 запарывали раздел). Остановился на Linux Mint - но он DVD, из него загрузочную флешку изготавливать ещё.

(добавлено 23.06.2025) Баг с рваным скроллом VirtualBox+Astra_1.4+Qt - оказался шире: VirtualBox+Astra_1.4. Исправление: в настройках виртуальной манипулятора курсора на "PS/2 мышь". Ложка дёгтя: мышь выйдет из виртуалки только после нажатия клавиши HOST.

Linux Mint - не грузится в VirtualBox. Пришлось в Recovery Mode, под рутом, umount всех разделов - и fsck -f. Ошибки - были найдены и исправлены. На функционале - не отразилось. Оценка фрагментации - e4defrag: менее 1%.

(добавлено 24.06.2025) Это какой-то сюр:

- ntfs3 - не выводит носитель на 100% его аппаратной скорости (есть ускорение в 2-2.5 раза - но это не предел);

- попытка переформатировать раздел в ext4 - приводит к тому, что mkfs имеет другой список параметров (mkfs = mkfs.ext4 = mke2s). Нет параметра -Q - хрен с ним (форматируется и так быстро). Но не даёт корректно выставить размер кластера 512 - несмотря на то, что диагностическая винда показывает размер кластера именно 512Б;

- носитель вышел на примерный предел скорости - но интересовало изменение размера кластера для оценки максимальной скорости (в NTFS и FAT32: больше размер кластера - быстрее скорость, но большие потери дискового пространства, если файлы мелкие). Попытка в Windows переформатировать созданный в Astra раздел Ext4 в Paragon Hard Disk Manager 15: пишет - раздел неформатированный, но при этом даёт возможность отформатировать раздел в ext4 - но при этом это вообще не тот раздел: программа по работе с дисками видит его как C:, а драйвер этой же фирмы - как G:;

- то есть, ext4 у Astra - нестандартная, с внедрением ими мандатных меток, - и глючит при работе с другими диагностическими утилитами. Этим же объясняется то, что видимый раздел ext4 (системный) грохается, если ему сделать fsck частью других утилит по работе с дисками.

Вышла версия Astra SE 18.1: тестирующие в соседней комнате говорят, что тоже полна багов, - только других.

(добавлено 26.06.2025) С помощью HWiNFO удалось выяснить: то, что процессор не может в виртуалке на турбо-режим выйти - виновата не Astra, а VirtualBox. Установка Guest Additions также не помогла исправить проблему, все настройки ЦП виртуалки ситуацию не исправляют - тупик.

Виртуалка запоминает свою полноэкранность - разрешение дочерней ОС можно делать равным разрешению родительской.

Миграция ОС Windows в виртуалку.

(добавлено 27.06.2025) Никак не получается устранить дельту в 3ч дочерней ОС относительно времени родительской. И это при условии, что обе ОС - Astra, т.е. этой дельты вообще не должно было произойти.

(добавлено 30.06.2025) Решение с часами для виртуалки: отключить в ней опцию "Enable Hardware Clock in UTC Time", запустить в ОС "sudo dpkg-reconfigure tzdata".

Вероятное решение для реалки: отключение RTC in local TZ с помощью команды "sudo timedatectl set-local-rtc 0 --adjust-system-clock".

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