Зависимости логина от mnt

Ага, для секретарши Маши это как косынку запустить.

Если «всё сломалось», один фиг к ней идти.

Свой системд с собой патченный таскать?

Разработчики systemd не принимают конструктивной критики? Поддерживающие дистрибутива не принимают конструктивной критики?

Если «всё сломалось», один фиг к ней идти.

man ssh

Это заранее известно.

Откуда? Может у меня в /mnt абсолютно важная инфа. Инит об этом гадать не должен.

Читайте man fstab внимательнее.

Я то читал внимательно. Здесь reports, как и во многом в unix, подразумевает код возврата из функции. Соответственно при nofail код возврата не возвращает ошибку, и загрузка не останавливается. А сообщение об ошибке он естественно выдает. Специально ребутался, чтобы проверить.

Вопрос на засыпку: А как мне заставить SysV со товарищи ни в коем случае не загружаться при ошибке монтирования раздела?

И самое интересное ни кто не может объяснить что ж случиться если /mnt не по моунтить?

Да мало ли, что я в /mnt запихал. Это мне решать, нужное там, или нет.

Здесь reports, как и во многом в unix, подразумевает код возврата из функции. Соответственно при nofail код возврата не возвращает ошибку, и загрузка не останавливается. А сообщение об ошибке он естественно выдает. Специально ребутался, чтобы проверить.

А вот этого я не знал. Это меняет дело.

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

То у него не будет не необходимых разделов в fstab без nofail

Почему?

А как мне заставить SysV со товарищи ни в коем случае не загружаться при ошибке монтирования раздела ?

Если ничего не делать, оно так и работает. В RH так было, пока я им пользовался, сейчас в ALT так. Это вот если кто пошерудил в скриптах шаловливыми ручками, может оно и иначе.

Если «всё сломалось», один фиг к ней идти.

man ssh

Я ждал этот ответ. Если man ssh, экран ты не увидишь. ;-) И да, остальное покажет хоть просто mount.

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

Как раз наоборот, главное не навредить.

Если man ssh, экран ты не увидишь. ;-)

А логи увидишь. О том, что всё сломалось, ты уже знаешь от секретарши.

Кроме того что список велик, он заведомо неопределённый.

И самое интересное ни кто не может объяснить что ж случиться если /mnt не по моунтить?

Я объясню.

В двух словах, есть «программисты» и «остальные». Первые понимают, что компьютер — тупая железка, выполняющая команды, не понимая смысла этих команд. Другие привыкли искать смысл, и их мышление стопорится, когда что-то «неправильно». Они склонны одушевлять железку, потому что не понимают принципа её работы. Для них вполне обыденно мышление вида: «systemd что, не понимает, что /mnt не важна для загрузки?» А первые не могут принять тот факт, что кто-то такое может заявить всерьёз.

Ну тут не факт, согласен, не подумав написал. Могут появиться. Но если человек сам правит fstab, то пусть сам и nofail`ы расставляет.

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

Потом присмотрелся - это системд говорит, что не может подмонтировать недостающие разделы из fstab

мдэ/

Разработчики systemd не принимают конструктивной критики? Поддерживающие дистрибутива не принимают конструктивной критики?

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

Ваши же пассажи про «конструктивную критику» в данном случае абсолютно бессмысленные лозунги-речекряки, так как вам прекрасно известн очто это wontfix. Как будто вам платят за то что вы игнорируете указанные вам факты, и знай гоните себе содержимое политруковых методичек.

PS
Кстате не вижу тут фанатиков которые в соседнем треде уверяли просто наперебой что править бинарь никогда не потребуется. Вот пожалуйста - «поправь сам»(С), хыхыхы.

Лучше уж узнать о проблеме сразу, чем огрести «радости» во время работы.

нифига. О проблеме надо узнавать тогда, когда она вылезает. А то, блин, давайте не грузиццо, если блоба не установлено => не будет glxgears работать, ога.

Вот пожалуйста - «поправь сам»(С), хыхыхы.

Править бинарь не надо. Расставляете везде в fstab nofail и получаете старое поведение.

Но если человек сам правит fstab, то пусть сам и nofail`ы расставляет.

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

Править бинарь не надо. Расставляете везде в fstab nofail и получаете старое поведение.

Вообще-то нет - получаю fstab утыканный nofail'ами.

Ну убунта понятно, а сузя nofail`ы или noauto к автоматом подхваченным разделам не подставляет? Сам не пользовал, не знаю.

так как вам прекрасно известн очто это wontfix

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

править бинарь системд.

Ты же в курсе, что есть исходники, да? Исходники — это текстовые файлы оформленные с использованием специального синтаксиса, обычно называемым «язык программирования». Специальной программой (компилятор) эти файлы транслируются в бинарный код, который затем можно непосредственно исполнять на CPU.

О проблеме надо узнавать тогда, когда она вылезает.

Представь ситуацию — сбоит память. Грузиться и узнавать о проблеме по битым файлам или пищать?

Боишься, что такой утыканный fstab весь корень забьёт? Ну да, тут есть чего опасаться.

nofail`ы или noauto к автоматом подхваченным разделам не подставляет?

При чем здесь автоматом? Я о /mnt/DiskD, указанный при установке.

О проблеме надо узнавать тогда, когда она вылезает.

Представь ситуацию — сбоит память. Грузиться и узнавать о проблеме по битым файлам или пищать?

во-первых это не одно и то же. А во-вторых никто ж не догадывается прогонять memtest86 час перед каждой загрузкой :)

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

Если у вас сервер бекапов неделю не работал, и вы об этом узнали только когда что-то навернулось, то вам не станет сильно легче от того, что это не ошибка, а правильное_поведение_системы™

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

Насчет системы мониторинга и необходимости смотреть в ее отчеты (и тем самым узнавать о сбоях вовремя) спору нет.

И куда оно тебя там пустит?!

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

Я это к тому и говорил, что в серьёзном продакшене всё равно без мониторинга никак, и ложащиеся сервера в качестве сигналов не катят.

Разработчики systemd не принимают конструктивной критики?

эти masturbating monkey вообще никакой критики не принимают

во-первых это не одно и то же

Я утрирую, конечно. Но суть та же: система завязана на обещания. Если загрузчик получил управление, он может считать, что железо инициализировано и исправно. Если программа запускается и она запросила цель «локальные фс», то она может считать, что все фс смонтированы и работоспособны. systemd просто следит в usermode, чтобы обещания были выполнены. По-моему, здраво.

никто ж не догадывается прогонять memtest86 час перед каждой загрузкой :)

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

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

Не въехал. 8-()
Вроде, вопрос, как раз, про наоборот. :-) Может, там ещё одного «не» не хватает ?

Я утрирую, конечно. Но суть та же: система завязана на обещания. Если загрузчик получил управление, он может считать, что железо инициализировано и исправно. Если программа запускается и она запросила цель «локальные фс», то она может считать, что все фс смонтированы и работоспособны. systemd просто следит в usermode, чтобы обещания были выполнены. По-моему, здраво.

локальные ФС не являются необходимым условием функционирования системы, в отличие от исправной ОЗУ.

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

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

вообще никакой критики не принимают

Вот смотрел я видео с недавней FOSDEM. Там был доклад Поттеринга о systemd. И там среди вопросозадающих был один кадр, который на ломанном английском зло так спрашивал, а не собирается ли systemd интегрировать в себя linux? Ну так вот, это критика, но она не конструктивная.

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

локальные ФС не являются необходимым условием функционирования системы, в отличие от исправной ОЗУ.

По какому признаку я могу различить значимость /usr/local/ и /mnt/pornostorage/ ?

Ещё раз говорю, что поттеринг и ко воспринимает критику в стиле «сам дурак». Примеры с udev показательны.

локальные ФС не являются необходимым условием функционирования системы, в отличие от исправной ОЗУ.

По какому признаку я могу различить значимость /usr/local/ и /mnt/pornostorage/ ?

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

ни по какому. Просто в какой-то момент загрузки вылезет ошибка.

О том, что не удалось смонтировать /var/ или /usr/ ?

О том, что не удалось смонтировать /var/ или /usr/ ?

к примеру, да. если /usr не удалось смонтировать, то ясен пень дальше работать нет смысла. а если .var не удалось, то вполне можно и дальше попробовать. Хотя вообще достаточно убедиться, что основное дерево смонтировано. то есть /boot /usr /var /

а если .var не удалось, то вполне можно и дальше попробовать

SQL, логи, сайты...

достаточно убедиться, что основное дерево смонтировано. то есть /boot /usr /var /

Зависимости логина от mnt (комментарий)

На другом венике небыло бутлоадера и небыло бут флажка на разделе. Соответственно согласно настроек биоса он взялся за второй жесткий диск... А там то...

достаточно убедиться, что основное дерево смонтировано. то есть /boot /usr /var /

www.linux.org.ru/forum/talks/8946567?cid=8947338

Я ж написал признак - все, что по стандарту в корне находится.

то есть /var /usr и т.д. должно быть примонтировано (ну кроме /opt разве что) А вообще достаточно только / /bin /sbin /boot /usr все. Если это на месте - продолжать мужественно грузиццо.

а если .var не удалось, то вполне можно и дальше попробовать

SQL, логи, сайты...

пофигу. Срать ошибками в консоль, но грузиццо.

А если у меня в этом порно основные программы и данные?

А если у меня в этом порно основные программы и данные?

не беда. главное, чтобы баш запустился. А если не запустится, то dash какой-нить грузить из initramfs.

говно для инициализации до этого в арче

арчепроблемы.

вообще-то это логично, фря так же делает - останавливается на single user mode если не может смонтировать все прописанные в fstab разделы.