Gparted Увеличить диск (проблемка)

разметь, потом смонтируешь и добавишь

/dev/sda4 невозможно редактировать, он не примонтирован в том и дело.

В твоем случае никак не получится добавить.

Я думал изначально что можно как-то удалить его а потом просто его создать заново в том же месте, но не могу создать в той же файловой системе.

Когда создаешь разделы, определяется начало и конец раздела. Чтобы увеличить раздел, нужно чтобы пространство для увеличения непосредственно граничило с нужным разделом.

хм, а если прогнать 104гига через все области а в промежутке sda3 и sda5 удалим и создадим заново область такого же типа винда ее не будет отторгать, как думаешь?

Что ты подразумеваешь под «прогоним»? Переместить свободное пространство не изменяя текущую структуру (читай, не удаляя все, что после sda1) не выйдет.

Так если взять 104гб вложить их в disk-D и в начале disk-D освободить эти же 104 разве что-то изменится? та же неразмеченная область из 104гб только теперь между sda7 и sda8. Таким же макаром и с другими дисками не?

Вроде понял, о чем ты. Но нужно ответить на след.вопросы: 1) Соотносятся ли объемы переносимых данных? 2) Поддерживает ли ntfs такой перенос? 3) Поддерживает ли windows такой перенос? Если все ответы «да», то я думаю, что перенести можно, правда долго это будет.

В теории проблем не должно быть, однако на этот вопрос нужно узнать у тех кто уже это делал) Про ntfs не до конца понял, однако эти 104гб ранее были в диске Д оттуда я их и вытащил. Так что скорее ответ ДА.

А просто монтировать в папку на /dev/sda1 не подходит?

А с какой целью ты хочешь расширить sda1? Места не хватает под программы или что-то еще?

Для программ и остального. там ОСь

Он уже дал ответ, так оно и есть. просто так нельзя.

Niroday

Когда создаешь разделы, определяется начало и конец раздела. Чтобы увеличить раздел, нужно чтобы пространство для увеличения непосредственно граничило с нужным разделом.

Остального это чего? Если для файлопомойки, то как выше сказали, можно просто создать еще раздел и монтировать его или даже перенести хомяк из sda1 на новый раздел.

В основном это ПО там стоит, бывает игрушка может стоять под playonlinux. Для шлака есть диск-Д он примонитрован в системе.

ЕМНИП PoL тот же вайн, только в обертке. Там наверное тоже можно префиксы создавать в любом месте, так что как вариант можно перенести префикс с играми на другой раздел.

почему нельзя создать из 104Гб /dev/sda9, форматировать раздел в ext4, смонтировать или прибинить как папку рута?

Просто создать еще один раздел и монтировать его в папку на sda1 для задач тс подойдет

А получится использовать такой способ для увеличения места под по, которое ставиться в /bin /usr/bin и тд.?

ага

Мне не нужно еще один диск, Диск-Д уже выполняет эту роль на ура. Нужно увеличить место под ПО увеличив sda1 ну или даже не предcтавляю как, замонтировать новый /home

С лайва создаешь раздел в конце диска. Переносишь туда /home из рута. В /etc/fstab создаешь запись для монтирования /home с uuid раздела. Дефолтные параметры монтирования: rw,relatime,data=ordered 0 2

В линуксе нет Диска-Д, а есть каталог смонтированный в одно дерево

спасибо за совет, какие то костыли получаются)

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

Ну так монтируете в папку где у больше размерное по будет стоять, вайн пул или что там под что 30гиг не хватает

получается что перенеся все данные на новоиспеченный home я его замонтирую вместе с системой, а коль старый не нужен я его удалю. Это теория или уже было дело в практике? Боюсь что будут конфликты у системы.

там не только wine, есть еще Steam который сильно ругается на sda8 (он же /home/caffein/disk-D) вполне возможно и не стал бы все это делать на самом деле если бы не steam. Wine сместить не сложно. При указании пути в Steam он качает игру, запускает ее и через пару минут она вылетает а все файлы с игрой удаляются(лол) в home стим ставит игры спокойно. Гугл и форумы промолчали на эту тему.

Не будет никаких конфликтов. Если беспокоит, то можно /home на руте после копирования переименовать, например, в /home-bak. Не забудь только создать директорию /home для монтирования. И если вдруг что-то пойдет не так, сможешь всегда восстановить из имеющегося /home-bak.

У меня стим игры на отдельном разделе. Чтобы перенести, нужно скопировать .local/share/Steam на нужный раздел, в настройках стима установить приоритет на новое расположение папки Steam, выйти из стима, удалить(или временно переименовать) .local/share/Steam. Когда запустишь стим, он спросит, куда пропала папка. Указываешь новое расположение и все работает. Это для родного линуксового стима.

Кто сказал LVM ? Долго, мутно, но вполне реально.
Создаем PV sda9(?), дальше VG, LV. Копируем sda1 на созданный LV. Правим заргузчик, fstab. Проверяем. Если все заработало, создаем на sda1 PV, присоединяем к VG, расширяем LV, расширяем fs.
Это по хардкору.
Проще. Копируем /dev/sda1 на другой носитель. Сразу создаем два PV sda1, sda9, VG из них, LV, копируем назад данные, правим заргузчик, fstab. Проверяем.

НО Традиционно напоминаю, в любом случае сначала сделайте бэкап всего диска.

почему нельзя создать из 104Гб /dev/sda9, форматировать раздел в ext4, смонтировать или прибинить как папку рута?

А получится использовать такой способ для увеличения места под по, которое ставиться в /bin /usr/bin и тд.?

Насчет прибиндить анон и прав и нет. С корнем такое провернуть тяжеловато. Так же последнее время /usr отдельно уже считается «не правильным». А если быть точным, то «туева хуча» при загрузке стала использовать /usr. Даже слака до этого «докатилась» уже «несколько раз». Но вот если опустить необходимое для загрузки, то соглашусь с анон, бинд особо «жрущих» директорий вполне прокатит, только надо аккуратно для себя решить, что и куда.
Итого. Плюсы решения. В случае «бум бабах», просто с раздела шансов восстановить данные гораздо больше. Минусы решения. Неудобство планирования места. И скорее всего, как не планируй, на первом разделе окажется приличный кусок не используемого пространства.
В варианте LVM будет наоборот. Проблема восстановления с разных PV, но зато утилизация пространства полная.