rPman

погуглю за тебя
помимо самого доступа нужно еще и чужие структуры понимать, а это значит использовать как минимум те же версии подключаемых библиотек (в т.ч. статически, что не так просто определить)

Конкретно для виртуальной машины нужно установить драйвера гостевой ос (смотреть ту виртуальную машину которую используешь), например VirtualBox таскает с собой VirtualBoxAdditionals.iso

универсально (т.е. и на реальном железе):
с помощью cvt генерируешь дефолтные параметры для своего режима и затем добавляешь этот режим с помощью xrandr
https://wiki.archlinux.org/title/xrandr
https://linuxnow.ru/view.php?id=103

Зачем выбирать специализированную версию linux - RedOS а затем уходить от ее протестированных компонент на самые новые, в 99% случаев вне зависимости от ос это непередаваемые приключения и страдания. Чем тебя qt5 версии не устраивают, которые есть в репах этой ос?

Так как готовых backports разработчики или сообщество не предоставило (наличие их отсутствия показывает размер и качество этого сообщества и разработчиков данной ОС), то собирать вам весь комплекс пакетов самостоятельно

Без знания linux боюсь будет очень сложно, ведь на таком квесте спотыкаются и опытные пользователи

RedOS Система основана на rpm пакетах, пакетный менеджер утилита dnf (ранее yum) так как скорее всего основано на centos. С некоторой вероятностью у операционной системы может быть бинарная совместимость с centos (одинаковые версии системных библиотек) а значит можно попытаться поискать готвые решения от туда.

p.s. но главное, куда поедет сертификация, после того как вы на эту ос начнете водружать системные пакеты собственной/чужой сборки?

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

Кстати со всеми xserver обычно идет древний дефолтный twm, настолько примитивный что даже смешно, но если бы при открытии любого окна он не требовал от пользователя указать расположение и размер, им можно было бы пользоваться (не удивлюсь если это настраивается но никогда этим вопросом не задавался).

Из минималистичных и вполне функциональных DE можно предложить еще какой-нибудь openbox, его можно настроить так чтобы вообще никаких 'пуск' и списка задач не было, а только иконки и приложение на весь экран. Но пользователь сможет добраться до редактирования меню и запустить любое приложение, т.е. это не для kiosk mode

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

На самом деле процесс запуска DE стал очень замудреный, его запутали несколько поколений разработчиков и выпутывать не желают, но обычно все это критично для тяжелых DE типа KDE, а что то простое и легкое с приложениями на gtk работает и так

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

lvm? lvextend

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

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

Еще момент, некоторые файловые системы, например btrfs/zfs, умеют на лету! добавлять (и удалять) диски к пулу, и не обязательно это должен быть raid, возможно простое объединение пространств дисков, даже без чередования. Собственно btrfs я бы и рекомендовал использовать, даже не смотря на его нестабильный статус (так как все его проблемы касаются вещей, которые можно не использовать, например raid56)

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

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

Запрети всем доступ к usb и запили скриптик, который к примеру по крону будет проверять список устройств, например с помощью lsblk (там можно настроить подробный вывод) и смотри там uuid или метку или идентификатор устройства и монтируй

а для размонтирования разрешай запуск своего sudo unmount, пусть ярлыком запускают пользователи

в самом скрипте в цикле (например на каждую новую итерацию) ставишь проверку например наличия определенного файла в /tmp а при запуске скрипта этот файл удаляешь, если есть

на нужную тебе комбинацию клавиш (в штатных настройках DE) настраиваешь на запуск своей команды bash -e touch /tmp/имя_файла, эта команда создаст пустой указанный файл

блочное шифрование - решение только вокруг типового backup format restore, т.е. необходимо место куда перенести бакап уже установленной системы

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

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

ставь 2х и выбирай xfce, у него мелкие значки, а значит с таким увеличением на твоем мониторе будет в самый раз
p.s. я считаю наилучшее размещение панели задач - сверху, поверх заголовка окна, на 2/3 ширины экрана

2k и 14" это какой то сюр, создана проблема на пустом месте

Вангую - сеть на этой машине поднимается не с момента включения компьютера как положено, а позднее, например после входа пользователя в DE.
.е. в момент включения компьютера сети нет и шара подключиться не может

исправляй этот момент