Как на Ubuntu 22.04.4 LTS увеличить размер системного раздела (/dev/nvme0n1p3) за счет второго раздела(/dev/nvme0n1p4)?

На втором скриншоте посмотри, где у тебя конец /dev/nvme0n1p3 и где начало /dev/nvme0n1p4.

Видишь много места между ними? Куда собрался расширять?

и что делать нужно

1. Забэкапить содержимое /dev/nvme0n1p3 и /dev/nvme0n1p4.
2. Удалить /dev/nvme0n1p4.
3. Расширить /dev/nvme0n1p3, если получится (там от ФС зависит, и стрёмное это дело, живой партишн расширять, так что не пренебрегай бэкапом).
4. Создать новый /dev/nvme0n1p4 на оставшемся месте.
5. Восстановить содержимое /dev/nvme0n1p4 из бэкапа.

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

не майся дурью!

перенеси /opt/ на раздел с хомяком и сделай ссылку из корня…

как это сделать?

Двигать раздел p4 вправо, очевидно.

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

на rutracker скачай любую норм программу коммерческую или купи для resize дисков и запиши на флешку.

рабочий раздел изменить в онлайн не дает система.

Кто вам такое сказал?

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

В командной строке, в командной строке товарищ.

fdisk /dev/nvme0n1
d
3
n
3
1261568
# и далее можно было бы ввести остаток
# но свободного места между разделами p3 и p4 нет.

А так, после создания раздела заново с новым размером и началом раздела в тех же границах и далее просто запускается

resize2fs /dev/nvme0n1p3

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

Много раз так делал на виртуалках Proxmox, увеличиваешь диск, даже если схема разметки в GPT - fdisk ругается, что размер диска не соответствует и вообще вторая копия GPT в конце диска не найдена.

Просто удаляешь раздел, создаёшь новый, перезаписываешь таблицу разделов, заодно она записывается в конец диска и далее расширяешь файловую систему.

В консоли, батенька, в консоли.

А не в GUI. Кажется пользователю Windows и в Linux появились, ничего кроме GUI не знающие и строящие выводы исходя из своего неполноценного опыта и отсутствия знаний.

Автор, а тебе - только выносить части файловой системы на второй раздел. Например /var/log, /root, /var/{lib/postgres,mysql,www} (хотя у тебя наверное их нет), значит /var/cache/apt/archives. Их кстати можешь и почистить.

И заодно запустить процедуру сжатия логов journalctl, но для этого надо освободить место.

Ну и если в /var/log/ есть логи, которые обслуживает syslog / rsyslog - удали старые файлы логов, в окончании которых присутствует ‘.gz’.

Не стоит, если на втором разделе есть данные - можно потерять.

Без бэкапа не надо.

Двигать раздел через gparted, если это не системный раздел с виндой, на которой некоторые сектора двигать нельзя — без проблем всегда.

А ещё может быть /usr/local есть и /var/lib/docker.

Старые пакеты почистить, /boot и /lib/modules от модулей старых ядер.

Возможно, на 4 разделе ещё к тому же не /home.

Хотя вообще не понятно зачем на nvme накопителе несколько разделов.

Это в первую очередь имело место для HDD накопителей, чтобы системные файлы лежали на относительно небольшом разделе ближе к началу диска и в процессе обновления системы файлы программ писались в одну область диска, а /home, части /var/, /opt опять же выносились на другие разделы.

В случае nvme, да и вообще SSD диска проще, правильнее и нужно создавать /boot, swap, если нужно hibernate. А всё остальное под корень, без разделения.

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

С одним разделом на диск не будет проблем как у ТС и износ диска будет меньше.

Вспомнил случай когда только стали появляться SSD накопители, так меня спросили, что дескать я делаю дефрагментацию файловой системы на SSD и ничего не меняется.

Вот тут такая же ситуация - делаю не понимая что и для чего.

Понимаешь сама процедура перемещения записанных данных на раздел производится посекторно. Т.е. с конца раздела берётся некоторая порция данных и записывается в область:

сектор для записи = граница старого раздела + конец нового раздела - размер переносимой области.

И если раздел размером 220 Гб - то по кусочкам будут двигаться все эти 220 Гб.

gparted только после завершения переноса всех 220 Гб по кусочкам вправо удалит запись старого раздела и создаст запись нового в новых границах.

И если в этот момент произойдёт любой сбой - ты получишь частично перенесённые структуры файловой системы в старых границах раздела.

Обратно откатить эти изменения нельзя.

Поэтому так делать не стоит. Для таких целей придумали LVM и другие способы управления дисковым пространством.

Вариант «делать бекап, сносить раздел, создать заново, накатить из бекапа» — безусловно, безопаснее. Но если не отключать питание посреди операции перемещения раздела, то ни разу никаких проблем не было.

Пусть ТС решает, это его данные.

На втором скриншоте не видны параметры диска, а именно количество секторов. Но судя по первому скриншоту на диске размечено всё свободное пространство.

А следовательно даже если ТС захочет передвинуть 4-й раздел ему в начале нужно уменьшить файловую систему, вот так: https://access.redhat.com/articles/1196333

А потом пересчитать размер файловой системы в сектора, удалить 4-й раздел, создать заново, указав её размер из выводы tune2fs -l /dev/nvme0n1p4

echo $((Block Count * Block Size  + Inode Count * Inode Size))

И то это будет не совсем точно и не будет равняться число секторов умноженное на 512 исходя из вывода fdisk -l, а будет чуть больше.

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

Ай-яй-яй, свобода, равенство и братство, опенсорс.

Ставить 502 по IP не хорошо. Товарищи модераторы.

Хм, заработало, мистика. С 3-х мест открывается, с одного нет с разных устройств.

на rutracker скачай любую норм программу коммерческую или купи для resize дисков и запиши на флешку.

Что за дурацкий совет? Софта для перемещения разделов и так более чем достаточно в линуксе бесплатного и свободного.

Ага, например dd - тоже можно использовать для перемещения.

В скрипт заверни и перемещай. Вполне себе бесплатно, Linux-way и если лог перемещения прикрутить можно будет даже прервать процесс и продолжить.

С dd вообще много вещей можно сделать.

Теоретически, можно

1. Уменьшить размер файловой системы на p4

2. Поблочно перенести файловую систему из начала раздела в конец, от конца к началу. Размер блока должен быть не больше разницы между размером раздела и размером файловой системы на нём. Можно взять ddrescue попробовать с ключом -R или написать скрипт использующий dd

3. С помощью fdisk -W never -w never или иной утилиты сместить границу разделов к новому началу файловой системы четвёртого раздела

4. С помощью resize2fs расширить файловую систему на разделе p3.

Понятно, что ситуация довольно сложная и крайне не рекомендуется её выполнять без резервной копии, если на четвёртом разделе есть данные, которые жалко потерять.

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

Есть ddrescue — dd с прикрученным логом. Но если требуется ресайзнуть скажем на 20 гигабайт, то будет всего 11 итераций и их можно запускать даже вручную.

В случае пропадания питания на одной из итераций, можно просто начать её заново, так как каждый раз будет как минимум одна копия перемещаемого блока.

но расширить (/dev/nvme0n1p3) он не даёт, только уменьшить

Почему? Что говорит? Какие сообщения об ошибке? Мы не телепаты :-)

Уменьшаешь nvme0n1p4, двигаешь его вправо, в освободившееся место расширяешь nvme0n1p3. Итого три операции.

Важно: если отключат электричество (или зависнет машина) посреди процесса — потеряешь все данные. Поэтому озаботься либо ИБП (и выключи любой разгон), либо бэкапами.

И да, всё, что тебе написали выше, игнорируй.

Попробовал сделать на виртуалке. С ddrescue почему-то не получилось. Задача была сдвинуть раздел 64M с данными вперёд на 32 мегабайта, для этого я его пересоздал с размером 96 мегабайт вместо 64, затем попробовал такую команду:

root@slackware:/# ddrescue --same-file -R -v -u -c 2048 -y -o 32M -f /dev/sda1 /dev/sda1 ddresc.map
GNU ddrescue 1.27
About to copy 100663 kBytes from '/dev/sda1' to '/dev/sda1'
    Starting positions: infile = 0 B,  outfile = 32000 kB
    Copy block size: 2048 sectors       Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 0 B, tried: 0 B, bad-sector: 0 B, bad areas: 0

Current status
     ipos:   99614 kB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  131614 kB, non-scraped:        0 B,  average rate:       0 B/s
non-tried:  100663 kB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:        0 B,   bad areas:        0,        run time:          0s
pct rescued:    0.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (backwards)
ddrescue: /dev/sda1: Write error: Invalid argument

Да и размер 32000kB явно неправильный.

Вторая попытка с dd, вроде всё получилось, хотя надо было использовать ключи status=noxfer и echo offset: $i, но в целом не критично. В случае ТС блоки по гигабайту подойдут. Ну и командой tee можно сохранять лог, чтобы продолжить с того места, где копирование прервалось, если что:

for i in {63..0}; do dd if=/dev/sda1 of=/dev/sda1 bs=1M skip="$i" seek="$[i+32]" count=1; done
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.149179 s, 7.0 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.192866 s, 5.4 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.139224 s, 7.5 MB/s
...

Теперь с помощью fdisk я создал два раздела на месте sda1, а именно sda1 на 32M и sda2 сразу после него на 64M, если всё правильно сделано, то второй раздел должен быть копией первого. Проверяем вначале через fsck:

root@slackware:/# fsck -f /dev/sda2 
fsck from util-linux 2.39.2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts                                              
Pass 5: Checking group summary information
/dev/sda2: 36/16384 files (16.7% non-contiguous), 27914/65536 blocks

Затем пробуем смонтировать и посмотреть файлы:

root@slackware:/# mount /dev/sda2 /mnt/       
root@slackware:/# ls /mnt/
bin/  boot/  dev/  etc/  lib64/  lost+found/  proc/  syslinux/
root@slackware:/# umount  /mnt/

Файлы тоже на месте. После переустановки lilo система загружается. То есть способ рабочий.

Важно: если отключат электричество (или зависнет машина) посреди процесса — потеряешь все данные. Поэтому озаботься либо ИБП (и выключи любой разгон), либо бэкапами.

Должны быть утилиты, которые позволяют продолжить операцию в случае фейла. В крайнем случае мой вариант с dd с условием что лог процесса сохраняется на отдельный носитель - он позволит выяснить, сколько блоков скопировано, а сколько нет.

пфу, зачем так извращаться же. cp -ax в помощь