HighMan

from subprocess import run
i = 4
disk = {'path': '/dev/vdb'}
d = f"label:gpt\nsize=512M,type=U\nsize=2G\nsize={i}G,type=S\n+\n"
r = run(['sfdisk', disk['path']], text=True, input=d, capture_output=True)
print(f"Return code: {r}")

Вот так работает как нужно.

Ха! Достал Google так, что чуть меня в нем не забанили, но похоже нашел решение!
Если кому интересно, то распишу всю последовательность действий.
1. Импортируем ovpn или conf файл в NetworkManager. Это расписывать не стану. Мануалов в нете достаточно.
2. Пробуем установить соединение через Network-Manager. Если получилось, то переходим к следующему пункту. Если нет, то идите и доставайте Google :)
3. nmcli connection show
Внимательно смотрим что за билеберду он нам выдал. Что бы не долго мучатся, нас интересует первый и посление колонки. Ищем там название нашего VPN соединения. Теперь смотрим последнюю колонку (DEVICE). Если там пусто или непонятные тире, то соединение не активно.
4. nmcli connection up "имя вашего vpn соединения". Если оно "client" то nmcli connection up client
5. В изумлении смотрим в правый верхний угол Gnome и видим значок, что соединение установлено!

В общем: поймал вирус.
Смотрите в комментариях как обнаруживается и ловится.

Все зависит от того, как система будет использоваться.
Например, если планируется активное использование в режиме Desktop, то довольно много разнобезобразной информации будет хранится в /home/ и есть смысл выносить его на отдельный раздел или даже диск.
Особенно это актуально, когда есть маасенький SSD и здоровый HDD. Тогда можно систему поставить на ssd, а в /home монтировать здоровенный раздел с HDD. Можно и симлинками раскидать, но это пока можно опустить, что бы окончательно не запутаться.
Если же основное использование сервер, то с разделом для /home можно не заморачиваться. Там все равно почти ни чего лежать не будет. Лучше для /var/lib сделать отдельный раздел.

Тьфу! Нашел!

tar -C /tmp/1/2/3/4/5/6/7/8/ -czvpf /mnt/archive.tar.gz .

Так он всю файловую структуру ниже 8/ воспринимает как от корня. Т.е. то что требовалось

Давно заданный вопрос так и остался без решения. Однако, сейчас встала задача и данный вопрос снова стал актуальным.
Занялся чуть более вдумчиво и...
Ставим Debian 11 на виртуалку. Монтируем qcow2 через nbd, потом / монтируем в /mnt

cd /mnt
tar -cvpfz /srv/debian.tar.gz .

Ой. Забыл совет: Debian по стандартной разбивке не выделяет отдельный раздел под /boot, потому лучше бить вручную. /boot мы трогать не будем.
Создался архив. Крысота!

rm -fr /mnt/*
ls /mnt

Ой! Пусто! Что же я наделал????
Но есть же архив!

cd /mnt
tar -xvzpf /srv/debian.tar.gz
sync

Отмонтируемся. Запускаем виртуалку. Зашибись! Система работает.
Но мы не ищем простых путей. Хочется иметь универсальный способ. Fedora у меня в прошлый раз не заработала. Точнее, заработала, но не дала авторизоваться. После ввода пароля мгновенное нечитаемое сообщение и снова приглашение авторизации.
На виртуалку ставим Centos 8 Stream. С Федориным горем находятся в ближайшем родстве.
Повторяем все издевательства как с Debian. Система запускается, но ровно с тем же результатом. После ввода пароля на мгновение нечитаемое сообщение и снова запрос авторизации.
Сука-а-а!
Заново гасим, монтируем лезем смотреть логи.
Мать! Хрен поймёшь! Вроде все норм, но почему-то всплывают невнятные сообщения от selinux. Тааак! Я же не отключал этот глюк! Фактически, доставил пару пакетов на свежую систему и больше ни чего не делал.
Отрубаем selinux. Размонтируемся. Загружаемся. Авторизуемся.
Все работает! Что-то не понравилось selinux, но с ним нет ни какого желания разбираться. Все равно он у меня всегда живёт в DISABLED режиме.
Если кто-то знает, как договориться с selinux - напишите! Я с ним разбираться не хочу, но для расширения кругозора, не помешает.
В общем, можно прекрасно быкапить систему в оффлайне с помощью tar. И не только быкапить, но и восстанавливать!))
Многие удивятся: нахрена тебе этот геморрой, если есть снапшоты у вартуалки, да и LVM можно снапшотить... Для чего?
Да потому что не снапшот!
Я снапшотами даже на виртуалках не пользуюсь.
Слишком велики накладные расходы!
А такой способ бэкапа ни к чему не обязывает. Нужно лишь место для хранения архивов.
Но,на самом деле, вернуться к этой проблеме меня заставила другая необходимость.
Нужно заливать прошивки на устройства. На много тысяч устройств.
Можно, конечно, ставить систему и дальше на нее заливать нужный софт. Ansible в помощь.
Но такой подход не плох, когда нужно залить один девайс. Ну, десяток!
А если больше, то это совсем беда.
А так подготавливаем один девайс. Тестим.
Если все зашибись, то с помощью dd снимаем /boot раздел. Дальше / архируем tar.
Осталось лишь автоматизировать процес, но это ерунда! Не шибко большой bash скрипт сумеет разбить диск, залить /boot, распаковать архив в / раздел.
Быстро и следить не нужно.
Осталось лишь разобраться с "анонимизацией" эталонной системы.
Буду очень благодарен, если кто-то подскажет, что и как убивать в эталонной системе, что бы ее можно было клонировать на тысячи однотипных устройств.

https://archlinux.org.ru/forum/topic/20858/
Я сделал у себя по привычному на Ctrl+Shift
gsettings set org.gnome.desktop.wm.keybindings switch-input-source "['Shift_R']"
Даже вверху раскладка стала индицироваться нормально

Вот решение:
Импортируем настройки VPN подключения. Дальше идем в настройки ->IPV4->Автоматический DHCP -> поставить галку в самом низу на "Использовать это подключение только для ресурсов этой сети".
Готово!
Теперь при подключении не будет переназначаться Default Gateway

Хм... Крайне холиварная тема.
У Вас какие-то предпочтения есть? Есть опыт работы с каким-либо семейством Linux?
Если нет, то: Ubuntu (Debian famaly)
Если хотите вааще на пике новшеств, то Fedora 33 (RedHat family). Fedora 34 крайне не советую. Там по умолчанию Gnome 4, а он ещё недопилен.
Хотя я и предпочитаю Fedora, но новичку посоветовал бы Ubuntu. Намного больше информации.
В плане безопасности, рулит не дистрибутив, а пользователь. А ещё лучше - администратор :)

Вопрос разрешился. В муках)
Виной всему оказалось мое очень поверхностное знание настройки PHP и... дурацкий скрипт phpdismod.
phpdismod отрабатывает и НИЧЕГО не сообщает. Сделал он что-то, не сделал - хз.
Оказалось, что он все таки делает! Только не совсем так, как от него ожидалось.
Я считал что он должен что-то делать с /etc/php/7.x/mods-avilable, а он на самом деле этот каталог не трогает. Просто рубит символьные ссылки, напримр в cli.

А зачем ставить на Ubuntu и морочить голову?
Наверное можно извратится и накатить Proxmox на CentOS. Только зачем?
Proxmox это, по большому счету, web gui над qemu+kvm и кластеризацией.
Какая разница на чем это будет стоять?
Если ему комфортнее крутится на Debian, то зачем это насилие?
Если вы предпочитаете управлять всем через терминал, то нафига Proxmox?
Ставьте qemu-kvm, libvirt и virsh на любой дистр и вот оно - счастье!