-
Lamios
- Posts: 37
- Joined: 2017-12-09 23:26
[Solved] Failed to start raise network interfaces
#1
Post
by Lamios » 2017-12-10 00:06
Hello,
when I start Debian I get an error message saying the following:
Code: Select all
[Failed] Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details.systemctl status networking.service gives me the following:
Code: Select all
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: en
Active: failed (Result: exit-code) since Sat 2017-12-09 12:49:24 GMT; 11h ago
Docs: man:interfaces(5)
Main PID: 2043 (code=exited, status=1/FAILURE)
lines 1-5/5 (END)
ifconfig -a lists the following devices:
— enp0s25
— lo
— vpn0
— wlp2s0
The network had been configured automatically with DHCP during the installation…
I am still able to connect to the internet, also if I sometimes have to reboot, because I get the massage that the connection had been deactivated.
The system (Debian 9 with KDE) is newly installed and the problem existed from beginning. The results from google and forum searches did not fit to my error message (at least as far as I can asses it as a Linux beginner).
Thank you for your help!
Lamios
P.S.: I hope the post is complete for the beginning. I am not sure in the moment, which additional output is going to be needed.
Last edited by Lamios on 2017-12-11 15:48, edited 1 time in total.
-
Lamios
- Posts: 37
- Joined: 2017-12-09 23:26
Re: Failed to start raise network interfaces
#4
Post
by Lamios » 2017-12-10 11:40
Thank you for the very fast reply!
systemctl cat networking.service:
Code: Select all
# /lib/systemd/system/networking.service
[Unit]
Description=Raise network interfaces
Documentation=man:interfaces(5)
DefaultDependencies=no
Wants=network.target
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service syst
Before=network.target shutdown.target network-online.target
Conflicts=shutdown.target
[Install]
WantedBy=multi-user.target
WantedBy=network-online.target
[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --re
ExecStart=/sbin/ifup -a --read-environment
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
RemainAfterExit=true
TimeoutStartSec=5min
lines 1-22/22 (END)
journalctl -u networking.service:
Code: Select all
-- Logs begin at Sun 2017-12-10 12:00:15 GMT, end at Sun 2017-12-10 12:07:46 GMT. --
Dec 10 12:00:16 PP systemd[1]: Starting Raise network interfaces...
Dec 10 12:00:16 PP ifup[334]: /etc/network/if-pre-up.d/firewall_renamed: 2: /etc/netw
Dec 10 12:00:16 PP ifup[334]: run-parts: /etc/network/if-pre-up.d/firewall_renamed ex
Dec 10 12:00:16 PP ifup[334]: ifup: pre-up script failed
Dec 10 12:00:16 PP systemd[1]: networking.service: Main process exited, code=exited,
Dec 10 12:00:16 PP systemd[1]: Failed to start Raise network interfaces.
Dec 10 12:00:16 PP systemd[1]: networking.service: Unit entered failed state.
Dec 10 12:00:16 PP systemd[1]: networking.service: Failed with result 'exit-code'.
Dec 10 12:00:17 PP systemd[1]: Starting Raise network interfaces...
Dec 10 12:00:17 PP ifup[594]: /etc/network/if-pre-up.d/firewall_renamed: 2: /etc/netw
Dec 10 12:00:17 PP ifup[594]: run-parts: /etc/network/if-pre-up.d/firewall_renamed ex
Dec 10 12:00:17 PP ifup[594]: ifup: pre-up script failed
Dec 10 12:00:17 PP systemd[1]: networking.service: Main process exited, code=exited,
Dec 10 12:00:17 PP systemd[1]: Failed to start Raise network interfaces.
Dec 10 12:00:17 PP systemd[1]: networking.service: Unit entered failed state.
Dec 10 12:00:17 PP systemd[1]: networking.service: Failed with result 'exit-code'.
lines 1-17/17 (END)
The loopback network interface contain the following:
I think I probably see the error in ‘journalctl -u networking.service’. I tried to setup a firewall with iptables but than thought it might be easier to use a firewall tool (at least for the beginning). To prevent an interference between the firewall tool and the existing iptables rules I renamed ‘/etc/iptables.firewall.rules’, ‘/etc/network/if-pre-up.d/firewall’ and ‘/etc/network/if-pre-up.d/firewall.save’ with the addition «_renamed». Is it possible that the .save had not been created by me earlier and is now causing the problem? Or is it because all these files are only renamed and not deleted?
-
p.H
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 130 times
Re: Failed to start raise network interfaces
#5
Post
by p.H » 2017-12-10 12:11
The lines you posted are truncated.
Scripts in /etc/network/if-*.d/ are run by run-parts. By default run-parts executes all scripts with names containing only letters, digits, underscore and hyphen [A-Za-z0-9_-]. So /etc/network/if-pre-up.d/firewall is executed, but /etc/network/if-pre-up.d/firewall.save is not because its name contains a dot, not in the allowed character list.
Renaming /etc/network/if-pre-up.d/firewall by adding _renamed does not disable its execution by run-parts because all characters of the suffix are allowed. However if an instruction in the script uses an other file such as /etc/iptables.firewall.rules and you renamed that file without updating the script, then an error may arise. Check in /etc/network/if-pre-up.d/firewall_renamed.
Also note that just renaming the script and not disabling it does not prevent interference with another firewall script.
-
Lamios
- Posts: 37
- Joined: 2017-12-09 23:26
Re: Failed to start raise network interfaces
#7
Post
by Lamios » 2017-12-10 22:05
‘journalctl -u networking.service —no-pager’ geave me the following output:
Code: Select all
-- Logs begin at Sun 2017-12-10 22:41:52 GMT, end at Sun 2017-12-10 22:46:26 GMT. --
Dec 10 22:41:53 PP systemd[1]: Starting Raise network interfaces...
Dec 10 22:41:53 PP ifup[313]: /etc/network/if-pre-up.d/firewall_renamed: 2: /etc/network/if-pre-up.d/firewall_renamed: cannot open /etc/iptables.firewall.rules: No such file
Dec 10 22:41:53 PP ifup[313]: run-parts: /etc/network/if-pre-up.d/firewall_renamed exited with return code 2
Dec 10 22:41:53 PP ifup[313]: ifup: pre-up script failed
Dec 10 22:41:53 PP systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Dec 10 22:41:53 PP systemd[1]: Failed to start Raise network interfaces.
Dec 10 22:41:53 PP systemd[1]: networking.service: Unit entered failed state.
Dec 10 22:41:53 PP systemd[1]: networking.service: Failed with result 'exit-code'.
Dec 10 22:42:18 PP systemd[1]: Starting Raise network interfaces...
Dec 10 22:42:18 PP ifup[1530]: /etc/network/if-pre-up.d/firewall_renamed: 2: /etc/network/if-pre-up.d/firewall_renamed: cannot open /etc/iptables.firewall.rules: No such file
Dec 10 22:42:18 PP ifup[1530]: run-parts: /etc/network/if-pre-up.d/firewall_renamed exited with return code 2
Dec 10 22:42:18 PP systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Dec 10 22:42:18 PP ifup[1530]: ifup: pre-up script failed
Dec 10 22:42:18 PP systemd[1]: Failed to start Raise network interfaces.
Dec 10 22:42:18 PP systemd[1]: networking.service: Unit entered failed state.
Dec 10 22:42:18 PP systemd[1]: networking.service: Failed with result 'exit-code'.
I did not update the script in ‘/etc/network/if-pre-up.d/’, thus that should be the reason. How can I disable the script?
In ‘/etc/network/if-pre-up.d/’ is also file called firewall.save (or now firewall_renamed.save), which I assumed the system created it to run the firewall rules I created. Is that true or is it there for any other reason?
-
p.H
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 130 times
Re: Failed to start raise network interfaces
#8
Post
by p.H » 2017-12-11 12:19
Lamios wrote:How can I disable the script?
(Re)move it, or rename it with a period («.») in the new name so that run-parts ignores it.
Lamios wrote:In ‘/etc/network/if-pre-up.d/’ is also file called firewall.save (or now firewall_renamed.save), which I assumed the system created it to run the firewall rules I created. Is that true or is it there for any other reason?
«The system» does not create such files on its own. Maybe your text editor did as a backup when you modified the original «firewall» file ?
Anyway its filename contains a period, thus is ignored by run-parts and not executed.
-
Lamios
- Posts: 37
- Joined: 2017-12-09 23:26
Докладываю. Пару вечеров и утр этой теме уже посвятил. Обнаружил следующее.
1) если комп не выключать, а погружать в спящий режим, после пробуждения всё замечательно. Решил настроить спящий режим на нажатие кнопки питания. Обнаружил, что в настройках менеджер питания отключен. Запустил, настроил, всё хорошо. Решил попробовать спящий режим. Ещё потыкал настройки питания, обнаружил что из меню выключения компьютера пропал спящий режим. Озадачило 
В менеджере питания есть, в меню нет.
2) решил попробовать спящий режим, он-то остался. Выключается и включается замечательно. Потом пришла мысль, что если так сделать, дети могут рубануть тумблер пилота и что тогда будет? Разведка боем, как говорится. Выключил, подождал немного и включил. Разумеется, он не просыпается, пытается загрузиться и виснет на чеке корневого раздела. Загрузился в режим восстановления, он написал что рэйды испорчены и он будет их ребилдить. В этот момент наступило время ухода на службу, и эксперименты остановлены до вечера.
Очень таки внезапные последствия! Как я понял, эти все режимы очень сырые в systemd и завалить систему в некоторых случаях можно легко и непринуждённо, не прилагая никаких некорректных действий.
Размышляю теперь над тем, хочу ли я восстановить всё до исходного состояния (до инцидента с тумблером пилота же всё работало!) или уже переходить на Devuan, который мне кажется всё более и более интересным в последнее время. Как-то пока останавливают несколько более тухлые пакеты в репозиториях, вспоминается эпоха 6 Debian с его стареньким приятным как мягкие тапочки дизайном и неадекватно тухлые пакеты 
Поставится ли туда, для начала, свежая мазила и облако…
Или ребилдить рэйды и продолжать корячить Debian testing…
On a fresh installation of Debian 9 Stretch on a desktop PC when booting the
...
Failed to start Raise network interfaces
...
error occurres. The (cable) LAN-connection works but the (USB) WiFi is not working properly (detecting the WiFi networks but failing to connect). Previously on the same harware Debian 8 Jessie was installed working fine without any errors.
Seems the issues are connected to the recent predictable network interface names changes. Found users A, B, C, D, and E had similar symptoms. However, they had upgraded Ubuntu systems (without a clean install). Aditionally the proposed solutions are suggesting disabling the assignment of fixed/predictable/unique names. I would prefer to keep the new naming scheme/standard, eventually to find and eliminate the reason why(?) it is not working properly.
Found also users F, and G with the same problem — without solution.
Would be very thankful for any hint. Also, I’m happy to answer your questions if you need more in depth details.
Further you find some detailed system output.
$ sudo systemctl status networking.service
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2017-09-04 17:21:42 IST; 1h 27min ago
Docs: man:interfaces(5)
Process: 534 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Process: 444 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, status=0/SUCCESS)
Main PID: 534 (code=exited, status=1/FAILURE)
Sep 04 17:21:42 XXX ifup[534]: than a configuration issue please read the section on submitting
Sep 04 17:21:42 XXX ifup[534]: bugs on either our web page at www.isc.org or in the README file
Sep 04 17:21:42 XXX ifup[534]: before submitting a bug. These pages explain the proper
Sep 04 17:21:42 XXX ifup[534]: process and the information we find helpful for debugging..
Sep 04 17:21:42 XXX ifup[534]: exiting.
Sep 04 17:21:42 XXX ifup[534]: ifup: failed to bring up eth0
Sep 04 17:21:42 XXX systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Sep 04 17:21:42 XXX systemd[1]: Failed to start Raise network interfaces.
Sep 04 17:21:42 XXX systemd[1]: networking.service: Unit entered failed state.
Sep 04 17:21:42 XXX systemd[1]: networking.service: Failed with result 'exit-code'.
$ cat /etc/network/interfaces.d/setup
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
EDIT2start:
$ sudo ifconfig
[sudo] password for XXX:
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.31 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 xxxx::xxx:xxxx:xxxx:xxxx prefixlen 64 scopeid 0x20<link>
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 765 bytes 523923 (511.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 803 bytes 101736 (99.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 50 bytes 3720 (3.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50 bytes 3720 (3.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlxf4f26d1b7521: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
EDIT2end.
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlxf4f26d1b7521: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
EDITstart:
$ lsusb
...
Bus 001 Device 004: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
...
$ sudo cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
EDITend.
EDIT3start:
$ sudo systemctl status networking.service
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2017-09-05 10:29:16 IST; 44min ago
Docs: man:interfaces(5)
Process: 565 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)
Process: 438 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, status=0/SUCCESS)
Main PID: 565 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/networking.service
Sep 05 10:26:56 sdd9 systemd[1]: Starting Raise network interfaces...
Sep 05 10:26:56 sdd9 ifup[565]: ifup: waiting for lock on /run/network/ifstate.enp3s0
Sep 05 10:29:16 sdd9 systemd[1]: Started Raise network interfaces.
EDIT3end.
We use a lot of virtualization technology in our stack, particularly during development. It just makes life easier. However, there are times when problems arise purely from the fact we’re testing the latest tech.
Most recently, we upgraded all of our VM’s to the latest Linux (Some are Debian, some are Ubuntu). Immediately, we noticed that the new machines cou;dn’t connect to the nwtork… They appeared to be conected properly, they even have a DHCP allocated IP Address, but they just don’t have a connection.
Turns out the network interfaces were not being initialised properly:
Failed to start Raise network interfaces
See 'systemctl status networking.service' for details
After some research, it appears that the issue is related to the Predictable-Network-Interface-Names from systemd/udev.
In order to resolve the issue, we created a new file 10-rename-network.rules in /etc/udev/rules.d/ with a rule in it to attach a specific name to the network interface matching the MAC address of the Network Interface Card (NIC):
sudo vi /etc/udev/rules.d/10-rename-network.rules
and add the following content to it:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ff:ff:ff:ff:ff", NAME="eth0"
where:
eth0 = desired network interface name, used in /etc/network/interfaces or /etc/network/interfaces.d/setup;
ff:ff:ff:ff:ff:ff = hardware mac address of the network device;
Additionally, you’ll need to execute the following to generate a new boot/initrd image:
update-initramfs -u
and, reboot…
sudo shutdown -r now
et violla, you have yourself a connected vm.
I just upgraded a virtual 14.04 server machine to 16.04. After rebooting the VM I see the following error:
[FAILED] Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details
After login I can run the mentioned command and get the following output (image as I’m not able to connect):
The configuration in /etc/network/interfaces looks fine — featuring the manually configured eth0 (not using dhcp here)
What makes me wondering is that ifconfig -a lists
- ens160
- lo
Where I would expect
- eth0
- lo
Trying to up the eth0 device via
sudo ifup -v eth0
outputs:
...
Cannot find device "eth0"
Failed to bring up eth0.
The virtual wired network device itself is still configured in the VM itself as it was before.
ip link shows as well lo and ens160 — where ens160 has the mac address configured in vmware for the single configured virtual network device.
UPDATE
I am able to solve the issue if i change all references of eth0 in /etc/network/interfaces to ens160.
BUT — this feels wrong for me for several reasons:
- I would like to understand this problem
- I would like to stick to eth0 instead of ens160
So please can someone explain this change, which didn’t happen to several other 14.04 machines on the same server which I also upgraded to 16.04.