Проклятый systemd заломал мой тестинг

Это уже второй случай факапа с nofail, который я наблюдаю. Оба раза, ЧСХ, во всём обвинили systemd и его разработчиков.

Ну вот тебе в копилочку еще одна поломатость связанная с монтированием. Такая строчка в /etc/fstab ломала загрузку:

/home/user/.bindDirs/Mausoleum            /home/user/Mausoleum         auto            bind

/home/user/.bindDirs/Mausoleum            /home/user/Mausoleum         auto            bind  0  0

The sixth field (fs_passno)...... If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

systemd и его разработчики не виноватые?

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

Нет, виноватые кривые руки мейнтейнеров твоего дистрибутива.

Таки причем тут мантайнеры дестрибутива? Не попатчили systemd, чтобы отучить его от нестандартного поведения?

При том что в нормальных дистрибутивах все работает, так что надо чинить руки. И для этого не нужны патчи.

systemd и его разработчики не виноватые?

Линк на багрепорт или балабол.

Линк на багрепорт или балабол.

Нету линка. Проверил, сейчас все работает как в мане, можно и без ноликов. Забавно, но багрепортов про это не нашел, видать само починилось. Просто неудачное стечение обстоятельств: в 208 они поломали fsck для non-devices и потом до того как это починилось в 209, случилось что fsck начал плевать на умолчания (а вот про это вообще ничего не нашел). Вот тут я и попался. Правда я дописал нолики, успокоился и просто подумал что создатели systemd просто поменяли стандарты. Таки выходит на святое разработчики systemd не замахивались, просто кривой код.

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

Ой дядька - совсем мимо. Ибо дистр - арч. Ты вот, если спец по systemd, ответь на вопрос ниже. Сам баг с дохлыми иксами возможно даже и монтайнеры арча спровоцировали, они там этот патч для non-devices туда-сюда дергали. Но суть, что systemd три месяца, от одного к следующему релизу был поломатый. Если интересно, то 64e70e4b86d ломает, а e2f123b97b9a - чинит.

Почему systemd рвался запустить fsck не на файловой системе - понятно. Не понятно, почему там где явно не указано что файловая система подлежит проверке, пытаются запустить fsck. Вот кстати, выходит багрепорт писать всетаки нужно:

$ cat /etc/fstab|grep c3810902
UUID=c3810902-92d4-4ea2-8320-899e62c51c94	/home/bigboss/.bigBindDirs	ext4		rw,relatime,data=ordered

$lsblk
/dev/sdb6: UUID="c3810902-92d4-4ea2-8320-899e62c51c94" TYPE="ext4" PARTLABEL="BigBoss home" PARTUUID="cc0d029a-7d14-439d-ba97-e8a00b4223c8"

systemctl|grep c3810902
systemd-fsck@dev-disk-by\x2duuid-c3810902\x2d92d4\x2d4ea2\x2d8320\x2d899e62c51c94.service loaded active exited    File System Check on /dev/disk/by-uuid/c3810902-92d4-4ea2-8320-899e62c51c94

systemd-fsck[815]: /dev/sdb6: clean, 515129/10485760 files, 35374611/41943040 blocks

И ты, timuaz, подскажи [как специалист по systemd], где почитать правила по которым динамически создаются юниты монтирования из fstab? Логическое мышление есть, нет желания ковырять исходники systemd в поисках ответа на вопрос: каково значение по умолчанию для fs_passno? Единственное, что нашел, это фак красношляпых, где они говорять что если не хочешь проверки - пиши явно нуль. Но фак это как бы не документация.

$ grep linux-data /etc/fstab
/dev/disk/by-label/linux-data    /mnt/data              ext4     noatime,data=writeback,discard,noauto,x-systemd.automount

$ systemctl | grep 'linux\x2ddata'

$ journalctl -b | grep linux-data

$

Если что-то было сломано раньше — ну, значит, было сломано. Бывает. Значит, я не заметил.

нет желания ковырять исходники systemd в поисках ответа на вопрос

А зря... :) Это единственный 100% метод найти точный ответ по systemd...

во-первых, школолоарч. ну ты понял, да?

что systemd три месяца, от одного к следующему релизу был поломатый. Если интересно, то 64e70e4b86d ломает, а e2f123b97b9a - чинит.

Багрепорты в студию. что поломано, чем исправили.

Вот кстати, выходит багрепорт писать всетаки нужно:

Все-таки? Ты совсем идиот чтоли? Разработчики должны коннектится к тебе через libastral?

где почитать правила по которым динамически создаются юниты монтирования из fstab?

man systemd.mount

man systemd.service

man systemd.automount

Багрепорты в студию.

Дядька ну нельзя же себя таким неумным выставлять. Ты ладно бы сделал вид, что не заметил. Но ты ПРОЦИТИРОВАЛ хэши ломающего и чинящего коммитов. (и да это про проверку не-устройства, интерпретация отсутствия значения fs_passno не как 0 - это кажется для systemd нормальное поведение)

man...

Читал, не нашел. Сейчас попробую перечитать. А еще где-нибудь может быть? Мне кажется это важно, если systemd при преобразовании fstab интерпретирует его несколько иначе. Наыерное, что им стоило об этом написать.

интерпретация отсутствия значения fs_passno не как 0 - это кажется для systemd нормальное поведение

Это не так: Проклятый systemd заломал мой тестинг (комментарий)

Это не так

Объясни, где ты нашел документацию как systemd интерпретирует твою строчку из fstab? (man 5 fstab - не подходит). У тебя там systemsd-cпецифичные опции монтирования, собственно эта партиция монтируется не при загрузке, а при первом обращении

man systemd.automount: Example: if an automount unit home-lennart.automount is active and the user accesses /home/lennart the mount unit home-lennart.mount will be activated.

Где описано поведение fsck в данном случае?

man 8 systemd-fstab-generator, который отсылает за подробностями в man 5 fstab. Поэтому можно считать, что поведение systemd должно соответствовать описанному в fstab(5).

То, что у меня automount, никак не влияет на поведение fsck. Оно описано в man 8 systemd-fsck.

Однако надоело спорить, и да Леннарт - опять не виноватый. Зачем либЦэ так делает, но:

#include <stdlib.h>
#include <stdio.h>
#include <mntent.h>

main()
{
	FILE *f;
	struct mntent *me;
	f = setmntent("/etc/fstab", "re");
	if(!f){
		printf("ERRRORRR!!!!");
		exit(2);
	}
	while ((me = getmntent(f))){
		printf("mnt_dir = %s\t",me->mnt_dir);
		printf("mnt_passno = %d\n",me->mnt_passno);
	}
}

Кусок fstab'a:

UUID=1527c960-50eb-4720-a587-ee8a26a5d456	/home				ext4		rw,relatime,data=ordered,discard 
UUID=c3810902-92d4-4ea2-8320-899e62c51c94	/home/bigboss/.bigBindDirs	ext4		rw,relatime,data=ordered,discard,noauto,x-systemd.automount

mnt_dir = /home	mnt_passno = 2
mnt_dir = /home/bigboss/.bigBindDirs	mnt_passno = 2

 if (passno != 0) {
                r = generator_write_fsck_deps(f, arg_dest, what, where, fstype);
                if (r < 0)
                        return r;
        }

Я у себя наблюдаю корректное поведение... Может, всё-таки дистропроблемы? // системы под рукой нет, скомпилять не могу

И виноват во всем ненужный пробел после четвертой записи (опций монтирования). getmntent() странно парсит /etc/fstab: если после четвертой записи идет конец строки, то fs_freq и fs_passno равны нулю. А иначе туда попадает мусор ибо думают, что sscanf() может вернуть только 0,1 или 2.

Читай выше - виноват лишний пробел в конце строки и кривой либЦэ.

Линк на багрепорт или балабол.

Теперь можно и написать багрепорт. Проблема в glibc, misc/mntent_r.c, [у меня 167 строка]; функция __getmntent_r(), там в самом конце не проверяют, что sscanf() может вернуть EOF. В результате, если строка в fstab не кончается концом строки, то в fs_passno и fs_freq - мусор. Ну и вообще, там все плохо.

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

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

кажись этот прикол с 1996 года

Это багофича - в fstab и скриптах всегда рекомендовали пустую строку оставлять. Просто раньше прокатывало, а с поделкой получается нет...

И виноват во всем ненужный пробел после четвертой записи

Ну, то есть виноват кривой конфиг. ЧИТД.

Да, уже увидел.

Поделка вообще не при делах. Запись в fstab вида

/dev/sda1    /home    ext4    rw,relatime

/dev/sda1    /home    ext4    rw,relatime  

От системы инициализации это не зависит. redgremlin, объясни, в чем кривизна конфига? Это явный баг в функции парсящей строчку fstab.

Нет. То же самое было у меня на одной самопальной системе, где вообще ничего, кроме ядра и busybox-static, не было. Нули приходилось явно прописывать.