Slow phase: "Bringing up the loopback interfaces" at bootup

1

Hi Folks,

Is there any way to improve the extended wait that appears at this stage? I often have to wait 10 minutes or so for the boot-up scripts to navigate past this stage. The delay is almost unacceptable.

Regards,

FF

2

Logs would help troubleshoot
Kernel
dmesg
output from terminal : ip a

3

I need to re-raise this issue as it is of concern now.

HyperV v1 Hardware. Profile ID: a8e8670f27b30162480bd356fefcae69ea987d7c

146Mb of log… just in the messages file. It is well and good to say:

Logs would help troubleshoot

dmesg and ip a not relevant in this instance as it is clearly systematic. I have basically been running ipfire since its inception (so no newbies here).

But in what form and how do you suggest that useful information be presented?

4

In the script that brings up the local host loopback interface the command before the “Bringing up the loopback Interface…” message is copying

127.0.0.1 localhost.localdomain localhost

into /etc/hosts then there are only three commands after the message before it moves to the “Setting hostname to” message.

Those commands are:-

ip addr add 127.0.0.1/8 label lo dev lo
ip link set lo up
evaluate_retval

As the loopback interface is a virtual networking interface I am not sure if a problem with your networking hardware would cause any of these commands to take 10 minutes.

Can you confirm that if you run ip addr on its own that you get a lo entry
Mine is

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

That would confirm that it did finally succeed in bringing up the loopback interface.

5

I assume it is the azure initskript but if i remeber correctly this bug should fixed in core156.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5b17fea8e746cb9c71d49af918e6baabbc9b7aa9

1 Like