LINUX.ORG.RU
ФорумTalks

Debian vs systemd

 , ,


0

3

https://lists.debian.org/debian-boot/2015/10/msg00120.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802184

Решил в кои веки поставить Debian Testing в VMWare и посмотреть чего ожидать и не смог запустить образ. За 10 лет ни разу подобного не видел - чтобы даже в single-user mode нельзя было загрузится в виртуальной машине! И это наше будущее?

Чувствую придется уходить на другие дистрибутивы - от «маркетологов» насильно пихающих дырявые и сырые программы в систему, в которой раньше принцип «стабильности» был основным, а не «О! Новая кака! Давайте возьмём её и включим в систему!»...

★★

Последнее исправление: necromant (всего исправлений: 2)

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

sehellion ★★★★★
()

А вообще в systemd в документации есть требование, чтобы /etc/mtab был симлинком на /proc/self/mounts.

Так что это не баг systemd, а оплошность мэнтейнера/девелопера Debian.

Chaser_Andrey ★★★★★
()

О ужас, опять что-то сломали при установке testing, какая трагедия.

Polugnom ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Testing. Ты же понимаешь, что это значит?

Да кто вас, дебианщиков, поймет. То у вас «даже дебиан сид стабильнее твоего поделия», а то «да ты ж понимаешь, это ж тестинг».
В дебианвики написано

Пакеты из Debian Unstable автоматически попадают в testing дистрибутив, когда выполнен список требований:


  • Пакет находился в «unstable» как минимум в течении 2-10 дней (в зависимости от срочности загрузки).
  • Пакет был собран для всех поддерживаемых testing дистрибутивом архитектур.
  • Установка пакета в testing не сделает дистрибутив неустанавливаемым.
  • Пакет не добавляет новые критические ошибки.


Как минимум 2 требования из 4 провалили

MyFreedom ★★★
()

Так вот почему, у меня не заработала установка testing на прошлой неделе. Правда, я вместо того, чтоб ныть на форуме установил stable netinstall и обновил.

Gu4
()
Ответ на: комментарий от Gu4

Правда, я вместо того, чтоб ныть на форуме

он хотя бы поинтересовался почему. А тебя выдаёт принцип: «Не работает? Переустановим винду!».

Deleted
()
Ответ на: комментарий от Chaser_Andrey

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

MyFreedom ★★★
()
Ответ на: комментарий от MyFreedom

Тебе показалось. ТС упоминал о

насильно пихающих дырявые и сырые программы в систему

хотя оказалось, что в systemd как раз и не было проблемы, а был косяк в подготовленном образе, где проигнорили требование к /etc/mtab.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от hateyoufeel

... потому девы читали мануал по диагонали. А ведь требование к /etc/mtab обсуждалось ещё с 2008 года. Только почему-то в той же вики debian писали

Issue #2: Warning: «/etc/mtab is not a symlink or not pointing to /proc/self/mounts»

This issue is only a warning and can be ignored, we have it on TODO

Т.е., всё это время просто забивали на warning.

Почитаем полный текст

[    5.784886] systemd[1]: /etc/mtab is not a symlink or not pointing to /proc/self/mounts. This is not supported anymore. Please make sure to replace this file by a symlink to avoid incorrect or misleading mount(8) output.

Фраза «This is not supported anymore.» о чём-нибудь говорит? На что они надеялись?

Chaser_Andrey ★★★★★
()
Последнее исправление: Chaser_Andrey (всего исправлений: 1)

Решил в кои веки поставить Debian Testing
За 10 лет ни разу подобного не видел
10 лет

Ну дык для дебиановодов 10 лет не срок. Многое может поменяться, когда вдруг решишь апдейтнуться.

Siado ★★★★★
()

Сижу на тестинге с systemd уже минимум год (или сколько там systemd в тестинге живет?) и нихрена не понимаю, как так можно было отрастить такие кривые руки.

Pavval ★★★★★
()

За 10 лет ни разу подобного не видел

Я сразу же в поиске нашёл на багтрекерах случаи. А ты рассказывай дальше про стабильный Debian Testing.

fornlr ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Chaser_Andrey> Testing. Ты же понимаешь, что это значит?

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

Quasar ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Chaser_Andrey> Ok. Причём тут systemd? :)

Дурачком прикидываешься?

Quasar ★★★★★
()

necromant> Чувствую придется уходить на другие дистрибутивы

Devuan

Quasar ★★★★★
()

<ссылка на закрытый за день баг в testing, где английским по черному написано, что и где не так и что делать>

мы все умрем! дебиан скатился!

t184256 ★★★★★
()

дебиан не линукс, и генту не линукс.

ставь линукс, например CRUX, или Slackware, там таких проблем нет.

Spoofing ★★★★★
()

Я тут недавно поставил на ноут Debian (stable), так там systemДНО, кароче поломался suspend по закрытию крышки: после просыпания чёрный экран, лечится только через systemctl restart lightdm.

А раньше всё работало (переставлять систему пришлось по причине сдохшего винта). Починилось так:

* Отрубил к чертям реакцию на закрытие крышки в logind.conf

* Снял галочку в настройках xfce, что закрытием крышки занимается logind

Теперь опять всё работает, заодно починилась мышка: с logind после просыпания ноута внешняя мышка не работала, надо было вытащить шнур и воткнуть заново.

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 1)
Ответ на: комментарий от Spoofing

ставь […] Slackware, там таких проблем нет.

Несколько лет назад ставил слакварь в virtual box. После установки первая загрузка кончилась кернел-паникой из-за невозможности найти корневую ФС.

dexpl ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Фраза «This is not supported anymore.» о чём-нибудь говорит? На что они надеялись?

Ичо? Это настолько страшная ошибка, что даже emergency shell нельзя дать? И это при том, что этот самый mtab нигде внутри systemd не используется, о чём написано в треде по ссылке.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Quasar

А что мешало Поцерингу сразу на /proc/self/mounts идти, а не требовать симлинк?

Судя по треду на жыдхабе, systemd никак этот самый mtab не используется, если не считать автодополнения в zsh-скрептах. Вешается он исключительно just for lulz. Поцтеринг как бэ пытается доминировать и показывает кто тут главный пахан а чьё место под шхонкой.

hateyoufeel ★★★★★
()

поставить Debian Testing

У меня в одном из установщиков не было кучи ФС - ext2/3/4, btrfs, и т.п. - была только xfs. Что ты хочешь то ежедневного/еженедельного снапшота?

leg0las ★★★★★
()
Ответ на: комментарий от Manhunt

Отсутствия критических ошибок?

это snapshot. Критическая ошибка, которая туда проскочила может быть уже выявленной и пофикшеной через час после создания снимка.

leg0las ★★★★★
()
Ответ на: комментарий от Deleted

он хотя бы поинтересовался почему. А тебя выдаёт принцип: «Не работает? Переустановим винду!».

В результате, у меня все заработало через 20 минут, а у ТС-а, судя по всему, не работает до сих пор.

Gu4
()
Ответ на: комментарий от MyFreedom

Да кто вас, дебианщиков, поймет. То у вас «даже дебиан сид стабильнее твоего поделия», а то «да ты ж понимаешь, это ж тестинг».

А это знаменитый дебиановский doublethink. Привыкайте, для фанбоев это норма.

Axon ★★★★★
()
Ответ на: комментарий от Spoofing

Там есть другие проблемы. Например, файлопомойка, начинающаяся с /.

kirk_johnson ★☆
()
Ответ на: комментарий от Chaser_Andrey

Так что это не баг systemd, а оплошность мэнтейнера/девелопера Debian.

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

kirk_johnson ★☆
()
Ответ на: комментарий от leg0las

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

А экспериментал тогда для чего?

Manhunt ★★★★★
()
Ответ на: комментарий от Quasar

Это уже вопросы к разрабам Debian. И всё же я на testing и не такие баги ловил. Чего только стоит небутабельная система после обновления локалей (было где-то год-два назад).

Chaser_Andrey ★★★★★
()

Я прочитал все буквы в https://github.com/systemd/systemd/issues/1495, но ни черта не понял, все только друг на друга клацают и всё, на util-linux, на glibc, на debian и обратно. Объясните кто-нибудь нормально что случилось и почему Лёня Горшков неувиноват.

d_a ★★★★★
()

Мне кажется, что тред не будет полным без мнения Поцтеринга по этому вопросу:

Well, so, the thing is that the file is part of glibc API via setmntent() and _PATH_MOUNTED.

I am not sure I understand why Ubuntu still runs into issues with this all... /etc/mtab is dead since 4+ years, and there are still up-to-date Ubuntu systems around with it as a regular file? Also, we have been shipping a tmpfiles snippet the fixes the symlink since more than a year too in systemd, is Ubuntu not shipping that? I really don't get why this is popping up now on Ubuntu.

Generally, there are tons of ways how you can fuck up your system. For example, remove /usr/lib/libc6.so or so... I am not sure why having a broken /etc/mtab file should be something we should accept...

We need no unlink() + symlink() in code, since we already have it in tmpfiles — and that as mentioned since quite some time. And that's really the right place, since you can only make such a change after / got remounted read-write, hence moving that into earlier boot will not work...

Also, initrds have rescue shells built-in, it's not that this was unfixable...

Anyway, I really don#t understand how this is popping up now. This can only happen if somebody mixes a really old /etc with a very new /usr — or if ubuntu's packaging is borked and doesn't change the file to become a symlink, and also didn't bother with the tmpfiles snippet... But all of that are packaging issues, not sure why this should be an issue upstream?

Where did this issue pop up exactly btw, can you point me to some real-life bug report?

I am fine with making systemd ignore the file all-together, but that really means that util-linux should ignore it too, and glibc as well... Maybe file a bug against gibc to change the _PATH_MOUNTED define?

kirk_johnson ★☆
()
Ответ на: комментарий от hateyoufeel

Похоже, что да.

У systemd были определенные требования, которые никто не скрывал, всё задокументировано.

Вот цитата:

systemd will freeze execution during boot if /etc/mtab exists but is not a symlink to /proc/mounts. Please ensure that /etc/mtab is a proper symlink.

Разрабы Debian долгое время игнорили предупреждение в systemd, надеясь на авось?

этот самый mtab нигде внутри systemd не используется

Это уже другой вопрос. Если он действительно не используется, то послать патч, чтобы исправить документацию. Если всё же система фризится при загрузке, значит таки используется?

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от kirk_johnson

Не выполнил требования к софту - ССЗБ. systemd давно предупреждал об необходимости симлинка на /proc/self/mounts.

Ты пытаешься оправдать ситуацию «а давайте нарушим требования авторов софта к конфигурации, а потом будем обвинять их в том, что софт не работает».

который даже не используется

Если бы он не использовался - система бы не вешалась.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Ты пытаешься оправдать ситуацию «а давайте нарушим требования авторов софта к конфигурации, а потом будем обвинять их в том, что софт не работает».

Нет, я пытаюсь понять, каким идиотом нужно быть, чтобы вешать к черту всю систему, потому что тебе симлинк не нравится. У меня даже с ro корнем без /usr все подниматься умудрялось. Но нет. SystemD не может.

kirk_johnson ★☆
()
Ответ на: комментарий от Quasar

Ничего. Но это его софт, который он пишет. Он не заставляет других его использовать. В Debian systemd был выбран демократическим путем - голосованием.

Но раз выбрали - стоило бы читать документацию, разве не так? Если что-то не нравится в требованиях к запуску systemd - почему их проигнорировали?

Но, как уже отписали, фриз пофиксили. Сделали симлинк. Проблема исчерпана.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

В Debian systemd был выбран демократическим путем - голосованием.

Но раз выбрали - стоило бы читать документацию, разве не так?

Вся соль демократии :D

Manhunt ★★★★★
()
Ответ на: комментарий от kirk_johnson

В коде таки есть проверка.

Убрать эту проверку или нет - это другой вопрос и для этого затеяли обсуждение. Нормальный технический момент. В них тезисы о том, что /etc/mtab может использоваться хелперами и сторонним ПО, при том, что статический /etc/mtab может быть неполным, что может привести к разным неприятностям.

Так вот, пока в документации проекта есть требование и пока есть проверка в коде - игнорировать нельзя. Или подготовить окружение согласно документации, или вносить изменения в проект.

А вот игнорировать требования софта к окружению - это чревато багами. На это и напоролись дебиановцы.

Chaser_Andrey ★★★★★
()
Последнее исправление: Chaser_Andrey (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

Конкретно эта проблема исчерпана.

Я почему-то уверен, что в systemd ещё полно таких сюрпризов.

Это не сюрприз. Предупреждению systemd о /etc/mtab уже много лет.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

В коде таки есть проверка.

Да, я знаю.

Убрать эту проверку или нет - это другой вопрос и для этого затеяли обсуждение. Нормальный технический момент. В них тезисы о том, что /etc/mtab может использоваться хелперами и сторонним ПО, при том, что статический /etc/mtab может быть неполным, что может привести к разным неприятностям.

Поэтому мы повесим систему сразу, намертво и без recovery shell'а. Отличная логика.

А вот игнорировать требования софта к окружению - это чревато багами. На это и напоролись дебиановцы.

Не спорю.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Поэтому мы повесим систему сразу, намертво и без recovery shell'а. Отличная логика.

Вот посмотрим, к чему они договорятся в обсуждении. Лично я за то, чтобы /etc/mtab вообще выкинуть к херам, а старый софт пофиксить.

Chaser_Andrey ★★★★★
()

а ты не знал? обычно, ставят stable и обновляют до testing, так как до самой заморозки диск то рабочий, то сломан

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.