+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[SOLVED] Debian 13 LXC network.service не запустился, Proxmox Виртуальная Среда

devilkin

Guest

08.08.2025 11:09:00

Пытаюсь понять, почему на более старом Debian LXC (сейчас версия 12, но было как минимум 2 крупных обновления) служба network.service после загрузки возвращается со статусом failed.

Код:
Aug 08 10:34:24 metricsbox systemd[1]: Starting networking.service - Raise network interfaces...
Aug 08 10:34:24 metricsbox dhclient[106]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:24 metricsbox ifup[106]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:24 metricsbox dhclient[106]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:24 metricsbox ifup[106]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:24 metricsbox dhclient[106]: All rights reserved.
Aug 08 10:34:24 metricsbox ifup[106]: All rights reserved.
Aug 08 10:34:24 metricsbox dhclient[106]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:24 metricsbox ifup[106]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:24 metricsbox dhclient[106]:
Aug 08 10:34:24 metricsbox dhclient[106]: Listening on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Listening on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Sending on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Sending on Socket/fallback
Aug 08 10:34:24 metricsbox ifup[106]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Aug 08 10:34:24 metricsbox dhclient[106]: Sending on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox dhclient[106]: Sending on Socket/fallback
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPOFFER of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPOFFER of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPREQUEST for 192.168.34.47 on eth0 to 255.255.255.255 port 67
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPREQUEST for 192.168.34.47 on eth0 to 255.255.255.255 port 67
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPACK of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPACK of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox dhclient[106]: bound to 192.168.34.47 -- renewal in 2947 seconds.
Aug 08 10:34:24 metricsbox ifup[106]: bound to 192.168.34.47 -- renewal in 2947 seconds.
Aug 08 10:34:25 metricsbox dhclient[156]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:25 metricsbox ifup[156]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:25 metricsbox ifup[156]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:25 metricsbox ifup[156]: All rights reserved.
Aug 08 10:34:25 metricsbox ifup[156]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:25 metricsbox dhclient[156]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:25 metricsbox dhclient[156]: All rights reserved.
Aug 08 10:34:25 metricsbox dhclient[156]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: Can't bind to dhcp address: Cannot assign requested address
Aug 08 10:34:25 metricsbox ifup[156]: Can't bind to dhcp address: Cannot assign requested address
Aug 08 10:34:25 metricsbox ifup[156]: Пожалуйста, убедитесь, что другой DHCP-сервер не работает и в /etc/inetd.conf нет записей для dhcp или bootp.
Aug 08 10:34:25 metricsbox ifup[156]: Также проверьте, что у вас не запущен HP JetAdmin, который включает bootp-сервер.
Aug 08 10:34:25 metricsbox ifup[156]: Если вы считаете, что получили это сообщение из-за бага, а не из-за ошибки конфигурации, пожалуйста, прочитайте раздел о подаче баг-репортов на нашем сайте www.isc.org или в файле README перед отправкой.
Aug 08 10:34:25 metricsbox ifup[156]: Эти страницы объясняют правильный процесс и информацию, полезную для отладки.
Aug 08 10:34:25 metricsbox ifup[156]: Завершение работы.
Aug 08 10:34:25 metricsbox dhclient[156]: Пожалуйста, убедитесь, что другой DHCP-сервер не работает и в /etc/inetd.conf нет записей для dhcp или bootp.
Aug 08 10:34:25 metricsbox dhclient[156]: Также проверьте, что у вас не запущен HP JetAdmin, который включает bootp-сервер.
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: Если вы считаете, что получили это сообщение из-за бага, а не из-за ошибки конфигурации, пожалуйста, прочитайте раздел о подаче баг-репортов на нашем сайте www.isc.org или в файле README перед отправкой.
Aug 08 10:34:25 metricsbox dhclient[156]: Эти страницы объясняют правильный процесс и информацию, полезную для отладки.
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: Завершение работы.
Aug 08 10:34:25 metricsbox ifup[83]: ifup: не удалось поднять eth0
Aug 08 10:34:25 metricsbox systemd[1]: networking.service: основной процесс завершился с кодом выхода 1/FAILURE
Aug 08 10:34:25 metricsbox systemd[1]: networking.service: завершился с ошибкой 'exit-code'.
Aug 08 10:34:25 metricsbox systemd[1]: Не удалось запустить networking.service - поднятие сетевых интерфейсов.

Настроено использование dhcp для ipv4 и dhcp для ipv6 (обе службы доступны в моей сети). Перезапуск networking.service решает проблему, но после перезагрузки всё повторяется. Новый Debian 12 LXC такой проблемы не имеет. Она появляется после обновления до 13. Очень интересно, что именно вызывает эту проблему.

Daniel-San

Guest

23.08.2025 00:47:00

Обход с dhcpcd-base кажется только наполовину решением. Только что попробовал, и моё IPv6-маршрутизация к контейнеру Debian 13 LXC так и не исправилась. Внутри самого LXC IPv6 работает нормально, но когда пытаешься получить доступ к сервису на этом LXC через IPv6 — не выходит. Мой PVE настроен как маршрутизатор. С контейнерами Debian 12 LXC маршрутизация до них всё ещё работает без сбоев.

Правка: маршрутизация не сломалась из-за перехода на dhcpcd-base. Выяснил, что проблема была в настройках Wireguard VPN. Так что можете забыть моё предыдущее сообщение.

Grimwiz

Guest

11.09.2025 15:16:00

[решено] Коротко: включил файрвол дата-центра и открыл оттуда доступ. Я пробовал переключиться на dhcpd-base и удалить isc-dhcp-client, но единственное, что случилось — временно назначился адрес из 168-сети, пока DHCP в итоге не сработал через пару минут. Убедился, что в конфигурации LXC нет включённых правил файрвола, но это не изменило ситуацию. Добавил правила для разрешения DHCP трафика в файрволе дата-центра, но при этом сам файрвол не включал — результата ноль. Перебрав все варианты и проследив трафик, чтобы убедиться, что LXC-сеть и интерфейс хоста Proxmox не видят DHCP-сообщения (хотя на других устройствах в сети всё отлично работало), включил файрвол дата-центра полностью, разрешив весь трафик (чтобы воспроизвести поведение, при котором файрвол Proxmox не является частью моего уровня безопасности), и сразу же DHCP ответы пошли как надо.

Daniel-San

Guest

11.09.2025 15:59:00

Правила брандмауэра DHCPv6 — это лишь половина дела. Нужно ещё добавить правила для IPv6 ICMP. Тогда включение брандмауэра в дата-центре с блокировкой по умолчанию вообще не станет проблемой. IPv6 DHCP по-прежнему зависит от объявлений маршрутизатора.

azuriye

Guest

12.09.2025 23:29:00

По какой-то причине LXCs, которые я обновил с 12 до 13, отлично работают с isc-dhcp-client, но когда я скачал чистый образ Debian 13 для своего контейнера, он не запускался, пока я не попробовал исправление от fabian. ИЗМЕНЕНИЕ: Похоже, что через день LXCs, обновлённые с 12 до 13, тоже начали сталкиваться с такими же проблемами.

Unspec

Guest

13.09.2025 23:00:00

У меня команда systemctl status networking показывает, что сеть не смогла запуститься при старте системы, но если потом выполнить systemctl start networking, сеть запускается без проблем. "Грубый" способ для тех, кто не хочет заморачиваться с контейнерами, — использовать в cron @reboot sleep 5 && systemctl start networking.

azuriye Guest	#7 0 13.09.2025 23:15:00 Разве isc-dhcp-client не устарел? Думаю, лучше перейти на dhcpcd-base, если только это не нарушит настройки у кого-то ещё.

Unspec

Guest

13.09.2025 23:17:00

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

Yetanprox

Guest

07.10.2025 01:42:00

Поскольку в Debian 13+ по умолчанию используется systemd-networkd, а Proxmox уже поддерживает такую конфигурацию в других дистрибутивах, логично добавить такую поддержку и для Debian 13+. Довольно простой патч к ${perl5_shared}/PVE/LXC/Setup/Debian.pm в сочетании с исправлением старой проблемы с отсутствием поддержки IPv6 RA при установках DHCPv6 в ${perl5_shared}/PVE/LXC/Setup/Base.pm работает у меня:

Diff:
diff -u usr/share/perl5/PVE/LXC/Setup/Base.pm /usr/share/perl5/PVE/LXC/Setup/Base.pm
--- usr/share/perl5/PVE/LXC/Setup/Base.pm 2025-09-15 19:24:30.000000000 +0200
+++ /usr/share/perl5/PVE/LXC/Setup/Base.pm 2025-10-06 13:15:29.889124763 +0200
@@ -296,6 +296,7 @@
if (defined(my $ip = $d->{ip6})) {
if ($ip eq 'dhcp') {
$dhcp |= $DHCP6;
+ $accept_ra = 'true';
} elsif ($ip eq 'auto') {
$accept_ra = 'true';
} elsif ($ip ne 'manual') {
diff -u usr/share/perl5/PVE/LXC/Setup/Debian.pm /usr/share/perl5/PVE/LXC/Setup/Debian.pm
--- usr/share/perl5/PVE/LXC/Setup/Debian.pm 2025-09-15 19:24:30.000000000 +0200
+++ /usr/share/perl5/PVE/LXC/Setup/Debian.pm 2025-10-06 18:28:35.126916032 +0200
@@ -9,6 +9,7 @@
use PVE::RESTEnvironment qw(log_warn);

use File::Path;
+use POSIX;

use PVE::LXC::Setup::Base;

@@ -119,7 +120,9 @@
$self->setup_container_getty_service($conf);

my $version = $self->{version};
- if (at_least($version, 12, 0)) {
+ # if (at_least($version, 12, 0)) {
+ # часть экспериментальной поддержки systemd-networkd для Debian Trixie
+ if (POSIX::floor($version) == 12) {
# это влияет только на первый запуск (если нет /etc/machine-id).
$self->setup_systemd_preset({
# systemd-networkd включается по умолчанию, отключаем его, в debian используется ifupdown
@@ -234,6 +237,13 @@
# ВНИМАНИЕ: этот код повторно используется в Alpine Linux, имейте это в виду при изменениях.
sub setup_network {
my ($self, $conf) = @_;
+ my ($os, $version) = ($conf->{ostype}, $self->{version});

+ # экспериментальная поддержка systemd-networkd для Debian Trixie и новее
+ if ($os eq "debian" && at_least($version, 13, 0)) {
+ $self->setup_systemd_networkd($conf);
+ return;
+ }

my $networks = {};
foreach my $k (keys %$conf) {
@@ -300,7 +310,8 @@
my $done_v4_hash = {};
my $done_v6_hash = {};

- my ($os, $version) = ($conf->{ostype}, $self->{version});
+ # определено выше для экспериментальной поддержки systemd-networkd для Debian Trixie
+ # my ($os, $version) = ($conf->{ostype}, $self->{version});
my $print_section = sub {
return if !$section;

Такой патч позволяет сразу после установки Debian 13+ запускать контейнеры без необходимости ручных вмешательств. Для же контейнеров, обновлённых командой dist-upgrade с более ранних версий Debian (которые используют ifupdown), потребуется кое-какое ручное вмешательство для перехода на systemd-networkd:
# systemctl disable --now networking
# systemctl enable --now systemd-networkd

Перезагрузите контейнер и проверьте, всё ли работает как надо. Я использую эту патченную версию и пока проблем не встречал.

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

Также видел обсуждения, стоит ли использовать systemd-resolved вместо прямого редактирования /etc/resolv.conf. Поскольку это не входит в стандартную установку Debian 13+, я пока не добавлял такую поддержку. Если её внедрять, то изменения по DNS из файла (Base.pm::set_dns()) стоит переносить в соответствующий /etc/systemd/network/interface.network, используя параметры DNS=... и DOMAINS=... в секции [Network].

@fabian, это примерно то, что планируется для будущих релизов Proxmox? Или предполагается оставить ifupdown по умолчанию в Debian после версии 12? Учитывая, что команда Debian перешла на systemd-networkd, логично следовать за этим, и я именно так и сделал.

fabian Guest	#10 0 08.10.2025 09:02:00 Что-то в этом роде — один из вариантов, но мы бы предпочли, если получится, более аккуратный сценарий миграции.

klinebau

Guest

#11

11.10.2025 16:51:00

@Yetanprox Мне нравятся эти изменения, и они у меня работают лучше, однако я заметил, что networking.service всё ещё запущен. Кажется, было бы чище, если бы его можно было как-то отключить в скрипте. Я бы внес это изменение, но не могу понять, как это сделать.

Yetanprox

Guest

#12

11.10.2025 17:37:00

Вы отключили networking.service (systemctl disable --now networking.service)? Если он всё ещё работает после этого, значит что-то другое его запускает. На моих системах (контейнеры Debian, обновлённые с 12/bookworm) он не работает и ни разу не запускается.

klinebau

Guest

#13

12.10.2025 06:49:00

Я, конечно, могу его отключить, и оно останется выключенным. Я имел в виду, что было бы здорово, если бы сетевая служба автоматически отключалась, когда я запускаю новый LXC. У меня так: служба работает сразу после создания LXC, и мне приходится её останавливать и отключать вручную. После этого всё нормально, даже после перезагрузок.

Yetanprox Guest	#14 0 15.10.2025 21:25:00 Это тоже можно сделать через template_fixup() и/или setup_init(). Могу добавить это в патч, но пока не сделал — больше как эксперимент, чтобы посмотреть реакцию. Посмотрю, как добавить и потом опубликую где-нибудь. // прошло время Это изменение достигает цели — не запускать networking.service. Поскольку template_fixup() вроде бы запускается только при восстановлении контейнера (вызывается из PVE::API2::LXC:560 при восстановлении), тот же шаг дублируется в setup_init(). В финальной версии достаточно будет одного из них, и код template_fixup() можно будет убрать, но я добавил его сюда, чтобы получить комментарии по каноничному способу сделать это. @fabian, вызов setup_systemd_preset() добавляет отключение networking.service в /etc/systemd/system-preset/00-pve.preset, но, похоже, это не действует — networking.service остаётся активным после первого запуска, поэтому нужен дополнительный ручной шаг для удаления ссылок. Diff: diff -u usr/share/perl5/PVE/LXC/Setup/Debian.pm /usr/share/perl5/PVE/LXC/Setup/Debian.pm --- usr/share/perl5/PVE/LXC/Setup/Debian.pm 2025-09-15 18:32:38.000000000 +0200 +++ /usr/share/perl5/PVE/LXC/Setup/Debian.pm 2025-10-16 11:00:17.019879722 +0200 @@ -9,6 +9,7 @@ use PVE::RESTEnvironment qw(log_warn); use File::Path; +use POSIX; use PVE::LXC::Setup::Base; @@ -34,6 +35,7 @@ 'bookworm/sid' => 12, 'trixie/sid' => 13, 'forky/sid' => 14, + 'duke/sid' => 15, 'kali-rolling' => 12, }; $version = $version_map->{$version} if exists($version_map->{$version}); @@ -110,21 +112,46 @@ $self->ct_file_set_contents($filename, $inittab); } +sub template_fixup { + my ($self, $conf) = @_; + my ($os, $version) = ($conf->{ostype}, $self->{version}); + + # экспериментальная поддержка systemd-networkd для Debian Trixie и новее + if ($os eq "debian" && at_least($version, 13, 0)) { + # отключаем networking.service + $self->ct_unlink('/etc/systemd/system/multi-user.target.wants/networking.service'); + $self->ct_unlink('/etc/systemd/system/network-online.target.wants/networking.service'); + } +} + sub setup_init { my ($self, $conf) = @_; + my ($os, $version) = ($conf->{ostype}, $self->{version}); my $systemd = $self->ct_readlink('/sbin/init'); if (defined($systemd) && $systemd =~ m@/systemd$@) { $self->setup_container_getty_service($conf); - my $version = $self->{version}; - if (at_least($version, 12, 0)) { + # if (at_least($version, 12, 0)) { + # часть экспериментальной поддержки systemd-networkd для Debian Trixie + if (POSIX::floor($version) == 12) { # это действует только при первом запуске (если нет /etc/machine-id). $self->setup_systemd_preset({ # systemd-networkd включается по умолчанию, отключаем, debian использует ifupdown 'systemd-networkd.service' => 0, }); } + if ($os eq "debian" && at_least($version, 13, 0)) { + $self->setup_systemd_preset({ + # отключаем networking.service, используем systemd-networkd + 'networking.service' => 0, + }); + # ...и вручную удаляем ссылки networking.service, так как вышеописанное не всегда срабатывает + # и шаг template_fixup срабатывает только при восстановлении контейнера, а не при создании нового. + $self->ct_unlink('/etc/systemd/system/multi-user.target.wants/networking.service'); + $self->ct_unlink('/etc/systemd/system/network-online.target.wants/networking.service'); + } } setup_inittab($self, $conf); @@ -233,6 +260,13 @@ # NOTE: this is re-used by Alpine Linux, please have that in mind when changing things. sub setup_network { my ($self, $conf) = @_; + my ($os, $version) = ($conf->{ostype}, $self->{version}); + + # экспериментальная поддержка systemd-networkd для Debian Trixie и новее + if ($os eq "debian" && at_least($version, 13, 0)) { + $self->setup_systemd_networkd($conf); + return; + } my $networks = {}; foreach my $k (keys %$conf) { @@ -299,7 +333,8 @@ my $done_v4_hash = {}; my $done_v6_hash = {}; - my ($os, $version) = ($conf->{ostype}, $self->{version}); + # переменные уже определены ранее для экспериментальной поддержки systemd-networkd в Debian Trixie + # my ($os, $version) = ($conf->{ostype}, $self->{version}); my $print_section = sub { return if !$section;

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры