Linux — одна победа, одна ничья и одно поражение.

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

Загадка монтирования дисков

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

systemd-fstab-generator[175]: Failed to create mount unit file
/run/systemd/generator/media-ntfs\x2dsdb2.mount, as it already exists. 
Duplicate entry in /etc/fstab?

Причем, таких строчек от загрузки к загрузке становилось больше.

Это при том, что у меня диски, заполненные разной информацией еще в винде, подключаются с использованием fstab, где я прописал их вручную. Открываю fstab и вижу, что там действительно появилась куча строк, которые я не писал, причем, почти все встречаются по два-три раза в произвольном порядке.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb3 during installation
UUID=6279-419e-b679 /               ext4    errors=remount-ro 0       1
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sda5   /mnt/WORK   ntfs    auto,exec,rw,nouser,async,iocharset=utf8,notail,relatime 0 0
/dev/sda6   /mnt/STORAGE    ntfs    auto,exec,rw,nouser,async,iocharset=utf8,notail,relatime 0 0
/dev/sda7   /mnt/FILES  ntfs    auto,exec,rw,nouser,async,iocharset=utf8,notail,relatime 0 0
/dev/sda8   /mnt/MISC   ntfs    auto,exec,rw,nouser,async,iocharset=utf8,notail,relatime 0 0
/dev/sdb2   /mnt/FILES2 ntfs    auto,exec,rw,nouser,async,iocharset=utf8,notail,relatime 0 0
/dev/sda7 /media/ntfs-sda7 ntfs-3g rw,noauto,dmask=000,fmask=000,user,locale=ru_RU.utf8,allow_other 0 0
/dev/sdb1 /media/ntfs-sdb1 ntfs-3g rw,noauto,dmask=000,fmask=000,user,locale=ru_RU.utf8,allow_other 0 0
/dev/sda5 /media/ntfs-sda5 ntfs-3g rw,noauto,dmask=000,fmask=000,user,locale=ru_RU.utf8,allow_other 0 0
/dev/sdb2 /media/ntfs-sdb2 ntfs-3g rw,noauto,dmask=000,fmask=000,user,locale=ru_RU.utf8,allow_other 0 0

И вот те строки внизу, которые монтируются в /media/, размножаются просто неприлично.

Жуть! Стер. Через пару загрузок (комп включен отнюдь не 24/7) вижу ту же картину и в консоли при загрузке, и в файле fstab. Что за дела?

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

Лирическое отступление

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

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

• systend-fstab-generator
• hotplug
• automount
• hal
• halevt
• kudzu
• dracut (systemd-drakut)
• udev (systemd-udevd)
• fstab-sync
• submount

Почитал про упомянутые штуки. Показалось, что udev — наиболее вероятная кандидатура пакостника. Однако поиск по системным логам через grep 'fstab' не дал ничего, и я не понял, кто и когда туда пишет.

Тогда, предполагая, что этот «кто-то» пишет, основываясь на своих настройках, которые, в свою очередь, лежат где-то в /etc/, запустил поиск файла, содержащего 'fstab'

$ grep -r "fstab" /etc/

и самым интересным в результатах поиска был /etc/udev/rules.d/10-automount.rules:

#ACTION=="add" KERNEL=="sd[a-z][0-9]" RUN+="/bin/mkdir -p /mnt/%k"
#ACTION=="add" KERNEL=="sd[a-z][0-9]" RUN+="/bin/mount -o uid=1000 /dev/%k /mnt/%k"
#ACTION=="remove" KERNEL=="sd[a-z][0-9]" RUN+="/bin/rmdir /mnt/%k"

#ACTION=="add" KERNEL=="sd[a-z][0-9]" RUN+="/bin/mkdir -p /mnt/%E{ID_VENDOR}_%E{ID_MODEL}_%n"
#ACTION=="add" KERNEL=="sd[a-z][0-9]" RUN+="/bin/mount -o uid=1000 /dev/%k /mnt/%E{ID_VENDOR}_%E{ID_MODEL}_%n"
#ACTION=="remove" KERNEL=="sd[a-z][0-9]" RUN+="/bin/rmdir /mnt/%E{ID_VENDOR}_%E{ID_MODEL}_%n"

# монтирование съемных накопителей
KERNEL=="sd[a-z]", GOTO="do-disk-rules"
KERNEL!="sd[a-z][0-9]", GOTO="end-of-file"
LABEL="do-disk-rules"
ACTION=="add", ENV{ID_USB_DRIVER}="usb-storage", GROUP="storage"
IMPORT{program}="/sbin/blkid -o udev -p %N"
ACTION=="remove", ENV{ID_FS_TYPE}!="", RUN+="/bin/sed -i '/\/dev\/%k /d' /etc/fstab"
ACTION=="remove", ENV{ID_FS_TYPE}!="", RUN+="/bin/rmdir /media/$env{ID_FS_TYPE}-%k"
ACTION=="add", ENV{ID_FS_TYPE}!="", RUN+="/bin/mkdir -p /media/$env{ID_FS_TYPE}-%k"
# монтирование раздела fat32
ACTION=="add", ENV{ID_FS_TYPE}=="vfat", RUN+="/bin/sed -i 
'$a\/dev/%k /media/$env{ID_FS_TYPE}-%k vfat rw,noauto,noatime,dmask=000,user,fmask=000,iocharset=utf8 0 0' /etc/fstab"
# монтирование раздела ntfs
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/sed -i 
'$a\/dev/%k /media/$env{ID_FS_TYPE}-%k ntfs-3g rw,noauto,dmask=000,fmask=000,user,locale=ru_RU.utf8,allow_other 0 0' /etc/fstab"
# монтирование прочих ФС
ACTION=="add", ENV{ID_FS_TYPE}!="", ENV{ID_FS_TYPE}!="ntfs|vfat", 
RUN+="/bin/sed -i '$a\/dev/%k /media/$env{ID_FS_TYPE}-%k $env{ID_FS_TYPE}  defaults,user 0 0' /etc/fstab"
LABEL="end-of-file"

Строчка в правилах монтирования однозначно соответствовала тому, что появляется в fstab. Возможно, авторы пакета, создавая настройки по умолчанию, предполагали, что основным диском будет hda, а sda — уже всякие флешки и все такое. А у меня два SATA-винчестера, и флешка становится sdc. Ну что же, пакостник найден, надо его слегка укротить. Сперва я сделал первое, что пришло в голову: вписал после # монтирование съемных накопителей пару строк:

# монтирование съемных накопителей
KERNEL=="sda[0..9]", GOTO="end-of-file"
KERNEL=="sdb[0..9]", GOTO="end-of-file"
KERNEL=="sd[a-z]", GOTO="do-disk-rules"
# ... и далее по тексту ...

чтобы при обнаружении первых двух SATA-дисков правила монтирования пропускались. Но буквально парой минут позже понял, что это дурь, и сделал проще — убрал эти строки, а во всех sd[a-z] заменил a на c:

KERNEL=="sd[c-z]", GOTO="do-disk-rules"

И в остальных строках так же. Теперь /ets/fstab после перезагрузок остается неизменным (даже после автомонтирования флешек), и при загрузке упомянутая ересь тоже не встречается. Одну проблемку решил. Засчитываю победу.

Выключение кнопкой питания

Фишка, давно ставшая привычной в Windows, довольно удобная. Все-таки, одно движение пальца, хоть и надо тянуться к системнику. Дай, думаю, попробую… А компьютер вырубился, как будто провод выдернули.

Полез опять в интернеты. Нашел, что за отслеживание событий, связанных с питанием, отвечает acpi. Убедился, что такой пакет у меня установлен. Настройки в /etc/acpi/powerbtn-acpi-support.sh посмотрел — нормально все.

Там указано, что для совместимости со старыми версиями при наличии в определенных местах старых скриптов все игнорируется и exit 0, так у меня в тех местах нету нифига лишнего…

Тут где-то в интернете (не помню точно, в чьем-то блоге) одному товарищу нужна была обратная задача: добиться отсутствия реакции на кнопку, и он в упомянутом sh-файле закрыл предпоследнюю строку:

/sbin/shutdown -h -P now "Power button pressed"

Сделал так же. Перезапустил демон:

$ sudo acpid restart

Ничего не изменилось. Вернул строчку обратно (раскомментировал) — заработало! Почти…

В общем, после этих телодвижений, имевших в сумме чистый ноль, по нажатию кнопки питания компьютер стал засыпать. Ну, и просыпаться, конечно. Почитал повнимательнее скрипт — а там упоминаются настройки среды, мол, они тоже учитываются. Слазил в настройки Гнома (Приложения – Системные – Дополнительные параметры – Электропитание), а в них для параметров питания указано «Hibernate» по кнопке питания. Изменил на «Shutdown». Теперь компьютер засыпает по кнопке сна на клавиатуре и выключается по кнопке питания на системнике.

Очень странно. Единственное мое активное действие (помимо закрытия и открытия строчки в скрипте) — перезапуск демона acpid, но я посмотрел логи grep 'acpi' и не нашел отличий «до» и «после». Он и раньше запускался.

Загадочно. Вроде, все работает. Вроде, раньше не работало. Вроде, ничего не делал. Засчитываю ничью.

Обновление Eclipse

А вот тут, что называется, косорезик вышел. Поставил Eclipse из репозитория через Synaptic. Встала версия 3.8, и где-то в Help нашел, что это Indigo. И это в наше время, когда космические корабли уже долетели до Марса, и даже до Марса 2, и под виндой у меня стоит 4.5.1. Причем, обновился до нее с Луны довольно просто, указав в нужных местах сервера обновлений и запустив не то установку нового ПО, не то обновление, не то оба по очереди.

А тут фигушки! Основная часть, которая собственно Eclipse, ставиться наотрез отказалась. Дескать, стоит уже и незачем ставить снова, и неважно, что версия уже новая… Ну, а все остальные «запчасти» зависят от движка и тоже не хотят обновляться. Часа полтора долбился в эту стенку. Потом плюнул, снес Eclipse начисто и скачал с официального сайта tar-архив. Распаковал в домашней папке — вот и вся установка, все работает. Благо, зависимостей у него особых нет, кроме Java, а с ней я разобрался чуть раньше, снес openjdk и поставил продукт от Oracle. А то под open у меня напрочь отказывались запускаться поделки, которые я наваял еще в винде, те же «Быки и коровы».

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