rPman

Загрузчик linux лучше размещать на устройстве, на котором нет загрузчика windows. Конечно можно и совместить но проблем будет не мало, были примеры когда при абсолютно верных настройках, windows при очередном обновлении затирало загрузчик Linux, ошибетесь, затрете загрузчик windows и т.п.

Куда ставить - стороннее устройство, позволит работать одновременно а не последовательно, это же логично

Как использовать диски hdd и ssd, особенно если ssd маленький (64..128гб):
1. сделать ssd диск кеширующим (не обязательно весь, можно выделить раздел) для большого но медленного hdd.
В linux есть отличная технология - bcache (там еще и другие есть с той же задачей, bcache универсальнее и проще), поддержка из коробки во всех современных дистрибутивах, никаких проблем с загрузкой, простое как валенок. в ней медленный раздел форматируется make-bcache как bcache backing device, а раздел на ssd как cache device, регистрируешь первый, а второй подсовываешь как кеш для первого (это можно делать на лету позже выключая и включая), даже поддерживается кеш записи.
Кеш сохраняется между перезагрузками и это главная фича, т.е. прогретый кеш сделает работу с hdd такой, будто он весь ssd (точнее не придется вручную решать и перемещать файлы кому лежать на hdd а кому на ssd).

2. разместить своп на ssd диске (размер обычно сравним с объемом ram или чуть больше - туда linux будет делать hibernate, если надо)
3. Не разделяй систему на разделы типа / /home /var /usr ... этот пережиток прошлого имел смысл когда диски были мизерные, если системой пользуются несколько человек, для /home наверное имело бы смысл выделять отдельный раздел или лучше subvolume (при использовании файловой системы btrfs например) но только чтобы можно было на уровне диска выставлять квоты (вообще то linux позволяет выставлять различные лимиты на уровне пользователя), иначе не стоит заморочек.

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

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

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

5. Файловая система btrfs, отличная альтернатива дефолтной ext4, и хотя она все еще не рекомендована как надежная (заявлены недоделки в их встроенном raid5...6), ее предлагают использовать инсталяторы как норма, это COW-файловая система, очень надежна в плане нештатных выключений, встроенные снапшоты (не понижают производительность), сжатие файлов налету, дедупликация (обывателю настроить проблематично) и много чего.

итого:
ssd (gpt диск):
* efi boot - 100mb (нужен если загрузка будет использовать uefi, можно установить только если установщик в режиме uefi)
* bios boot - 1mb (нужен если gpt а не dos разбиение)
* linux /boot - 512mb, нужен если рут linux размещен в bcache или еще где то нестандартно, если же просто ext4/btrfs/... то не нужен
* swap
* ssd cache - bcache
hdd:
* ssd cached device - bcache (причем даже не нужно создавать разделы)

Поверх bcache разместить btrfs файловую систему, с корнем linux в subvolume по умолчанию (он так и зовется /)

В настройках /etc/fstab использовать не имена дисков а их UUID=xxxxxxxxx (узнать можно lsblk - удобная утилита тогда все будет автоматически подцеплено и примонтировано и не важно какой порядок дисков)

ssh: connect to host port 22: Operation timed out

по ssh уже никак

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

иначе, перезагружай сервер, все хостеры дают такую возможность

На сколько мне известно, grub не шифруется, suse как я понимаю, просто ставит на него пароль, его так же можно самому добавить на ubuntu

По уму, при использовании UEFI и SecureBoot к запуску допускается только подписанный grub, а значит можно добавить свои ключи в биос, удалить все остальные и подписать grub своим ключом, в этом случае никто не сможет ничего запустить, сменить биос и прочее... только превратить в кирпич железо.

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

в окружении, в котором запускаешь приложение должна быть определена переменная DISPLAY, ее значение можешь смотреть в терминале, запущенном из графического окружения, скорее всего это будет :0
Однократно можно это использовать так:
DISPLAY=:0.0 xclock

Так же пользователю, если он отличен от того, для которого запущено графическое окружение, необходимо выдать права на подключение к xserver, это делается xhost (еще есть xauth):
xhost +local:root
Даст права root авторизованного локально работать с графической оболочкой.

Если подключаешься удаленно с помощью ssh можно указать ключ -Y и тогда все будет настроено автоматически (это могут отключать в настройках sshd.conf), т.е. имеется в виду из терминала, запущенного в графической оболочке xserver (например xwin идущий с пакетом cygwin для windows) подключаешься к удаленному серверу ssh -Y user@server и запускаешь там приложения, окна которого будут отображаться локально. Не очень эффективный метод, но будет работать даже 3d графика (если локальный сервер умеет). Эффективнее использовать x2go для таких вещей.

полистать логи до того как стали появляться эти сообщения.

дословный перевод - файловая система стала read only, т.е. только для чтения, а значит каждая попытка записи будет выдавать такую ошибку

Без чтения логов гадать бессмысленно.

bcache (hdd+ssd) и на него файловую систему ext4/xfs, кстати журнал можно так же разместить на ssd, в некотором смысле это наилучшая конфигурация для домашнего пользователя с точки зрения производительности на затраченный рубль.

Можно btrfs, поиграетесь со снапшотами, сжатием и дедупликацией (кстати с последним не поиграетесь, всякие ubuntu из коробки не умеют) но copy-on-write файловые системы могут подкинуть ряд неочивидностей (например базы данных там фрагментируют диск, но это тюнится)