Комментарии 116
Традиционно через do-release-upgrade?
Традиционно для Ubuntu, но не для Debian.
Есть множество разных вариантов.
Всех с релизом! Долгого uptime и гладкого обновления.
Есть множество разных вариантов.
- Вы на Wheezy, в sources.list прописан 'stable' — apt-get сам сделает что нужно (apt-get dist-upgrade)
- Вы на Wheezy, в sources.list прописан 'wheezy' — нужно сменить 'wheezy' на 'jessie', дальше apt-get сам сделает что нужно (apt-get dist-upgrade)
- Вы на Wheezy, но с какими-нибудь своими настройками apt (apt pinning etc.) — скорее всего, знаете что вам делать.
Всех с релизом! Долгого uptime и гладкого обновления.
uptime
Не то что бы очень долгий, но рекордный для моей машины uptime на Wheezy:
# uptime
06:24:06 up 165 days, 2:42, 2 users, load average: 0.01, 0.06, 0.05
Microsoft приглашает отметить выпуск Jessie на LinuxFest NorthwestКакой-то в этом должен быть подвох…
Почему откатили ядро?
В смысле? 3.16 новее чем 3.2.
c 4.0 не успели (
И не планировали, кстати. 4.0 не является LTS. А вот почему 3.16, а не 3.18 (которая самая свежая LTS) — это любопытно.
Так 3.16 тоже не LTS вроде )
www.kernel.org/category/releases.html
www.kernel.org/category/releases.html
Прошу прощения, не разглядел.
3.2 != 3.20
Теперь systemd официально принят всеми основными дистрибутивами (кроме Gentoo).
Slackware уже не считается основным дистрибутивом?
С добрым утром! А нокия уже не считается основным производителем телефонов )
...(кроме Gentoo и Slackware).
Хотя, судя по DistroWatch, Slackware сильно потеряла популярность в последние годы. Это редкие релизы влияют на статистику, или действительно дистрибутив постепенно уходит в историю?
Хотя, судя по DistroWatch, Slackware сильно потеряла популярность в последние годы. Это редкие релизы влияют на статистику, или действительно дистрибутив постепенно уходит в историю?
Не то, чтобы уходит в историю (слака живее всех живых), но в современном бешеном мире, где всего хочется поскорее, стала сильно сдавать позиции (как и дженту). Тот же деб за последние 3 года на серверах выстрелил на пару с убунтами, они RH-based сравняли со статистической погрешностью.
Это грустно, нигде кроме дженту (и может ещё некоторые source-based) так шустро не появляются новые пакеты, а выбор версии пакета вообще шикарен, учитывая, что это всё делается очень легко и штатными средствами, я считаю, что, как минимум, для личных серверов он шикарен. Вот если в Debian/Ubuntu будут появляться пакеты через неделю после появления на официальных сайтах и возможно будет выбрать версию пакета для установки это будут и правда хорошие дистрибутивы. Ещё не мешало бы аналог eix и eudev без systemd (это религиозное). Ах да, и самое важное-обновление конфигов (etc-update), как это сейчас сделано в дженту, вот уж не знаю как это реализовано в deb-based, если конфиги вообще не меняются-могут быть косяки, которые придётся искать и исправлять руками, если переписываются автоматом-есть вероятность, что заменится что-то важное.
В deb с conffiles всё сделано хорошо. Если конфиг меняли руками на диске, а потом едет новый из пакета — то можно попыриться в diff.
Честно-при обновлении ни разу этого не видел (ни в дэбиане ни в убунте, админю 2 сервера на Ubuntu 14.04 и 14.10, сервер на Gentoo и несколько воркстэйшнов на Debian 0_о), а в дженту постоянно. С чем связано не знаю, поэтому упомянул.
Кстати роллинг релиз был бы кстати, переходы на новые «выпуски» редко проходят бесследно.
Кстати роллинг релиз был бы кстати, переходы на новые «выпуски» редко проходят бесследно.
Может быть с тем, что в дженте постоянно меняют конфиги в релизах (путем добавления пробелов и пустых строк, например), а в дебах конфиг меняются раз в 3 года)?
Я сейчас обновлял тестовую машинку с Визом до Джеса — там конфиг апача такой же вышел.
Я сейчас обновлял тестовую машинку с Визом до Джеса — там конфиг апача такой же вышел.
Gentoo как правило конфиги не правят, а берут из официальных выпусков, sourcebased же. Все исходы выкачиваются с официальных гитов и прочих vcs, затем накладываются патчики (а иногда и не накладываются) и всё это дело собирается. Поэтому если в официальном выпуске изменился конфиг в дженте вы об этом узнаете, а в дебиане они будут тащить depricated пока оно не перестанет запускаться. Видимо так. А пробелы тут не при чём.
А вы попробуйте NixOS.
Русских физиков становится всё меньше.
А насколько полноценно он внедрён?
Что-то я подозреваю в убунте винигрет изи sysvinit, upstart, systemd.
Что-то я подозреваю в убунте винигрет изи sysvinit, upstart, systemd.
Поставил я jessie, что-то они там замудрили с этим systemd в сравнении с тем же арчем. Похоже это будет какая-то переходная ветка с кучей костылей
Аналогично: сам пользуюсь Арчой, а месяц назад решил попробовать Джесси. Посмотрел-посмотрел, плюнул и вернулся обратно. Чего только стоит подвисание загрузки системы на 15 секунд, пока подключается Wi-Fi.
Jessie amd64
CD: 85 штук + kde/lxde/xfce стартовые диски = 88 дисков
DVD: 13 штук
BD: 3 штуки
DLBD: 2 штуки (разумеется)
Откуда цифры «от 61 до 69»?!
CD: 85 штук + kde/lxde/xfce стартовые диски = 88 дисков
DVD: 13 штук
BD: 3 штуки
DLBD: 2 штуки (разумеется)
Откуда цифры «от 61 до 69»?!
А сколько дискеток было у 95 Винды? Истори идет по кругу
95 винду нельзя было установить из интернета.
А кто будет ставить дебиан с 85 CD в реальной жизни — с трудом представляю )
А кто будет ставить дебиан с 85 CD в реальной жизни — с трудом представляю )
например те, у кого в месте установки либо тырнета нет, либо он жутко медленный, либо жутко дорогой.
DVD?
cdimage-search.debian.org позволяет выбрать только минимальные необходимые CD-образы с нужными пакетами + первый диск для установки
Отсюда. Вообще да, цифра странноватая — я как-то не обратил внимания.
61 to 69 binary CDs (depending on the architecture)
Для разных архитектур поддерживается разное число пакетов (какие-то не портированы, какие-то невозможно портировать), соответственно число дисков отличается. Можно умножить число пакетов на число архитектур, чтобы получить примерное представление о размере полного репозитория Debian.
Я знаю откуда разброс. Мне непонятно как так получилось что для архитектуры arm64 их 88 ;)
А, неправильно понял вопрос.
Видимо, новость копировали из новости о релизе Wheezy и число не поправили.
www.debian.org/releases/wheezy/amd64/release-notes/ch-whats-new.en.html#cd — там значится то же число.
Видимо, новость копировали из новости о релизе Wheezy и число не поправили.
www.debian.org/releases/wheezy/amd64/release-notes/ch-whats-new.en.html#cd — там значится то же число.
Зарепортил баг, но по ошибке не на тот пакет: bugs.debian.org/783352
Зашёл сюда за этим постом.
С новым debian'ом.
С новым debian'ом.
как-то странно, ибо еще вчера вечером там висело более 70 release critical багов, что с ними стало?
Назвали, поди, некритикалами :D
Как в M$: «А, ко второму сервиспаку закроем»
Как в M$: «А, ко второму сервиспаку закроем»
Почитайте два последних письма от release.debian.org
Не пойму, что с OpenVZ?
Предыдущий админ мне подарок оставил на сервере, в виде:
debian stable main contrib non-free
Он и обновился. Встрял на udev. Хочет. чтобы ядро сначала обновлено было. А ядро OpenVZ. А в Jessie я что-то не наблюдаю его.
Как быть?
Предыдущий админ мне подарок оставил на сервере, в виде:
debian stable main contrib non-free
Он и обновился. Встрял на udev. Хочет. чтобы ядро сначала обновлено было. А ядро OpenVZ. А в Jessie я что-то не наблюдаю его.
Как быть?
поставить ядро от проксмокса?
Можно немного подробностей?
deb download.proxmox.com/debian jessie pvetest
и ставите pve-kernel-3.10.0-8 оттуда например.
и ставите pve-kernel-3.10.0-8 оттуда например.
А безопасно после этого релиза менять jessie в sources.list на testing (stretch), или лучше подождать?
Лучше подождать (где-то полгода).
Эмм, менять на testing само по себе связано с риском, и не только в debian.
Смотря где вы его используете. Для десктопа testing вполне стабилен хоть сейчас. Можно дождаться разморозки пакетов (1-2 недели).
Да, забыл написать, на десктопе и мелком персональном сервере. Соответственно, не критично 100% аптайм, но хотелось бы чтобы ничего не сломалось (внутри jessie вроде всегда без проблем обновлялось).
Как постоянный юзер тестинга скажу, что не всегда внутри без проблем обновлялось.
Особенно @#$%emd радовал
Особенно @#$%emd радовал
systemd вроде ещё до jessie в дебиане появился, нет? Когда его ввели, думал даже с нуля переустановить, но в итоге и так всё заработало, без новых проблем.
На джесси я помню несколько раз когда поломался gnome-fallback, помню проблемы когда s%@#$md стал обязательным (на визи это еще было не критично насколько помню), помню когда ядро при апдейте требовало для работы переименование переменных (иначе висло).
Несколько раз мерзко отваливались шрифты, и еще несколько мелких проблем, которые уже даже не замечаю.
Несколько раз мерзко отваливались шрифты, и еще несколько мелких проблем, которые уже даже не замечаю.
Зависит от вашего опыта и пакетов. Лично для меня testing работает без особых проблем.
НЛО прилетело и опубликовало эту надпись здесь
Кстати, ура. Наконец полноценная миграция с xbmc на свежий kodi))
«Кроме этого Debian выпущен в виде образов Blu-ray, по два образа для архитектур amd64 и i386 на каждый и два для исходного кода»
cdimage.debian.org/debian-cd/8.0.0/amd64/jigdo-bd
cdimage.debian.org/debian-cd/8.0.0/i386/jigdo-bd
Вроде как не два, а три образа все время было?
А исходников да, два образа.
cdimage.debian.org/debian-cd/8.0.0/amd64/jigdo-bd
cdimage.debian.org/debian-cd/8.0.0/i386/jigdo-bd
Вроде как не два, а три образа все время было?
А исходников да, два образа.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, что ваши претензии будут более уместны к «десктопному» дистрибутиву.
К тому же, я не думаю, что xfce (или любая другая DE) для Debian'а настолько приоритетна, чтобы разрабатывать (или серьезно дорабатывать) собственный DE. В своё время Debian внёс достаточно инноваций, чтобы на нём была основана та же Ubuntu. Теперь они очень осторожны с этим (что меня очень сильно радует). Всё же ИМХО ставить Debian ради DE — это плохая мысль.
P.S. KDE по сравнению с Wheezy очень сильно изменился. Я ещё осенью обновился до Jessie ради KDE.
А вот новый выпуск kubuntu меня не порадовал своей сыроватостью.
К тому же, я не думаю, что xfce (или любая другая DE) для Debian'а настолько приоритетна, чтобы разрабатывать (или серьезно дорабатывать) собственный DE. В своё время Debian внёс достаточно инноваций, чтобы на нём была основана та же Ubuntu. Теперь они очень осторожны с этим (что меня очень сильно радует). Всё же ИМХО ставить Debian ради DE — это плохая мысль.
P.S. KDE по сравнению с Wheezy очень сильно изменился. Я ещё осенью обновился до Jessie ради KDE.
А вот новый выпуск kubuntu меня не порадовал своей сыроватостью.
Из-за сложившейся ситуации со смесью Jessie и Wheezy в инфраструктуре и сопутствующими проблемами с унифицированными конфигурациями puppet, пришлось идти на риск и поэтапно обновлять всю инфраструктуру во время выхода Jessie RC1.
От systemd всё же пришлось отказаться и вернуться к SysV. Лишь несколько примеров. От греха подальше, сильно расширят список на своей шкуре не захотелось.
Обновление Ruby до 2.1. В релизе какой-то snapshot Redmine 3.0-preX. Redmine 3.0 не работает из-за слишком новых зависимостей. В общем, привет RVM.
Так же в релиз не вошли многие важные пакеты — их нужно доставлять из testing/sid с правильным pinning. Рудименты от wheezy могут перестать работать. В частности проблема возникла в связке corosync+pacemaker, где вылезали undefined symbols.
Что-то многое ещё, но сразу не скажу, т.к. прелести от обновления вкушали ещё далеко не одну неделю после.
Есть и приятные моменты:
От systemd всё же пришлось отказаться и вернуться к SysV. Лишь несколько примеров. От греха подальше, сильно расширят список на своей шкуре не захотелось.
- дополнительные конфигурации сервисов из /etc/default не поддерживаются. Самое печальное, что это не всегда можно сразу понять.
- многие дополнительные пакеты не из стандартных репозиториев просто не systemd-aware или лучше бы и не добавляли поддержки в том виде, что сделали
- Percona XtraDB Cluster казалось бы работал, но когда дело дошло до тестирования восстановления узла с нуля на боевой БД systemd так постарался с управлением, что весь кластер ошарашило и заклинило
Обновление Ruby до 2.1. В релизе какой-то snapshot Redmine 3.0-preX. Redmine 3.0 не работает из-за слишком новых зависимостей. В общем, привет RVM.
Так же в релиз не вошли многие важные пакеты — их нужно доставлять из testing/sid с правильным pinning. Рудименты от wheezy могут перестать работать. В частности проблема возникла в связке corosync+pacemaker, где вылезали undefined symbols.
Что-то многое ещё, но сразу не скажу, т.к. прелести от обновления вкушали ещё далеко не одну неделю после.
Есть и приятные моменты:
- обновление Xen c 4.1 до 4.4 с новым эффективным режимом PVH. Честно сказать, PVHVM вдруг почему-то перестал работать непосредственно после последнего обновления ядра перед официальным релизом и было быстрее перейти на более эффективный PVH, чем разбираться
- хоть и был в wheezy-backports, но формально nginx обновился с 1.2.x до 1.6.x
- puppet обновился до крайней версии и не требует дополнительных репозиториев [со сломанными конфигами по умолчанию]
- наконец-то установка полнофункционально работает из коробки как на стационарных, так и на портативных компьютерах (KDE) без потребности доводить до ума конфигурационные файлы вручную, non-free firmware лучше заранее закинуть на флэшечку. Тут systemd показывает себя во всей красе в хорошем смысле. UEFI тоже работает из коробки и поддерживается при установке ещё с Wheezy. Сильно рекомендую поставить систему с нуля, а не обновляться.
- Формально Node.js/npm появился в пакетах в ± пригодном состоянии для использования, но как мёртвому припарки
Обновление GlusterFS с 3.2 до 3.5 очень нетривиально.
Проблема с /etc/default касаются, скорее, не самого systemd, а соответствующих юнитов, написанных мейнтейнерами debian. У меня часто присутствует строчка
EnvironmentFile=-/etc/sysconfig/smth (на centos), если хочется привычного конфига.А можно подробнее: что за проблемы с /etc/default при использовании systemd?
Проблема в том, что формально были сделаны юниты для сервисов в рамках официального перехода на systemd, но по факту они не поддерживают полный набор возможностей старых SysV скриптов, что далеко не всегда очевидно и надо перепроверять все нестандартные фичи самостоятельно.
Пожалуй сразу могу вспомнить проблему с BIND9, открытую ещё в прошлом ноябре. При этом некоторые опции, такие как chroot задаются при запуске.
Пожалуй сразу могу вспомнить проблему с BIND9, открытую ещё в прошлом ноябре. При этом некоторые опции, такие как chroot задаются при запуске.
> Отдельно стоит упомянуть смену системы инициализации по умолчанию: SysVinit изменён на systemd.
БЛЯТЬ
БЛЯТЬ
И, если не ошибаюсь, Jessie имеет статус LTS с поддержкой 5 лет.
Debian 7 “Wheezy” from February 2016 to May 2018
Debian 8 “Jessie“ from May 2018 to April/May 2020
отсюда
Debian 8 “Jessie“ from May 2018 to April/May 2020
отсюда
Что три года, что пять — разница небольшая. Нужна поддержка лет на 10.
Ура!!! Обновлюсь на нетбуке. На серверах пусть пока живет семерка.
НЛО прилетело и опубликовало эту надпись здесь
давным давно уполз с арча по тому что с момента внедрения systemd не обновлял его, а на systemd невозможно по человечески организовать собственный порядок запуска демонов (ну или я дурак но объяснить ему что сеть и ssh надо поднять до монтирования шифрованных томов, и что если скрипт ждет действий от пользователя то его не надо пришибать и уходить в синглмод я не смог), так понимаю скоро нужно будет искать альтернативу и дебиану, какая жаль.
несмотря на то, что systemd — довольно таки УГ, коммент звучит как «я не хочу учиться пусть и хреновому, но новому, которе сейчас стало повсеместным».
Мну не понимает зачем хреновое повсеместным делать? Я понимаю когда это происходит с закрытыми программными продуктами, там производитель диктует свои правила, особенно если он монополист, но почему сообщество поступает как те самые мышки и продолжает жрать кактус? Да и вообще почему мне кто-то диктует что мне использовать, я сам хозяин своего времени хочу изучаю системд хочу трачу его на то чтоб тринити ковырять, захочу скачаю ленни и буду сам все что обновилось собирать руками. Кончатся дистры которые меня устраивают, сделаю свой дистр с баш скриптом вместо инита и пускай мне хоть хоть кто-то попытается объяснить что я не прав.
Дополню, я не верю что системд настолько своеобразен, что его нельзя заменить модульным инструментом, а лучше вообще набором из множества разных (ведь так и было раньше я мог выбрать удобный повер менеджер, системную шину, звуковую систему и тд) я не верю что для организации параллельного запуска 10-20-30 демонов обязательно нужно создать дерево зависимостей которое мелким шрифтом даже на A0 не влезет, я не верю что невозможно создать инструмент инициализации который будет легко и интуитивно конфигуриться как это было при помощи симлинков или текстового файла в арче коткорый, если система легла даже из ефи шелл можно было отредактировать. Я не верю что невозможно не ломать обратную совместимость и дать пользоватюлю хал, oss, QT3 и прочие «устаревшие» инструменты наравне с вновь вышедшими. В конце концов я не понимаю почему программа вдруг стала плохой если вышла новая её версия в которой разработчик по каким-то причинам решил вместо исправления ошибоук написать все с 0 и наплодить гору новых (мифическое окончание поддержки и мифическую-же несовместимость в расчет не берем)… минусите дельше, не могу молчать, насто… доело!
Я тоже не понимаю. Но это теперь данность. Возмущаться надо было раньше.
Почему systemd? А потому, что он единственный кто что-то делал. Все остальные (включая меня) только возмущались.
Вот только замена системы загрузки на параллельную давно назрела, ибо все системы сейчас всё более и более многопроцессорные, а никто ничего лучше не предложил.
> Да и вообще почему мне кто-то диктует что мне использовать
legacy загрузчик же был изучен?
да, никогда не хочется изучать новое, особенно, когда это новое дерьмо.
проблема в том, что это опенсорс, и живёт то, что поддерживают, а не то, что хорошо.
Почему systemd? А потому, что он единственный кто что-то делал. Все остальные (включая меня) только возмущались.
Вот только замена системы загрузки на параллельную давно назрела, ибо все системы сейчас всё более и более многопроцессорные, а никто ничего лучше не предложил.
> Да и вообще почему мне кто-то диктует что мне использовать
legacy загрузчик же был изучен?
да, никогда не хочется изучать новое, особенно, когда это новое дерьмо.
проблема в том, что это опенсорс, и живёт то, что поддерживают, а не то, что хорошо.
проблема в том, что это опенсорс, и живёт то, что поддерживают, а не то, что хорошо.
На мой взгляд, любой софт так живёт. Идеального ПО практически не существует, есть разные степени (сорта)
Исключения есть, но их не так уж много.
НЛО прилетело и опубликовало эту надпись здесь
проблемы не было, точнее она решалась одним единственным символом "&" в тех скриптах запуск которых администратор конкретной системы считал необходимым распараллелить, ну или скриптом-заглушкой, если нужна более гибкая настройка, но это уже пол часа времени потратить нада. И кстати все изучение системв сводится к узнаванию путей к папке с симлинками на конкретном дистре. Еще раз говорю от того что у соседа появился ламборджини ваш логан не стал хуже, не надо его выкидывать на свалку, в спорткар 8 мешков картошки не впихнешь, подручными средствами не отремонтируешь. Дистростроители же решили что разгон с места до 300 за 5 секунд это нужнее чем увезти на 500кг больше груза или починиться подручными средствами. Голосовать и в опен сорсе можно, как только очередной дистростроитель поймет что внедрение системд чреватой потерей половины аудитории в частности мантейнеров он 10 раз подумает как быть.
ну и в догонку решения проблемы я не увидел с системд система из коробки запускается цуко значительно медленее
Вот чего не люблю, так это диванных теоретиков.
Символ "&" не позволяет решить что запускать следующим, он не позволяет корректно отрабатывать результат запуска и еще много чего.
Скрипты-заглушки как раз требуют много усилий. initng как раз пытался решить это.
Символ "&" не позволяет решить что запускать следующим, он не позволяет корректно отрабатывать результат запуска и еще много чего.
Скрипты-заглушки как раз требуют много усилий. initng как раз пытался решить это.
я не теоретик ни разу, я всегда все пробую на практике и если у меня есть положительный опыт решения этой проблемы безо всяких initng я и пишу о нем, был бы опыт с initng я бы и писал что есть инитнг по этому нам системд не нужен. Выставить симофоры баш скриптом и получить коды возврата скриптов это, ещё раз повторюсь, на пол часа история ещё пол часа если хочется сделать конфиг отдельно от скрипта и оформить это в традициях дистра. А там где сервис не кретичен можно не замарачиваясь пустить его фоном и грузиться дальше. Это уже не раз внедрено и это работает там где критично время перезапуска или там где нужно пустить загрузку в нестандартной последовательности. Там где кто попало серваки не роняет мне вообще кглубоко фиолетово сколько по времени оно грузиться будет, а вот убить/добавить нужный демон не перелопачивая гору зависимостей порой очень надо. С ситеммд я пытался разобратся не один час и даже не один день и перестал дружить с ним тех самых пор как он прямым текстом мне написал что игнорит мои настройки и грузит все = все в той последовательности кв корой сам считает нужным. И никогда я не буду дружить с тем софтом который себя считает умнее пользователя а уж тем более админа, вот такая я редиска.
man systemd.unit, там всякие Before, After, Wants, Requires etc. Ничего сложного там нет.Касательно того, что системд нужен/не нужен — он назрел, в том или ином виде. Для многих задач полезны нормальные зависимости (от разных стадий запуска сети network-pre.target, network.target, network-online.target до разных local-fs.target, remote-fs.target и зависимостей от конкретных mount points), удобство логгирования, socket activation (старый добрый inetd и вспоминать не хочется), удобное понижение привилегий (декларативно, не в коде приложения), нормальное ограничение ресурсов через cgroups и тому подобные вещи.
Upstart, извините, говно, если у вас больше одной зависимости, так как использует события, а не состояния. Опять же, у него только зачатки функционала супервизора.
Runit — простая и понятная штука, но только для простых систем и простой структуры зависимостей. Понравилась работа с логами (аналогично тому, что делается в journald, только попроще). Нет зависимостей, от слова совсем.
Всякие supervisord, god, monit и многие другие супервизоры специализированы на наблюдении и перезапуске компонент, но не очень хороши при работе с зависимостями и запуском/остановкой подсистем.
С openrc, initng, launchd, smf и многими другими не работал.
меня не сложность не устраивает а то что то что какая-то паршивая система запуска мнит себя самым главным компонентом системы, да ещё и в наглую ингнорит настройки, разве что не молча это делает, это был бы вообще финиш. Благо оставили возможность вернуться на системв, и кстати вопреки предостережениям с ним DE нормально работают во всяком случае 3 кеды и 4 крыса.
а то что то что какая-то паршивая система запуска мнит себя самым главным компонентом системы, да ещё и в наглую ингнорит настройки, разве что не молча это делает, это был бы вообще финишС этого места поподробнее. Какие настройки игнорировало systemd? Есть ли тикет по этому поводу в багзилле на freedesktop.org?
Работа DE вообще никак не связана с systemd. Она связана с dbus, polkit1, consolekid/logind, udev, но никак не с systemd/upstart/sysv.
в официальной вики написано This probably won't work if selecting one of the desktop environments that require systemd specific features however по тому и пишу что DE-хи пашут нормально.
проблема была на арче когда он перешел на системд, я тогда пол ночи пытался прописать нужные зависимости, всего-то хотел как писал выше чтобы сначала поднималась сеть и ssh а потом уже монтировались шифрованный файловые, второе что я хотел чтобы если не вводишь 2 минуты пароль от шифрованного раздела система не уходила в синглмод, в конечном итоге при загрузке стала выводится надпись (дословно не помню) что мол требутеся тут поднять сеть — проигнорировано, требуется полднять ssh — проигнорировано. Потом я просто сделал все что хотел на дебиане и с тех пор с систем д стараюсь не связываться.
С этого места поподробнее. Какие настройки игнорировало systemd? Есть ли тикет по этому поводу в багзилле на freedesktop.org?
проблема была на арче когда он перешел на системд, я тогда пол ночи пытался прописать нужные зависимости, всего-то хотел как писал выше чтобы сначала поднималась сеть и ssh а потом уже монтировались шифрованный файловые, второе что я хотел чтобы если не вводишь 2 минуты пароль от шифрованного раздела система не уходила в синглмод, в конечном итоге при загрузке стала выводится надпись (дословно не помню) что мол требутеся тут поднять сеть — проигнорировано, требуется полднять ssh — проигнорировано. Потом я просто сделал все что хотел на дебиане и с тех пор с систем д стараюсь не связываться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Состоялся релиз Debian Jessie 8.0