Created attachment 9397 [details]
Output of lspcidrake -v

Please give a link to the attachment that you'll attach to bug 21054.

Source RPM: (none) => networkmanager? drakx-net?
Keywords: (none) => NEEDINFO
CC: (none) => gnome, mageiatools, marja11

Hi.

Again, this doesn't happen every time.

Link.
https://bugs.mageia.org/attachment.cgi?id=9400

(In reply to Stig-Ørjan Smelror from comment #3)
> Hi.
> 
> Again, this doesn't happen every time.
> 

Does it still, occasionally, happen?

If so, please attach the "journalctl -b" logs (as root) from when it just happened

(In reply to Marja van Waes from comment #4)
> (In reply to Stig-Ørjan Smelror from comment #3)
> > Hi.
> > 
> > Again, this doesn't happen every time.
> > 
> 
> Does it still, occasionally, happen?

Does it? 

> 
> If so, please attach the "journalctl -b" logs (as root) from when it just
> happened

(In reply to Marja van Waes from comment #5)
> (In reply to Marja van Waes from comment #4)
> > (In reply to Stig-Ørjan Smelror from comment #3)
> > > Hi.
> > > 
> > > Again, this doesn't happen every time.
> > > 
> > 
> > Does it still, occasionally, happen?
> 
> Does it? 
> 
> > 
> > If so, please attach the "journalctl -b" logs (as root) from when it just
> > happened

Hi.

Sorry, been away on holiday without access to a computer...

The last few boots didn't show this beaviour, but will check a few more times to be sure.

Cheers,
Stig

FYI, for me this happens at every boot, but it's normal: at boot time my connection is not up. For some reason networkmanager doesn't want to connect to the wifi as plasma-nm apparently only wants to save the password to my user profile, so I need to input my user password at every start of Plasma before I have network..

Not necessarily related to Stig's issue, but just to mention that this LSB timeout during boot can just be caused by the network not being up :)

(In reply to Rémi Verschelde from comment #7)
> Not necessarily related to Stig's issue, but just to mention that this LSB
> timeout during boot can just be caused by the network not being up :)

Why does the boot need to have a working network? This shouldn't prevent us from logging in. This happens to me too pretty often. This is painful.

CC: (none) => LpSolit

(In reply to Frédéric Buclin from comment #8)
> 
> Why does the boot need to have a working network? This shouldn't prevent us
> from logging in. This happens to me too pretty often. This is painful.

This issue has history.  The primary reason for having a network at login is if it's needed for authentication during login.  But it's also nice if your hostname is obtained from DHCP as the correct hostname appears on the login screen rather than localhost.localdomain.

But it should not take 1 minute for any network (except maybe dialin) to come up.  Is NM not being started early enough in the boot ?  nmtui activate usually completes in a second or two.

CC: (none) => ftg

This seems to be an issue with WiFi connections. If I disable my WiFi USB key and only use a wired connection instead, startup is *much* faster. systemd-analyze shows that the time spent in network-up.service decreases from 27.9s to 4.8s.

I see "Waiting for hotplugged network to be up" while boot messages are paused with a timer counting for on the order of a minute.  This happens when my cellphone (Blackberry Q10) is connected via USB.  When I unplug the phone, boot proceeds immediately.

CC: (none) => rolfpedersen

I'm on a cabled network on this computer and was wondering why the boot took so long.

Thought it might be a bug or something with LSB, since the network is already up at this point.
Ip-address is acquired from dhcp and hostname is set.

I think one contributor to this kind of issue is something auto-generates /etc/sysconfig/network-scripts/ifcfg-* files for network devices that are detected, and it puts ONBOOT=yes in them.  If you change the ones that shouldn't say yes to no, it usually helps.

Hi.

I'm still seeing this issue, but found this on the CrunchbangPlusPlus Reddit.

"edited systemd's networking.service to exit after 1 second (default was 5 minutes, and there was no need to sit there 5 minutes after the network was set up)"

https://www.reddit.com/r/crunchbangplusplus/comments/70twpn/mirror_login_prompt_across_all_screens/

Don't know if it's related, but it made me think. Haven't tried this solution yet so I can't tell.

Cheers,
Stig

Created attachment 9703 [details]
Log of bug

Having the same bug, I was advised to add my log

CC: (none) => giby_the_kid

Hi.

After having looked at my log and the log from Benjamin, I think I see something that looks like the boot process enables the network twice.

The first comes pretty early on and the next one is from systemd.

Cheers,
Stig

(In reply to Stig-Ørjan Smelror from comment #16)
> Hi.
> 
> After having looked at my log and the log from Benjamin, I think I see
> something that looks like the boot process enables the network twice.
> 
> The first comes pretty early on and the next one is from systemd.
> 
> Cheers,
> Stig

Thanks, Stig,

Assigning to the base system maintainers.

Source RPM: networkmanager? drakx-net? => (none)
Assignee: bugsquad => basesystem

I have no installations with wireless hardware configured, and only a rarely used laptop with wireless hardware. All but one of my systems are configured with static IP. I vastly reduced delay time by doing some modifications to ethernet configuration, though delay as waiting for hotplugged network to be up appeared on vtty1 was significant:

# inxi -S
System:    Host: big41 Kernel: 5.8.13-desktop-1.mga8 x86_64 bits: 64 Console: tty 3 Distro: Mageia 8 mga8
# /etc/sysconfig/network-scripts/ifup-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.0.4
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
#ONBOOT=yes
#METRIC=10
#MII_NOT_SUPPORTED=no
#USERCTL=no
DNS1=192.168.0.1
DNS2=8.8.4.4
DOMAIN=ij.net
#RESOLV_MODS=no
#LINK_DETECTION_DELAY=0
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
└─multi-user.target @12.387s
  └─gssproxy.service @12.358s +27ms
    └─network.target @12.354s
      └─network-up.service @2.977s +9.376s
        └─basic.target @2.931s
          └─mandriva-everytime.service @2.698s +233ms
            └─local-fs.target @2.552s
              └─home.mount @2.509s +41ms
                └─systemd-fsck@dev-disk-by\x2dlabel-home09\x2dcgn.service @2.390s +86ms
                  └─dev-disk-by\x2dlabel-home09\x2dcgn.device @2.379s
# systemd-analyze blame
9.376s network-up.service
1.298s systemd-random-seed.service
1.222s dev-sda32.device
 383ms user@0.service
 309ms network.service
 240ms systemd-udev-trigger.service
 233ms mandriva-everytime.service
 227ms resolvconf.service
 216ms kmod-static-nodes.service
 209ms dev-hugepages.mount
 208ms dev-mqueue.mount
 207ms mdmonitor-takeover.service
 207ms sys-kernel-debug.mount
 205ms sys-kernel-tracing.mount
 204ms fedora-loadmodules.service
 202ms partmon.service
...

Then I booted the current kernel, and it got noticeably worse:
# inxi -S
System:    Host: big41 Kernel: 5.9.3-desktop-1.mga8 x86_64 bits: 64 Console: tty 3 Distro: Mageia 8 mga8
# /etc/sysconfig/network-scripts/ifup-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.0.4
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
#ONBOOT=yes
#METRIC=10
#MII_NOT_SUPPORTED=no
#USERCTL=no
DNS1=192.168.0.1
DNS2=8.8.4.4
DOMAIN=ij.net
#RESOLV_MODS=no
#LINK_DETECTION_DELAY=0
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
└─multi-user.target @26.333s
  └─gssproxy.service @26.305s +26ms
    └─network.target @26.303s
      └─network-up.service @2.654s +23.648s
        └─basic.target @2.578s
          └─mandriva-everytime.service @2.407s +171ms
            └─local-fs.target @2.390s
              └─home.mount @2.310s +75ms
                └─systemd-fsck@dev-disk-by\x2dlabel-home09\x2dcgn.service @2.190s +82ms
                  └─dev-disk-by\x2dlabel-home09\x2dcgn.device @2.136s
# systemd-analyze blame
23.648s network-up.service
 1.315s systemd-random-seed.service
 1.036s dev-sda32.device
  410ms cpupower.service
  410ms acpid.service
  406ms ip6tables.service
  404ms iptables.service
  390ms dbus.service
  387ms user@0.service
  343ms mdmonitor.service
  340ms numlock.service
  340ms partmon.service
  314ms network.service
  255ms systemd-udev-trigger.service
  235ms sys-kernel-tracing.mount
  227ms fedora-loadmodules.service
  227ms systemd-fsck@dev-disk-by\x2dlabel-ulcl12\x2dcgn.service
  224ms systemd-fsck@dev-disk-by\x2dlabel-pub11\x2dcgn.service
  223ms dev-mqueue.mount
  222ms sys-kernel-debug.mount
  220ms dev-hugepages.mount
  219ms kmod-static-nodes.service
  210ms mdmonitor-takeover.service
  201ms modprobe@drm.service
...

CC: (none) => mrmazda

I finally recently upgraded to Mageia 7 (from 5) and can confirm this issue.  Even with wired interfaces I see it, and it spends more time in that waiting mode than it takes for the interface to actually come up.  Something is wrong here.  I even put ONBOOT=no for my unused interface, so unless that's being ignored, I don't think that's the problem.

CC: (none) => luigiwalser
Whiteboard: (none) => MGA7TOO

I have 32 PCs running other distros that do a lot better than this:

# inxi -CMSay
System:
  Host: p5bse Kernel: 5.10.2-desktop-1.mga8 x86_64 bits: 64 compiler: gcc v: 10.2.1
  parameters:<>plymouth.enable=0 noresume mitigations=auto consoleblank=0 speedboot=no
  Console: tty 3 Distro: Mageia 8 mga8
Machine:
  Type: Desktop Mobo: ASUSTeK model: P5B SE v: Rev 1.xx
  serial: <> BIOS: American Megatrends v: 1103 date: 06/04/2009
CPU:
  Info: Dual Core model: Intel Core2 Duo E7500 socket: LGA775 bits: 64
  type: MCP arch: Penryn family: 6 model-id: 17 (23) stepping: A (10)
  microcode: A07 L1 cache: 64 KiB L2 cache: 3 MiB
  flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx bogomips: 11734
  Speed: 1600 MHz min/max: 1596/2926 MHz base/boost: 2933/3800 volts: 1.3 V...
# systemd-analyze critical-chain
...
└─multi-user.target @1min 13.609s

  └─smb.service @1min 12.729s +878ms
    └─nmb.service @1min 10.862s +1.862s

      └─network-online.target @1min 10.846s

        └─network.target @1min 10.844s
          └─network-up.service @47.094s +23.749s
            └─basic.target @47.071s
              └─mandriva-everytime.service @42.017s +5.052s
                └─local-fs.target @42.013s
                  └─isos.mount @39.038s +2.974s
                    └─systemd-fsck@dev-disk-by\x2dlabel-h50isos.service @26.381s +9.957s
                      └─dev-disk-by\x2dlabel-h50isos.device @23.331s
# systemd-analyze blame
31.036s systemd-journal-flush.service
23.749s network-up.service
...

# inxi -SMay
System:
  Host: p5bse Kernel: 5.8.18-300.fc33.x86_64 x86_64 bits: 64 compiler: gcc v: 2.35-14.fc33)
  parameters:<>selinux=0 mitigations=auto consoleblank=0 plymouth.enable=0
  Console: tty 3 Distro: Fedora release 33 (Thirty Three)
Machine:
  Type: Desktop Mobo: ASUSTeK model: P5B SE v: Rev 1.xx
  serial:<> BIOS: American Megatrends v: 1103 date: 06/04/2009
# systemd-analyze critical-chain
...
multi-user.target @43.812s

└─smb.service @43.027s +784ms
  └─nmb.service @41.207s +1.816s
    └─network-online.target @41.197s

      └─NetworkManager-wait-online.service @37.178s +4.018s
        └─NetworkManager.service @32.496s +4.677s

          └─dbus-broker.service @33.004s +3.947s
            └─dbus.socket @32.475s
              └─sysinit.target @32.437s
                └─systemd-update-utmp.service @31.786s +650ms
                  └─auditd.service @17.147s +14.627s
                    └─systemd-tmpfiles-setup.service @14.691s +2.397s
                      └─local-fs.target @14.675s
                        └─usr-local.mount @12.946s +1.723s
                          └─systemd-fsck@dev-disk-by\x2dlabel-h50usrlcl.service @4.097s +8.847s
                            └─local-fs-pre.target @3.997s
                              └─systemd-tmpfiles-setup-dev.service @3.269s +723ms
                                └─kmod-static-nodes.service @2.916s +180ms
                                  └─systemd-journald.socket
                                    └─system.slice
                                      └─-.slice
# systemd-analyze blame | grep -i net
...
 4.677s NetworkManager.service
 4.629s avahi-daemon.service
 4.459s initrd-switch-root.service
 4.376s logrotate.service
 4.135s systemd-logind.service
 4.018s NetworkManager-wait-online.service...

I have 32 PCs running
was supposed to be
I have 32bit PCs running