Ошибка при создании жёсткой ссылки

https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg2058822.html

Покажи вывод mount.

Какая часть ФС у тебя на отдельном разделе? Тоже /usr?

Вообще не понятно зачем в пакете hard link, если достаточно symlink в большинстве ситуаций.

Напротив hard link нужен в очень специфичных случаях.

Напротив hard link нужен в очень специфичных случаях.

Например? Я как прочитал про хардлинк дюжину лет назад, так и не придумал с тех пор ни одного такого случая.

Сейчас таки загуглил. Оказывается, хардлинки используются rsync, timeshift, Back in Time для создания инкрементальных бекапов. Согласен, это полезно. А есть ли ещё какой-то ещё смысл?

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

mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7824108k,nr_inodes=1956027,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1572404k,mode=755,inode64)
/dev/nvme0n1p9 on / type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@rootfs)
/dev/nvme0n1p5 on /usr type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=23132)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p2 on /boot type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p7 on /usr/local type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p6 on /opt type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p4 on /var type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p8 on /home type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1572400k,nr_inodes=393100,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

На всех разделах, файловая система BTRFS

Разрабы пишут: «так надо». правда, не уточняют - кому надо…

Пересобирай пакет из dsc файла, что бы был симлинк, либо убирай /usr в основную ФС, после решения об объединении /bin -> /usr/bin поддержка /usr на отдельной фс не гарантируется.

Понял. Спасибо.

а подсунуть ему какой-нить алиас/скрипт с подменой команды ln не проканает? ну, по-тупому.

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

Придётся пересобрать пакет. Подобные команды обычно вызываются в post-install-скрипте пакета, а подменить этот скрипт на лету без пересборки нельзя.

А есть ли ещё какой-то ещё смысл?

Файлы a и b могут переименовываться (например переодически генеряться с ротацией предыдущей версии в .1, .2 итд), и хочется чтобы после переименования мы продолжали ссылаться на правильный файл (b.1 показывала на a.1 а не на a). Атомарная ротация, опять же (условно «create a.tmp; ln a a.1; mv a.tmp a;», тот кто пытается открыть a на чтение получит a или a.1, но никогда не ошибку). Примеры из реальной жизни.

Посмотрел пакет https://packages.element.io/debian/pool/main/e/element-desktop/index.html это уже в файлах сразу /usr/share/icons/hicolor/512x512/apps/element-desktop.png является жёсткой ссылкой на /opt/Element/ что-то там.

Т.е. даже не смотря на то, что /usr не стоит выносить, а у автора он вынесен, но никто не запрещает вынос /opt на отдельную файловую систему.

Т.е. при установке данного пакета, даже если /usr будет на корневой ФС, но в системе будет вынесен /opt - тоже будет ошибка.

В общем, автор этого deb пакета собрал всё через одно место.

Iron_Bug - так что - пересборка пакета.

Можно, конечно

mkdir /tmp/root
mount -o bind / /tmp/root
cp /opt/Element /tmp/root/opt -R
mkdir -p /tmp/root/usr/share/icons/hicolor/512x512
cp /usr/share/icons/hicolor/512x512/apps /tmp/root/usr/share/icons/hicolor/512x512/ -R

поиграться, а потом с /tmp/root на / сделать обратный bind, но думаю не получится.

В общем, автор пакета сам себе выстрелил в ногу. И автор топика тоже.

Ну это вообще странное решение. Автору пакета бить по рукам.

Автор топика может достать файлы из deb, положить в /opt и потом создать нужные символьные ссылки в /usr и других частях файловой системы руками.

Либо собрать самому из исходников.

Да, будет каша, но из исходников можно собрать нормальный deb пакет с символьной ссылкой.

А разве размещение файлов пакета в /opt это не нарушение полиси в этих ваших дебианах? В мире rpm за такое ругают. Если весь пакет целиком в /opt ещё ладно, но и там и в /usr это же фу

В /usr в пакете идёт иконка и, предполагаю, application-файл. Эти файлы в других местах не могут быть, всё остальное же в /opt. Так что нарушения никакого нет.

И да, обычно делают симлинки и не жужжат.

не нарушение полиси в этих ваших дебианах?

Первое, пакета нет в официальном репозитории Debian.

Второе, автор пакета нарушает LFS о том, что /opt может быть на отдельной ФС.

Третье, автор темы, нарушает LFS, поддержка /usr на отдельной ФС на текущий момент вообще не гарантируется.

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

Т.е. даже не смотря на то, что /usr не стоит выносить, а у автора он вынесен, но никто не запрещает вынос /opt на отдельную файловую систему.

Тут изначально три странности: зачем иерархия /usr/ в дополнение к корневой? почему она называется /usr/? и почему есть ещё и третья иерархия, /usr/local/? А дело в том, что корневая иерархия - для минимальной работоспособности, /usr/ - для монтирования полноценного пользовательского окружения с удаленного хоста, а /usr/local/ - для дополнительной кастомизации каждого отдельного локалхоста. В общем, деды как могли экономили дисковое пространство в условиях локалки.

Я, кстати, выносил /usr/, создавал /usr/opt/, делал ln -s /usr/opt /opt, и у меня всё работало. Тут, скорее, нет смысла выносить /usr/, не вынося /opt/. Да и в целом смысла дробить диск всё меньше, особенно на локалхосте.

Т.е. при установке данного пакета, даже если /usr будет на корневой ФС, но в системе будет вынесен /opt - тоже будет ошибка.

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

Спасибо за расследование.

Почитай почему вообще появился /usr, если кратко, то когда Unix системы создавались накопители были маленькие и на корневой ФС были библиотеки и программы, необходимые для запуска системы, а пользовательский (дополнительный) софт уже не влезал, поэтому подключили ещё один накопитель и его смонтировали в /usr и получилось две отдельные ФС.

На текущий момент диски большие и решили унифицировать

/bin <-> /usr/bin
/sbin <-> /usr/sbin
...

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

/bin -> /usr/bin
/sbin -> /usr/sbin
...

Поэтому для нормального запуска системы /usr должна быть на одной файловой системе с корнем. Но вынос /usr не обязательно пирведёт к невозможности загрузки системы.

Это всё сделано только ради унификации.

Иначе в initramfs нужно менять логику, чтобы монтировался не только root, но и то, что указано в /etc/fstab для /usr и уже потом делался pivot_root.

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

Автор deb пакета сам себе буратино, не нужна там жёсткая ссылка.

Второе, автор пакета нарушает LFS о том, что /opt может быть на отдельной ФС.

Linux from Scratch или всё-таки Filesystem Hierarchy Standard?

Третье, автор темы, нарушает LFS, поддержка /usr на отдельной ФС на текущий момент вообще не гарантируется.

Если /usr/ нельзя выносить, почему он в FHS перечислен среди sharable? Тут ты, видимо, свои представления приписал авторитетному источнику, который не читал.

Почитай почему вообще появился /usr

Так я о том же. Просто этот дополнительный диск часто делали сетевым. Это логично и с точки зрения экономии ресурсов, и в плане того, почему /usr/local называется именно так. Цитата из FHS: «The original idea behind ‘/usr/local’ was to have a separate (‘local’) ‘/usr’ directory on every machine besides ‘/usr’, which might be just mounted read-only from somewhere else».

Иначе в initramfs нужно менять логику, чтобы монтировался не только root, но и то, что указано в /etc/fstab для /usr и уже потом делался pivot_root.

А вот это интересно.

точка в начале пути: - «я для вас шутка какая-то?»

Это в первую очередь из-за systemd: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Читай. LFS - общий стандарт для Linux в целом.

Немного ошибся, но сути не меняет. Если в системе systemd и в дистрибутиве merged /usr на текущий момент - то будут проблемы.

Если автор условно сидел на системе, где изначально не было merged /usr, а это лишь появилось с некоторой версии, а он не выполнял инструкции по объединению или сам разнёс /bin и /usr/bin и прочие - у него всё будет работать.

Сути это всё не меняет, в современном Linux по умолчанию не поддерживается отдельный /usr, т.е. разработчики ПО, мантейнеры дистрибутива не обязаны поддерживать работу систем и приложений в случае, если /usr - на отдельной ФС, но и блокировать это тоже не будут.

Использующие отдельный /usr должны сами решать свои проблемы в работе софта.

ОК, убедил, спасибо.

я про подмену самого /usr/bin/ln. в смысле, временно вместо него скрипт подсунуть, который будет параметры подменять принудительно.

А. На время установки пакета. Ну да, как вариант.

Но я бы таки пересобрал пакет. Не из исходников, а просто разобрал этот пакет, убрал из DEBIAN/* упоминание хардлинка, добавил бы в postinst ln -s и упаковал бы назад, как это должно было быть сделано изначально. Делов на 10 минут.

Почитай внимательно https://ubuntu.com/blog/what-are-dependencies . Я почитал, очень занимательно. Это про убунту, но и для debian может подойти.

Я конечно нуб, но ошибка вроде как в этапе распаковки архива, а не в установки в систему, возможно у TC выключены жёсткие ссылки в каком-нибудь /tmp мли /var/tmp через xattr там где происходит распаковка и подготовка пакета системой apt перед слиянием с /.