LINUX.ORG.RU

При установке приложения на fedora 36 пишет недостаточно места

 


0

1

Здравствуйте, в очередной раз устанавливал приложение, и получил сообщение:«По меньшей мере необходимо еще 1345 МБ места в файловой системе /.». Проблема в том что при установке я выделил в /home около 850 гб. В чём проблема? Выводы df -h и df -i:

Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
devtmpfs           4,0M            0  4,0M            0% /dev
tmpfs              3,5G          18M  3,5G            1% /dev/shm
tmpfs              1,4G         1,8M  1,4G            1% /run
/dev/sda2           20G          17G  1,6G           92% /
tmpfs              3,5G          44K  3,5G            1% /tmp
/dev/loop1          64M          64M     0          100% /var/lib/snapd/snap/core20/1695
/dev/loop0          64M          64M     0          100% /var/lib/snapd/snap/core20/1634
/dev/loop2         5,7M         5,7M     0          100% /var/lib/snapd/snap/network-manager/742
/dev/loop3          48M          48M     0          100% /var/lib/snapd/snap/snapd/17336
/dev/loop4          50M          50M     0          100% /var/lib/snapd/snap/snapd/17576
/dev/sda6          880G         2,7G  833G            1% /home
/dev/sda1          998M          14M  985M            2% /boot/efi
tmpfs              714M         452K  714M            1% /run/user/1000
/dev/sda3          500M          15M  486M            3% /run/media/konstantin/34C1-185A

Файловая система   Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в
devtmpfs          1048576           578   1047998             1% /dev
tmpfs              913739            14    913725             1% /dev/shm
tmpfs              819200          1197    818003             1% /run
/dev/sda2         1310720        291575   1019145            23% /
tmpfs             1048576            47   1048529             1% /tmp
/dev/loop1          11897         11897         0           100% /var/lib/snapd/snap/core20/1695
/dev/loop0          11885         11885         0           100% /var/lib/snapd/snap/core20/1634
/dev/loop2            219           219         0           100% /var/lib/snapd/snap/network-manager/742
/dev/loop3            486           486         0           100% /var/lib/snapd/snap/snapd/17336
/dev/loop4            491           491         0           100% /var/lib/snapd/snap/snapd/17576
/dev/sda6        58662912         59209  58603703             1% /home
/dev/sda1               0             0         0              - /boot/efi
tmpfs              182747           243    182504             1% /run/user/1000
/dev/sda3               0             0         0              - /run/media/konstantin/34C1-185A


[i]Перемещено hobbit из general[/i]

Ответ на: комментарий от Konstantinfgf

Покажи вывод sudo fdisk -l.

И многие инструкции устарели. Раньше 20 гигов на корень и правда хватало, но сейчас с появлением более жирных приложений, snap и flatpak нужно хотя бы 30-40.

Наверное можно будет поправить, но так хитро, что для тебя проще переустановка.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid
Диск /dev/sda: 931,51 GiB, 1000204886016 байт, 1953525168 секторов
Disk model: ST1000LM024 HN-M
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: dos
Идентификатор диска: 0xd9fa2484

Устр-во    Загрузочный   начало      Конец    Секторы Размер Идентификатор Тип
/dev/sda1  *               2048    2050047    2048000  1000M             6 FAT16
/dev/sda2               2050048   43993087   41943040    20G            83 Linux
/dev/sda3              69208064   70232063    1024000   500M             6 FAT16
/dev/sda4              70232064 1953523711 1883291648   898G             5 Расширенный
/dev/sda5              70234112   76525567    6291456     3G            82 Linux своп / Solaris
/dev/sda6              76527616 1953523711 1876996096   895G            83 Linux


Диск /dev/zram0: 6,97 GiB, 7484735488 байт, 1827328 секторов
Единицы: секторов по 1 * 4096 = 4096 байт
Размер сектора (логический/физический): 4096 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт


Диск /dev/loop0: 63,2 MiB, 66265088 байт, 129424 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop1: 63,24 MiB, 66314240 байт, 129520 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop2: 5,54 MiB, 5812224 байт, 11352 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop3: 47,99 MiB, 50319360 байт, 98280 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop4: 49,64 MiB, 52051968 байт, 101664 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт

Если уж так то можете подсказать как правильно смонтировать? В плане сколько выделять нужно, а то ещё и /var отсутствует
Konstantinfgf
() автор топика
Ответ на: комментарий от Konstantinfgf

Первое, что неверно, ты не используешь lvm

lvm позволяет создавать тома с читабельными названиями и спокойно расширять и уменьшать их на лету. Увеличивать можно практически с любой FS, в том числе не отмонтируя. Для кменьшения нужна файловая система поддерживающая эту операцию, например ext4 и это делается с отмонтированием.

Но и сейчас вполне можно решить проблему. У тебя все пространство сожрали снепы.

Создаешь папочку в /home/snapd раз там места много.

гасишь все снепы. что тотипа systemctl stop snapd

mv /var/lib/snapd/* /home/snapd

ln -s /home/snapd /var/lib/snapd ln -s /home/snapd /snapd

Директории уточни, в корне там вроде /snap

И все, теперь у тебя все снепы в хомяке.

AVL2 ★★★★★
()
Ответ на: комментарий от Konstantinfgf

У тебя между sda2 и sda3 ещё 10ГБ свободного места, можно sda2 туда расширить. Но надо делать всё очень аккуратно, иначе запорешь систему (запускаться перестанет) и чинить будет ещё сложнее.

/dev/sda2               2050048   43993087   41943040    20G            83 Linux

Открываешь fdisk, удаляешь sda2, потом создаёшь его назад с максимально большим размером который он предложит и ставишь тип 83 опять. Если он будет ещё заодно предлагать что-то делать с файловой системой (удалять её) - отказывайся. После того как создал новый sda2, посмотри ещё раз список разделов. Он должен быть точь-в-точь как был, отличие только в колонках «конец», «секторы» и «размер» у sda2. Если всё правильно, сохраняешь изменения (w) и перезапускаешься.

На этом этапе у тебя уже будет 30ГБ раздел, но файловая система на нём была создана 20ГБ, её отдельно надо увеличивать.

Дальше надо расширить файловую систему корня на новый увеличенный раздел. Это делается программой resize2fs, но по-хорошему её бы надо размонтированный раздел давать. А у тебя это корень - он всегда смонтирован. Я бы ребутнулся в iniramfs как-то и оттуда это сделал.

Чтобы загрузиться в initramfs можно в grub отредактировать стандартный пункт меню (там хоткей есть), дописав параметрам ядра init=/bin/sh вроде.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от Vsevolod-linuxoid

Просто - это когда есть таблица с чёткими началом и концом каждого раздела (как автор привёл). Всё остальное - это лишняя путаница, непонятно зачем нужная.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Ну например с LVM проблема автора решилась бы мигом, откусить кусок от /home и добавить к / можно было бы прямо на ходу без ребута, буквально 2 командами.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от firkax

Объясни, чем она так ужасна. С технической точки зрения всё будет работать, и будет работать нормально, LVM технологии уже не первый год, device mapper в Linux отлично с ней справляется.

А что же касается непонятности… блин, LVM прост как палка, он даже проще, чем обычная MBR разметка с её 3 типами разделов: http://xgu.ru/wiki/LVM

Мне он лично очень нравится, хотя из-за совместимости с IBM-PC на Linux он не такой красивый, как на AIX — там PV просто реальный PV, то есть LVM не поверх стандартной разметки, а и есть стандартная разметка.

Я вижу лишь одну проблему — если у человека OCD, то он может быть расстроен, что «неаккуратно», и что даже дефрагментация на ФС полностью «проблему» не решит… а уж как ему некомфортно SSD использовать, наверное, ведь там данные вообще через контроллер проходят, так что он сам выбирает, в какие ячейки писать, и может даже невидимо для ОС задействовать их из резервной зоны…

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)

На будущее, для домашнего компа хватит двух разделов: /boot/efi и /, всё.

swap сегодня идёт в zram.

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

Философия, дальше можно не читать.
Да, простые решения могут быть не самыми удобными на первый взгляд, но они того стоят: прелесть в том, что ты можешь забыть и забить, выключить комп и месяцами к нему не подходить, а потом включить и быстро сообразить чего у тебя и где. Упрощай, выкидывай, удаляй, отказывайся и не позволяй морочить себе голову нерелевантными конкретно для тебя вещами и однажды Линукс начнёт тебя радовать.

papin-aziat ★★★★★
()

Просто выясни в какую директорию система кладёт эти файлы, создай новое место (раздел или что там у тебя), перенеси эти файлы туда, с сохранением пермишенов, и примонтируй это новое место в эту директорию. Это суперсила linux - каждая (почти) директория может быть отдельным диском.

targitaj ★★★★★
()
Последнее исправление: targitaj (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

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

Раздел в нормальной разметке можно сдампить с помощью dd, не пользуясь ядерной поддержкой разделов,

dd if=/dev/sda bs=512 skip=(начало) count=(длина)

С LVM такого не получится, потому что там всё запутано и без алгоритмического вычисления координат каждого сектора не обойтись. Понятное дело, что это не просто так, а плата за его «гибкость» в ресайзах и прочем, но при нормальном использовании оно не нужно, а муть эта остаётся.

firkax ★★★★★
()
Ответ на: комментарий от papin-aziat

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

Верно,

/boot/efi

как раз из этой категории. А вот отдельный /home нужен. Более того, иногда бывает полезно сделать несколько разных разделов под /home и его аналоги, чтобы они не пересекались.

firkax ★★★★★
()
Ответ на: комментарий от firkax

dd if=/dev/sda bs=512 skip=(начало) count=(длина)

без алгоритмического вычисления

Почему bs=512, а не 256, например? Что будет если ошибиться в цифре «начало» или «длина» - неверные данные? И когда об этом станет известно?

Просто - это когда есть таблица с чёткими началом и концом каждого раздела (как автор привёл). Всё остальное - это лишняя путаница, непонятно зачем нужная.

Проще программировать на ассемблере или на питоне?

NyXzOr ★★★
()
Последнее исправление: NyXzOr (всего исправлений: 1)
Ответ на: комментарий от firkax

А нахрена вычислять с LVM границы сектора? Нахрена дампить разметку вообще?

Если ты о переносе системы с диска на диск, то с LVM можно мигрировать целые LV и VG со всем содержимым, в некоторых ситуациях на ходу.

Или сделать примерно такую же разметку и ФС dump/restore, чуть сложнее, но позволит переехать на диск меньшего размера с XFS, например.

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

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

С LVM такого не получится, потому что там всё запутано и без алгоритмического вычисления координат каждого сектора не обойтись. Понятное дело, что это не просто так, а плата за его «гибкость» в ресайзах и прочем, но при нормальном использовании оно не нужно, а муть эта остаётся.

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

Отличный пример в этом же треде — что в LVM занимает 2 команды на лету, в твоем варианте с классической разметкой сложная операция с LiveCD с риском потери данных и пересозданием разделов.

ФС создана была для того, чтобы люди могли не думать, в каком именно месте диска находится файл. LVM — чтобы могли не думать, как расположен том с ФС. Ты же не беспокоишься, что при копировании файлов с диска на диск они на новой ФС будут не в том порядке на поверхности диска расположены? Так зачем беспокоиться о том же с томами LVM?

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 8)
Ответ на: комментарий от Vsevolod-linuxoid

Я отключаю его.

Но спасибо, дельное замечание. Недавно так проклинал ктулху, когда сбрасывал пароль на свежей системе. Ничерта не работало. Причем и с ошибками и молча. А потом проверил, а это selinux на страже всего стоял…

AVL2 ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

У тебя неправильный подход. Дело не в том «зачем дампить» и дело не в дампе вообще. Дело в том что LVM создаёт ненужные усложнения, ничего полезного взамен не давая. dd - только наглядный пример того, как эти усложнения вылезают наружу.

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

Нечем там пользоваться, преимуществ нет. Это просто мусорные абстракции.

Отличный пример в этом же треде — что в LVM занимает 2 команды на лету
сложная операция с LiveCD с риском потери данных и пересозданием разделов.

Никаких рисков нет. И LiveCD тут ни при чём, он если где и нужен так это для resize2fs (хотя можно и без него), а оно уже от LVM никак не зависит. Просто автор новичок и я ему посоветовал быть осторожным. А так можно всегда риск найти: вдруг от rm -RF /* введёт - тоже риск, и не зависит от разметки вообще. Собственно, в этом («автор новичок») и причина нужности этой операции вообще. В нормальном случае с опытным юзером никаких ресайзов делать не потребуется вообще, потому что диск надо разбивать не наобум, а заранее продумав как он будет использоваться.

Ты же не беспокоишься, что при копировании файлов с диска

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

ничего полезного взамен не давая

Я буквально в этой теме привел пример полезного функционала: быстрая перенастройка ошибочной разметки на ходу. Есть ещё возможности организации RAID, снимки, много чего ещё.

dd - только наглядный пример того, как эти усложнения вылезают наружу

То, что забивать шурупы молотком неудобно, не делает их плохим вариантом крепежа.

Никаких рисков нет.

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

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

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

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от firkax

А вот отдельный /home нужен. Более того, иногда бывает полезно сделать несколько разных разделов под /home и его аналоги, чтобы они не пересекались.

Угу, а потом внезапно обнаружить, что места в одном разделе не хватает, в другом есть, но так как он спереди первого и меж ними ещё один забитый раздел, то ты в жопе… если не используешь LVM, конечно.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

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

На самом деле надо переписать 4 байта (8 если GPT) в таблице разделов, просто у fdisk нет команды редактирования существующего раздела и приходится немного костылить её аналог. Накосячить там можно только если быть невнимательным.

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

Это общие слова. На деле при адекватном использовании диска проблем не случается. Быстрее закончится место на разделе с данными (/home или аналоги) и это к покупке дополнительного диска или нового большего объёма, а не к мазохистическому перекраиванию оставшихся нескольких гигабайтов между разделами (после которого всё равно придётся покупать новый диск, т.к. они тоже быстро закончатся).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

Угу, а потом внезапно обнаружить, что места в одном разделе не хватает, в другом есть, но так как он спереди первого и меж ними ещё один забитый раздел, то ты в жопе… если не используешь LVM, конечно.

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

То есть если у меня есть раздел, где свободно 1,5 терабайта, и два забитых раздела по 50 и 100 гигов, то мне новый диск покупать вместо переразбивки средствами LVM в несколько команд для увеличения тех вдвое? Это и правда «неадекватной ценой».

Чувак, может хватит маняврировать? Я тебе уже 100500 примеров пользы LVM расписал, а ты «нинужно-нинужно». Серьезно.

Я понимаю, что лично тебе непонятна концепция LVM, но это не повод называть её бесполезной и отговаривать иных от её изучения. Тем более это стандарт индустрии, что RHEL, что Ubuntu Server используют это по умолчанию, и не без причины.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 2)
Ответ на: комментарий от Vsevolod-linuxoid

То есть если у меня есть раздел, где свободно 1,5 терабайта, и два забитых раздела по 50 и 100 гигов, то мне новый диск покупать вместо переразбивки средствами LVM в несколько команд для увеличения тех вдвое? Это и правда «неадекватной ценой».

И что это за два раздела такие? Может быть /etc и /tmp? Почему они именно 50 и 100 ГБ? Хватит приводить примеры в отрыве от реальности. Я причину подобных проблем вижу только одну - изначально неграмотную разбивку диска.

Я понимаю, что лично тебе непонятна концепция LVM

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

RHEL

Корпоративная политика часто выглядит странно и оторванно от реальности. Ещё они пропихивают пакостные systemd и гном3. Это не повод им доверять. Главная их цель - продать побольше контрактов на поддержку.

Ubuntu

Ну а ставить в пример болгеносы это вообще смех.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Хватит приводить примеры в отрыве от реальности.

Буквально эта тема подобный пример. Маленький забитый / при огромном пустом /home — предлагаешь бежать за новым диском? И «неграмотность» разметки от обстоятельств зависит. Не используй ТС snap, жил бы спокойно, Fedora можно и на 15 гигах уместить, если не ставить много ПО.

RHEL начал использовать LVM задолго до systemd и GNOME3, еще в 5 версии, ЕМНИП. И да, у них есть цель продать больше контрактов, но вот в серверной части они делают очень качественную работу, именно для этого.

И всерьез сравнивать Ubuntu с говносборкой от школьника может только ничего не смыслящий балабол. То есть она не идеальна, но это очень мейнстримный дистрибутив далеко не с самой слабой командой.

Вот Manjaro такого сравнения достойна: https://manjarno.snorlax.sh/

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Буквально эта тема подобный пример.

Да, пример новичка, заранее не разобравшегося что делать, как я и писал. Выделять под систему всего 2% объёма системного диска - плохая идея. По-хорошему, терабайтный диск вообще не стоило делать системным, лучше взять для системы какой-нить 100-200гб ссд, а терабайтный можно уже хоть mkfs /dev/sdb без разметки для /home. Заодно так намного удобнее будет шарить его между разными ОС, если автор захочет поэкспериментировать.

Не используй ТС snap, жил бы спокойно

Ну в целом да, использование снапа это одна из его ошибок. И небольшой оффтоп (всмысле, на проблему автора это никак не влияет): ставить софт в /var это очевидный идиотизм, он должен быть в /usr или /opt.

firkax ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

LVM прост как палка

прикладывает ссылку на простыню текста

На секундочку, типичный новичок примерно вот на этом месте:

VG, Volume group, группа томов. Это самый верхний уровень абстрактной модели, используемой системой LVM. С одной стороны группа томов состоит из физических томов, с другой -- из логических и представляет собой единую административную единицу.
LV, Logical volume, логический том. Раздел группы томов, эквивалентен разделу диска в не-LVM системе. Представляет собой блочное устройство и, как следствие, может содержать файловую систему.
PE, Physical extent, физический экстент. Каждый физический том делится на порции данных, называющиеся физическими экстентами. Их размеры те же, что и у логических экстентов.
LE, Logical extent, логический экстент. Каждый логический том делится на порции данных, называющиеся логическими экстентами. Размер логических экстентов не меняется в пределах группы томов.

закроет вкладку и пойдет ресетапнет систему с новой разметкой.

leave ★★★★★
()
Ответ на: комментарий от leave

Я уже просто считаю, что если человек не может или не хочет изучать Linux на уровне грамотного админа, то он не сможет его нормально использовать и бросит.

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

Нет, успехи бывают, но редко. Да и толку с них… они тоже мелкие. Опытным я не нужен, нубам в принципе нельзя помочь.

Vsevolod-linuxoid ★★★★★
()