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

иногда место заканчивается, когда заканчиваются иноды
а иноды иногда заканчиваются, когда ФС содержит ошибки
так что смотри df -i и думай

Filesystem       Inodes  IUsed    IFree IUse% Mounted on
devtmpfs        2016578    740  2015838    1% /dev
tmpfs           2024321    177  2024144    1% /dev/shm
tmpfs            819200   1452   817748    1% /run
efivarfs              0      0        0     - /sys/firmware/efi/efivars
/dev/nvme0n1p3        0      0        0     - /
/dev/loop5        20203  20203        0  100% /var/lib/snapd/snap/gnome-42-2204/29
/dev/loop0           29     29        0  100% /var/lib/snapd/snap/bare/5
/dev/loop6        20187  20187        0  100% /var/lib/snapd/snap/gnome-42-2204/44
/dev/loop1        12857  12857        0  100% /var/lib/snapd/snap/core/14399
/dev/loop2        13335  13335        0  100% /var/lib/snapd/snap/core22/444
/dev/loop4          307    307        0  100% /var/lib/snapd/snap/discord/145
/dev/loop3        13342  13342        0  100% /var/lib/snapd/snap/core22/469
/dev/loop7        76208  76208        0  100% /var/lib/snapd/snap/gtk-common-themes/1535
/dev/loop8          777    777        0  100% /var/lib/snapd/snap/pulsemixer/283
/dev/nvme0n1p2    65536    106    65430    1% /boot
/dev/nvme0n1p3        0      0        0     - /home
tmpfs           1048576     61  1048515    1% /tmp
/dev/nvme0n1p1        0      0        0     - /boot/efi
/dev/sda1      61054976 224383 60830593    1% /home/faza/1TB_space
tmpfs            404864    252   404612    1% /run/user/1000

А что мне думать то? Я понимаю как работают иноды лишь приблизительно. Я понял лишь то, что иноды все таки закончились, но что с этим делать, или как найти, что с этим делать - ни в зуб ногой.

Буду крайне благодарен, если объясните.

так, с инодами всё в порядке
значит загружайся с liveCD и делай fsck раздела, на котором установлена федора
только обязательно его (раздел) отмонтируй перед запуском fsck

Я ничего не понял, но почитал и кое что понял…

Мне короче надо скачать линукс на флешку, загрузится с нее, отмонтировать раздел с моей основной ОС и прописать что то типа: «sudo fsck /тыры/пыры»

Есть одна маленькая проблемка… Я не могу найти свою загрузочную флешку, а значит она либо благополучно ушла в мир мертвых и я ее выкинул, либо я ее успешно где нибудь всрал…

Завтра куплю новую флешку и доложу результаты.

ну тогда попробуй пересоздать базу dnf, раз такие дела
погугли, что это и как делать, я тут уже не подскажу ничего больше (раньше это делалось через rpm –rebuilddb)

Вообщем, я запустился с флешки. Вот выхлоп:

[liveuser@localhost-live ~]$ sudo btrfs check /dev/nvme0n1p3
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p3
UUID: 720b5ed3-8395-4507-8ae9-c30f9faedff1
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 119162417152 bytes used, no error found
total csum bytes: 113923856
total tree bytes: 1862828032
total fs tree bytes: 1582055424
total extent tree bytes: 124354560
btree space waste bytes: 388749731
file data blocks allocated: 142635974656
 referenced 164567568384

Я человек смелый, так что очень ссусь запускать sudo btrfs check --repair /dev/nvme0n1p3

Особенно после страшного как смерть передупреждения:

	Do not use --repair unless you are advised to do so by a developer
	or an experienced user, and then only after having accepted that no
	fsck can successfully repair all types of filesystem corruption. Eg.
	some software or hardware bugs can fatally damage a volume.
	The operation will start in 10 seconds.
	Use Ctrl-C to stop it.

Тем более, когда check показал, что ошибок нет.

Так что прошу вас, дорогие «Эксипиеренсед юзерс», помочь.

Стой на месте и ничего не делай пока не уничтожил всё.

Покажи df -h / и sudo btrfs filesystem df /

Есть, Сэр!

btrfs
no space left on device
Помогите кто чем может, люди добрые.

Никогда такого не было и вот опять.

Оке. Ещё sudo btrfs subvolume list /run/media/liveuser/fedora_localhost-live и за одно попробуй почистить /run/media/liveuser/fedora_localhost-live/var/cache и .cache в хомяке твоего юзера. Если прокатит - отделаешься малой кровью.

Обновление, влетевшее в no space left on the device на любой файлухе == проблемы.

Обновление, влетевшее в no space left on the device на любой файлухе == проблемы.

В обычной ФС достаточно просто удалить что-нибудь. Насколько я знаю, в btrfs от этой проблемы просто так не избавиться, нужно отдельно монтировать ее, подключать к ней раздел со свободным местом, тогда может быть получится что-то удалить.

Выхлоп от первой команды:

[liveuser@localhost-live ~]$ sudo btrfs subvolume list /run/media/liveuser/fedora_localhost-live
ID 256 gen 980923 top level 5 path home
ID 257 gen 981361 top level 5 path root
ID 258 gen 980388 top level 257 path root/var/lib/machines

Кэш в хомяке почистил, а вот папка «run» пуста.

Мне пробовать загружаться с основной системы?

Кэш в хомяке почистил, а вот папка «run» пуста.

А где я про run говорил? Я про /var/cache (не тот который в лайве)

Мне пробовать загружаться с основной системы?

Если она загружается, то можно попробовать

Ну btrfs и не обычная. С местом как повезёт, можно нарваться, да.

no space left on device

Ну показывай df -h и df -i.

Ура!

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

Когда будет время - отпишусь.

Всем спасибо

Проблема с запуском осталась.

Система запускается, только если добавить к командам запуска «selinux=0»

Это был еще не конец…

Подозреваю, что нужно исправить метки SELinux.

Сделай от суперпользователя в корне системы touch /.autorelabel и перезагрузи с включённым SELinux. Он сам перемаркирует всю файловую систему.

Файл .autorelabel уже лежал в корневой директории.

Я все равно прописал команду и сделал загрузку с включенным selinux.

Не помогло. Система падает в бесконечную загрузку.

Система падает в бесконечную загрузку

Ему нужно время, чтобы перемаркировать все твои файлы. Или ты что-то другое имеешь в виду?

В любом случае, если система грузится с отключённым SELinux и не грузится с включённым, у тебя два выхода: или отключить его совсем, или провести перемаркировку файлов. Рекомендую второе.

Я запустил систему с включенным SElinux.

Она стоит на экране загрузки больше часа.

Червячек все крутится и крутится…

Есть смысл продолжать, или это не поможет?

Червячек все крутится и крутится…

Ну так нажми ESC или что там нужно чтобы вместо «червячка» смотреть выхлоп загрузки. Кажется, стрелки вверх-вниз ещё работали на переключение режимов.

Если у тебя там до хрена мелких файлов, это может быть долго, да.

Поэтому полезно смотреть что сообщает система.

Собственно, что происходит при перемаркировке: система читает метку файла и проверяет её на соответствие тому, что записано в политиках. Если он не соответствует, ему назначается другая метка. И так для каждого файла.

Выхлоп вот такой.

Я проверял, продвижение не идет.

ты видишь, что crond мучается?
помоги ему, перезагрузись и передай ядру параметр systemd.mask=crond

ps. исправь теги - убери update, ошибка, добавь btrfs и другие нужные

Это норма! (с)

Помню как они (давно еще) сломали yum/rpm, спустив на юзеров корявую политику selinux. Обновить не получается- пакетманагер ею сломан. Красота.

Я в такие истории не влетал, всегда спасала перемаркировка.

Перед перезагрузкой /.autorelabel создавал?

Если создавал и не работает (я бы перепроверил на всякий случай), то ищи как восстановить контексты файлов без перезагрузки.

Первое, что гуглится, это fixfiles, справка для RHEL5, где он упоминается, и справка по SELinux для RHEL9.

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

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

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

Когда ты после этого загружаешься в систему снова, SELinux видит какие-то незнакомые файлы без меток и сообщает, что с этим он работать не будет. А у него основной принцип, что запрещено всё, что не разрешено.

Если от изменённых файлов зависит работа системы, то система предсказуемо не загрузится. Единственный способ исправить это – дать SELinux понять как работать с этими файлами. То есть, провести маркировку.

В RHEL и RHEL-based дистрибутивах SELinux включён по умолчанию. SLES/openSUSE/Ubuntu используют Apparmor, который разрешает всё, что не запрещено. Емнип, встальные никаких модулей безопасности по умолчанию не включают.

Команда: fixfiles relabel выдает такой аутпут:

[faza@Fortress-Accident ~]$ sudo fixfiles relabel

    Files in the /tmp directory may be labeled incorrectly, this command
    can remove all files in /tmp.  If you choose to remove files from /tmp,
    a reboot will be required after completion.

    Do you wish to clean out the /tmp directory [N]? n
fixfiles: No suitable file systems found
Cleaning up labels on /tmp
cat: /initial_contexts/unlabeled: No such file or directory
secon: SELinux is not enabled

secon: SELinux is not enabled

-очень ироничная строка, учитывая то, что с включенным SElinux система не запускается.

Но это не столько важно, так как:

Use the following procedure to relabel a file system using this method.

touch /.autorelabel
reboot

At boot time, init.rc checks for the existence of /.autorelabel. If this file exists, SELinux performs a complete file system relabel (using the/sbin/fixfiles -f -F relabel command), and then deletes /.autorelabel.

В последний раз, я держал систему в загрузке 2 часа (не знаю, достаточно ли этого для перемаркировки всех файлов, но что то мне подсказывает, что дело не во времени)

P.S. - Может, следующая информация сможет помочь следствию:

в моем районе часто случаются перепады напряжения. Например, вчера после выключения света, моя сетевая ноутбучная wi-fi карта (спасибо горе-сборщикам) перестала подавать признаки жизни (я пока не разбирался с ней, т.к. времени нет). Такие перепады, насколько я знаю, происходят регулярно. Однажды было зафиксировано напряжение в розетке - 250V.

Может ли это быть как то связанно с этой проблеммой?

SELinux is not enabled

Ну да, действительно :3 Можно попробовать загрузиться в permissive mode и сделать перемаркировку под ним.

но что то мне подсказывает

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

Ты либо /.autorelabel не создал перед перезагрузкой, либо по какой-то причине система его игнорирует. Второе было бы очень странно.

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

Если она по какой-то причине неудачно заканчивается, об этом тоже будет сообщение. Можно его не только сюда скопипастить, но и в гугле забить.

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

Чисто практически есть несколько выходов из этой ситуации. Перемаркировка файлов была бы самым простым.

Может, следующая информация сможет помочь следствию

Я бы на твоём месте о покупке ИБП подумал, если это у тебя регулярно случается. Но если с отключённым SELinux загрузка происходит нормально, то файловые системы у тебя целы.

судя по описываемым FAZA симптомам, ему больше подойдёт стабилизатор напряжения

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

.autorelabel в корне был и есть, но система не начинает перемаркировку.

Хм. Попробуй загрузиться в permissive mode.

Changing to permissive mode

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

Но судя по выводу консоли, он у тебя включен, потому что там видны его сообщения, все эти AVC с Permission denied.

Хотя да, всё верно, тут же и пишут, что сначала нужно переключиться в permissive mode, а потом создавать файл. Очевидно, для того, чтобы SELinux не игнорировал .autorelabel.

То есть, когда загрузишься в permissive mode, тебе нужно удалить старый и создать новый.

Итак, дамы и господа.

Наша 3х дневная эпопея наконец-то завершилась.

Рассказываю о произошедшем:

Я включил permissive mode по гайду (для тех, кто возможно сталкнется с такой проблеммой в будующем - не тупаните как я, ваш файл config должен выглядеть так:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# See also:
# https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/#getting-started-with-selinux-selinux-states-and-modes
SELINUX=pemissive
# NOTE: In earlier Fedora kernel builds, SELINUX=disabled would also
# fully disable SELinux during boot. If you need a system with SELinux
# fully disabled instead of SELinux running with no policy loaded, you
# need to pass selinux=0 to the kernel command line. You can use grubby
# to persistently set the bootloader to boot with selinux=0:
#
#    grubby --update-kernel ALL --args selinux=0
#
# To revert back to SELinux enabled:
#
#    grubby --update-kernel ALL --remove-args selinux
#
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

и желательно никак иначе). Я зачем-то решил сначала перезагрузить систему, а только потом создавать .autorelabel. Перезагрузил, отошел от компа, и нашел его уже отключенным. После включения он загрузился в штатном режиме с включенным SElinux.

Данное положние дел подталкивает к следующему выводу:

видимо SElinux делает ремаркировку файлов в permissive mode в автоматическом режиме и данный гайд говорит нам о создании .autorelabel только в контексте ручной перемаркировки.

В целом, это логично, так как если внимательно почитать вот этот гайд вы там ни слова не найдете об .autorelabel.

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

Ваш вклад в это сообщество неоценим♡

Поздравляю.

видимо SElinux делает ремаркировку файлов в permissive mode в автоматическом режиме

Чёрт его знает, если честно. Скорее всего, в permissive mode он наконец-то среагировал на /.autorelabel и принялся перемаркировывать, после чего и отключился (хотя вроде должен перезагружаться, но может что и путаю).

если внимательно почитать вот этот гайд вы там ни слова не найдете об .autorelabel.

Естественно, потому что гайд не про перемаркировку, а про переключение режима.

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

Вся суть в том, что я удалил /.autorelabel перед перезагрузкой.

Я не переключал режимы, так что сейчас стоит Permissive. Будет ли система работать, если я переключу режимы обратно - хз. Потом попробую переключить обратно и отпишусь.

А, ясненько. Тогда всё ещё нужно провести перемаркировку, потом переключиться в enforcing mode.

Как проводить перемаркировку ты уже в курсе, переключение в enforcing mode описано в следующей главке после переключения в permissive, по той же ссылке.

Перемаркировка прошла в штатном режиме. В enforcing mode переключился.