Один из вариантов:

auto eth0
iface eth0 inet manual
        pre-up ip link set dev "${IFACE}" up
        pre-up dhclient -nw -pf /var/run/dhclient."${IFACE}".pid -lf /var/lib/dhcp/dhclient."${IFACE}".leases "${IFACE}"

        pre-down dhclient -pf /var/run/dhclient."${IFACE}".pid -lf /var/lib/dhcp/dhclient."${IFACE}".leases -r "${IFACE}"
        pre-down ip addr flush dev "${IFACE}"
        pre-down ip link set dev "${IFACE}" down

Кто DHCP-сервер?
Обычно у меня такое, когда дхцп-сервер слоупочит или сломался.

Проблема не в DHCP-сервере, а в кривых скриптах, написанных дебиановскими обезьяномейнтейнерами.

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

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

Дык а если файлуха удаленная?

Дык а если файлуха удаленная?

Значит она будет недоступна, пока сервер не получит адрес от dhcpd. Появится адрес -> примонтируется ФС.

А если /home по NFS?
Зачем мне система без моих файликов?

Кто DHCP-сервер?

ADSL-модем в режиме роутера. Да вроде нормально с ним всё, другие устройства подключаются без всяких проблем (по вайфаю, правда).

mironov_ivan, идею понял, попробую. Такое еще решение нагуглил.

Значит она будет недоступна, пока сервер не получит адрес от dhcpd. Появится адрес -> примонтируется ФС.

А если там корень?

ИМХО, я бы всё-таки попытался разобраться в проблеме, у меня такого нет, может патчкорд заменить, другую сетевуху попробовать, почитать логи. Может у тебя проблемы с пк/сетью/роутер. Тебе дебиан намекает, а ты игноришь послание.

ADSL-модем в режиме роутера.

Пропишите статический ip адрес и не мучайтесь.

А сетевой провод случаем не мятый ? По нему ногами не ходили ?

ИМХО, я бы всё-таки попытался разобраться в проблеме, у меня такого нет, может патчкорд заменить, другую сетевуху попробовать

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

ifconfig eth0 down
dhclient -r
ifconfig eth0 up
dhclient eth0

То коннектится максимум секунд за 5, задержек особых не вижу. Хз, подумаю, конечно.

Смотрите dmesg.

А если там корень?

А если уборщица ведро воды в сервак вылила?

Очевидно, что это отдельный специальный случай.

Очевидно, что это отдельный специальный случай.

Для тонких клиентов - нет. А если я правильно понимаю политику дебиана - они стремятся делать универсальный инструмент, поэтому вот так вот.
К тому же, не вижу проблемы поправить его (скрипт) самостоятельно, если тебе какой-либо фукнционал не нужен.

Для тонких клиентов - нет.

В случае тонких клиентов не дойдёт даже до загрузки ядра, так как PXE тоже отвалится.

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

У меня есть более правдоподобная версия: сначала «не подумали», а теперь «обратная совместимость!!1» =).

Проблема не в DHCP-сервере, а в кривых скриптах, написанных дебиановскими обезьяномейнтейнерами.

Советую сначала эти скрипты прочитать, чтобы не нести такую чушь.

Процесс загрузки не зависит от наличия сети кроме, естественно, тех скриптов, что его явным образом требуют (Required-Start: $network). NFS по умолчанию монтируются асинхронно (смотрите /etc/init.d/mountnfs.sh). Я могу хоть с выключенным DHCP-сервером загружаться, разницы нет.

У автора, возможно, почему-то отключена параллельная загрузка.

Советую сначала эти скрипты прочитать, чтобы не нести такую чушь.

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

Процесс загрузки не зависит от наличия сети кроме, естественно, тех скриптов, что его явным образом требуют (Required-Start: $network).

Вот в этом и проблема: у нас есть $network и всё. А если у меня несколько десятков интерфейсов, настраиваемых каждый своим способом, причём интерфейс с автонастройкой по dhcp стоит первым? Правильно, все будут ждать, пока этот интерфейс настроится или dhclient отвалится по таймауту. Никакой асинхронности и системы зависимостей внутри $network нет.

NFS по умолчанию монтируются асинхронно (смотрите /etc/init.d/mountnfs.sh). Я могу хоть с выключенным DHCP-сервером загружаться, разницы нет.

Ну хоть что-то они починили =).

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

Если судить по сообщениям авторов тем, то ничто ни у кого не работает :).

Всё же несколько лет назад не было параллельной загрузки, как сейчас. Из-за неё многое поменялось.

Вот в этом и проблема: у нас есть $network и всё.

А как система при запуске сети должна узнать, какой именно интерфейс нужен сетевой службе, запускаемой позже? Как отследить зависимости?

Вот и выходит, что проще дождаться инициализации всех интерфейсов, нежели распутать этот узел.

Лично у меня на десктопе с KDE (и, как следствие, kdm) вообще так:

$ grep \$network /etc/init.d/*
$

Даже если установлены службы, зависящие от $network, они не входят в цепочку зависимостей большинства остальных, включая *dm, поэтому никакой видимой задержки запуска быть не должно.

А как система при запуске сети должна узнать, какой именно интерфейс нужен сетевой службе, запускаемой позже? Как отследить зависимости?

Из конфига сетевой службы в /etc/default/, например.

Из конфига сетевой службы в /etc/default/, например.

Далеко не все сетевые службы вообще имеют конфигурацию в /etc/default, не говоря уже о том, что необходимость дублировать часть настроек стандартного конфигурационного файла где-то ещё вряд ли понравится администраторам :).

Можно, конечно, придумать систему утилит, поставляемых с каждым пакетом сетевой службы, которые запускаются автоматически при редактировании конфигурации и обновляют некую базу вида <служба, список интерфейсов>, которая потом будет использоваться при построении графа зависимостей, но это выглядит неоправданным усложнением, да ещё и добавит работы сопровождающим пакетов, и так ей не обделённым. И всё это, чтобы всего лишь увеличить скорость загрузки.

Так что приходится смириться и грустно радоваться, что со временем иголки становятся не такими колючими :).

Автор темы, тем временем, был немного занят, потому прописал статический айпишник в /etc/network/interface (настройки матешного network почему-то работают как-то через раз), в результате чего всё стало грузиться быстро... но не с выключенным модемом. С ним мы все равно останавливаемся подумать, почему у нас нет сети.