Увеличение раздела программой «Управление разделами KDE» уничтожает данные на нём?

Без потерь , но потенциально опасно. Все важные данные должны иметь бекап

А куда ты его будешь увеличивать? Расскажи обо всем, что есть на диске.

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

Еще я не помню насчет фрагментации в Ext3. По идее, перед тем, как начинать что-то делать с разделами, желательно бы их причесать. Но это в случае уменьшения, скорее, увеличение не должно сказаться.

Для увеличения не нужна дефрагментация

Спасиб, что подтвердил.

Несмотря на то, что увеличение раздела по идее не должно быть рисковым:

1. всегда делай бекапы
2. partitionmanager не рекомендую после одного инцидента: Как починить битый раздел ext4 после перемещения?

используй лучше gparted, он никогда не подводил

Я бы предложил использовать fdisk (с параметрами -W never -w never) для того чтобы вначале удалить раздел, а потом создать заново с тем же номером первого сектора, но другим конечным сектором. Внимательно читать предупреждения.

Затем можно resize2fs /dev/sda3 или как-то так расширить файловую систему на весь раздел.

«Управление разделами KDE» — бажная кака. Была, есть и будет.

Как починить битый раздел ext4 после перемещения?

А почему такой вопрос возник-то?

У меня программа управления разделами из KDE выдавала ошибку на каком-то из кейсов, с которыми я сталкивался. gparted отработал без проблем. Подробностей не помню, но с тех пр я сделал для себя вывод пользоваться gparted.

В любом случае всё это только обертки для вызова консольных средств. Главное, чтобы они передавали туда правильные параметры.

/dev/nvme0n1p5: LABEL=«Steam» UUID=«8bd3667d-01ea-45b8-82bb-cd534d4c003c» BLOCK_SIZE=«4096» TYPE=«ext4» PARTUUID=«4940cede-9207-1148-b2c1-9095e8c0454c» /dev/nvme0n1p3: LABEL=«root» UUID=«a73a1e4b-689a-47c8-b7a6-518cb16df62d» BLOCK_SIZE=«4096» TYPE=«ext4» PARTUUID=«25dede72-4e31-694e-84ae-4c5e7705c425» /dev/nvme0n1p1: LABEL_FATBOOT=«ESP» LABEL=«ESP» UUID=«B186-FFDC» BLOCK_SIZE=«512» TYPE=«vfat» PARTUUID=«9ea5b7d0-eddf-ee42-ac24-1adf9493f9e8» /dev/nvme0n1p4: LABEL=«home» UUID=«855e957f-5e10-49de-aa58-b02b6f9ceb5b» BLOCK_SIZE=«4096» TYPE=«ext4» PARTUUID=«a56b4547-d7ff-0643-a326-428d8a9bab26»

Присоединюсь к вопросу. Можно ли безопасно расширить /home на /steam в данной ситуации? Вроде они подряд идут p4 и p5 на накопителе. Или лучше\надёжнее скинуть всё на другой диск и потом их уже склеить и вернуть данные?

Хм, а я просто никогда не пользовался чем-то, кроме gparted. У меня и щас вон лежат его лайвсиди и флешка с ним где-то на полке. Незаменивая вещь. Пользуюсь уже почти 20 лет как, года с 2006, и ни разу он меня не подвел. А тогда я его просто нагулил вопросом, возможно даже по ЛОРу, мол, чем поменять разделы.

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

5 звезд, а оформить портянку не смог…

Из этого текста кто идёт подряд, а кто нет - не понятно. Лучше скинь вывод fdisk -l.

А так - без проблем. Удаляешь раздел p5, увеличиваешь размер раздела p4, если они и вправду идут друг за другом, делаешь resize p4. Всё это можно сделать прям из живой системы, линукс умеет делать resize файловой системы наживую, потрясающая система.

Этими гуями я не пользовался, привык по-старинке, через fdisk всё делать. Чего и вам советую. Но, наверное, и гуй это сделает. Главное начало раздела не двигай.

Вроде красивая портянка. Каждая строка выхлопа в своей строке. Разве у вас не так выглядит?

Иногда важно создать ФС с конкретными опциями. Тогда проще man покурить и вызвать точную команду. А так для простых кейсов я gparted запускаю обычно.

Минус в том, что он не понимает LVM.

А KDE Partition Manager – понимает. Но ему я не доверяю.

Поэтому с LVM только ручками в терминале.

Ты через кастомный клиент или с кастомными скриптами на ЛОРе сидишь?

https://ibb.co/3WhMXGK

Устр-во           начало      Конец    Секторы Размер Тип
/dev/nvme0n1p1      2048    1050623    1048576   512M Microsoft basic data
/dev/nvme0n1p2   1050624    3147775    2097152     1G Файловая система Linux
/dev/nvme0n1p3   3147776  515147775  512000000 244,1G Файловая система Linux
/dev/nvme0n1p4 515147776  924747775  409600000 195,3G Файловая система Linux
/dev/nvme0n1p5 924747776 1953523711 1028775936 490,6G Файловая система Linux

Да, подряд похоже. Вот этот 195, хочу увеличить на последние 490. Видимо уже пора. Раздел steam переехал на 2Тб отдельный накопитель уже 4 месяца как.

Нет. Может дело в том что разрешение 4К и монитор 27", поэтому вся портянка(каждая строка портянки конечно) влезла в одну строку. Я что-то и не подумал, что у других это будет не так. А исправить уже не могу.

ext4 позволяет в on-line режиме менять размер тома.

Я так легко и просто увеличиваю тома в LVM по мере необходимости.

Сначала увеличиваешь раздел, потом увеличиваешь ФС.

Если у тебя ext3, то я не помню, умеет ли она такое.

https://ibb.co/fYH2Tr4

У меня вот так. Довольно аккуратно, хоть и без отдельного блока.

Ext4. Спасибо.

Нет, все в кашу одной строкой.

Ну LVM да. Правда, я его редко использую, поэтому хватает гпартеда.

Ну что тут рассказывать, ну с лева на право /boot/efi, /boot, /, /home, за ним идёт тот самый раздел, который хотел увеличить, а следом пустое пространство до конца диска. Всё кроме efi и сабжа размечено в ext4, сабж в ext3.

Я не выдержал и, не долго ожидая всех ответов, размонтировал раздел и запустил изменение размера. Кажется всё прошло успешно, раздел монтируется файлы читаются.

Так что спасибо, парни. Всем палец вверх.

Ну вот я это и хотел услышать, да. Что справа пустое место. Поздравляю с успехом.

Тебе не повезло, попробуй ещё раз

Какой глупый вопрос. Ни увеличение, ни уменьшение не приводят к утере данных. Проблемы могут быть только если при уменьшение укажешь размер меньше чем «занято», но решается это увеличением (увеличение/уменьшение - это просто запись в таблицу разделов в начале диска). Убить данные можно только пересоздав файловую систему, но файлы все еще можно будет восстановить (не все)