You are not logged in.

#1 2018-04-30 17:36:32

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Long boot time after last update

I always check the news before I update and there has been no new news since my last update on 4/25 so I ran

pacman -Syu

as always.  Now when I boot I get a solid 40 - 55 seconds of flashing cursor screen before my kde login screen, once I enter my password it is only about 2 seconds before I have my desktop environment and everything seems normal and fully functioning.  Does anyone know why the flashing cursor screen is so long after this update, has anyone else had this problem?  I have always had a 15 second boot time with Arch on this laptop.  I removed all the silent boot arguments from "arch.conf" and rebooted to see if there might be some clue in that hidden process, but everything has a green "ok" and then the flashing cursor at the end just flashes for 40 seconds or so before the login screen appears.

Edit appended:
Now that I think of it, I am actually unsure that it did not start after I ran the update on 4/25 which would be the update after the news about the pam.d configuration files, I have been at the house more this week and have not really used my laptop that much.  Before I ran that update I looked through every single one of the configuration files in

/etc/pam.d

, all of them had "pam_unix.so" and none had any other characters before the ".so" i.e. "pam_unix_*.so".  I was unsure about the intervention and wondered if I had interpreted it correctly, however.  There also are no symlinks in the directory

/etc/pam.d

I have checked the logs in

/var/log/pacman.log

and there is a warning during the 4/25 update that says:

/etc/locale.gen installed as /etc/locale.gen.pacnew

and the next line says:

upgraded glibc (2.26-11 -> 2.27-2)

which is the update that was in the news on 4/20, so I am guessing that is related to this issue?  There are no warnings in the update I ran today.  How do I fix this, I clearly did not interpret the intervention correctly?

Last edited by Astral Axiom (2018-04-30 18:31:53)


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#2 2018-04-30 19:06:37

Arclight
Member
Registered: 2018-04-30
Posts: 4

Re: Long boot time after last update

I seem to be having a similar problem, a significant delay at boot that started today. After rebooting a couple of times I've noticed that the delay seems to vary. I know that, in my case at least, it has nothing to do with the pam/glibc updates since I've rebooted after that update with no issues.

When I first noticed that I was stuck at boot, I hit Alt+F2 out of habit to drop me into a workable terminal. But when I did that, my DM (login screen) appeared immediately. I've tried it a couple of times since, and sure enough, dropping into a virtual terminal seems to "resume" the boot sequence every time.

This is the relevant part of journalctl:

Apr 30 20:46:13 arclight systemd[1]: Reached target Graphical Interface.
Apr 30 20:46:13 arclight systemd[1]: Starting TLP system startup/shutdown...
Apr 30 20:46:13 arclight dbus-daemon[463]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
Apr 30 20:46:13 arclight tlp[627]: Applying power save settings...done.
Apr 30 20:46:13 arclight tlp[627]: Setting battery charge thresholds...done.
Apr 30 20:46:13 arclight systemd[1]: Started TLP system startup/shutdown.
Apr 30 20:46:13 arclight systemd[1]: Startup finished in 2.691s (kernel) + 6.823s (userspace) = 9.514s.
--- this is where the delay / flashing cursor begins
Apr 30 20:46:13 arclight NetworkManager[464]: <info>  [1525113973.8891] manager: NetworkManager state is now CONNECTED_GLOBAL
Apr 30 20:46:13 arclight nm-dispatcher[476]: req:3 'connectivity-change': new request (0 scripts)
Apr 30 20:46:13 arclight nm-dispatcher[476]: req:3 'connectivity-change': completed: no scripts
Apr 30 20:46:37 arclight systemd-timesyncd[367]: Synchronized to time server 193.145.15.15:123 (2.arch.pool.ntp.org).
--- this is where i hit Alt-F2
Apr 30 20:46:44 arclight systemd[1]: Started Getty on tty2.
Apr 30 20:46:44 arclight kernel: random: crng init done
Apr 30 20:46:44 arclight sddm[481]: Initializing...
--- that's my DM booting up, after this point everything's normal

Could you give that a go Astral? At the flashing cursor hit Alt-F2 to get into a virtual terminal and see if it moves things along.

Offline

#3 2018-04-30 19:14:24

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,425

Re: Long boot time after last update

That a locale.gen.pacnew is generated is completely normal, it also sounds like you didn't have an issue with the update intervention. However you might want to post /look through your journal of a boot where the error occurs.

Offline

#4 2018-04-30 19:17:04

loqs
Member
Registered: 2014-03-06
Posts: 17,194

Re: Long boot time after last update

Offline

#5 2018-04-30 19:53:25

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

I am reasonably sure that I did not have this issue until I updated today as well.

Arclight wrote:

I seem to be having a similar problem, a significant delay at boot that started today. After rebooting a couple of times I've noticed that the delay seems to vary. I know that, in my case at least, it has nothing to do with the pam/glibc updates since I've rebooted after that update with no issues.

When I first noticed that I was stuck at boot, I hit Alt+F2 out of habit to drop me into a workable terminal. But when I did that, my DM (login screen) appeared immediately. I've tried it a couple of times since, and sure enough, dropping into a virtual terminal seems to "resume" the boot sequence every time.

Yes I get a similar result, when I switch to tty2 I initially get a login prompt in the shell and it remains until I start typing my username and then DM immediately appears.

Arclight wrote:

This is the relevant part of journalctl:

Apr 30 20:46:13 arclight systemd[1]: Reached target Graphical Interface.
Apr 30 20:46:13 arclight systemd[1]: Starting TLP system startup/shutdown...
Apr 30 20:46:13 arclight dbus-daemon[463]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
Apr 30 20:46:13 arclight tlp[627]: Applying power save settings...done.
Apr 30 20:46:13 arclight tlp[627]: Setting battery charge thresholds...done.
Apr 30 20:46:13 arclight systemd[1]: Started TLP system startup/shutdown.
Apr 30 20:46:13 arclight systemd[1]: Startup finished in 2.691s (kernel) + 6.823s (userspace) = 9.514s.
--- this is where the delay / flashing cursor begins
Apr 30 20:46:13 arclight NetworkManager[464]: <info>  [1525113973.8891] manager: NetworkManager state is now CONNECTED_GLOBAL
Apr 30 20:46:13 arclight nm-dispatcher[476]: req:3 'connectivity-change': new request (0 scripts)
Apr 30 20:46:13 arclight nm-dispatcher[476]: req:3 'connectivity-change': completed: no scripts
Apr 30 20:46:37 arclight systemd-timesyncd[367]: Synchronized to time server 193.145.15.15:123 (2.arch.pool.ntp.org).
--- this is where i hit Alt-F2
Apr 30 20:46:44 arclight systemd[1]: Started Getty on tty2.
Apr 30 20:46:44 arclight kernel: random: crng init done
Apr 30 20:46:44 arclight sddm[481]: Initializing...
--- that's my DM booting up, after this point everything's normal

I do not have the same output, but the relevant lines in my

~$ journalctl /usr/bin/dbus-daemon

output seem to be:

Apr 30 15:18:41 dbus-daemon[365]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus
org.freedesktop.ModemManager1.service not found.

Apr 30 15:18:41 dbus-daemon[365]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus
org.freedesktop.ModemManager1.service' requested by ':1.18' (uid=**** pid=*** comm="kded5 [k>

Apr 30 15:18:41 dbus-daemon[365]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus
org.freedesktop.ModemManager1.service not found.

lines 4388-4438/4438 (END)

Seems to be something with activating dbus-org.freedesktop.ModemManager1service via systemd and then it says the unit is not found.  This must be the issue for me, do you have those lines in your output Arclight.


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#6 2018-04-30 19:59:05

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

V1del wrote:

However you might want to post /look through your journal of a boot where the error occurs.

Is my last post what you mean by that?  Looking through the output of

~$ journalctl /usr/bin/dbus-daemon

"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#7 2018-04-30 20:07:46

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

I also am running an IntelCore i3.  Mine is in a Toshiba laptop that I got in 2013.  I wonder if it is processor specific or maybe an intel ucode issue.

Last edited by Astral Axiom (2018-04-30 20:14:51)


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#8 2018-04-30 21:19:47

Arclight
Member
Registered: 2018-04-30
Posts: 4

Re: Long boot time after last update

Astral Axiom wrote:

do you have those lines in your output Arclight.

I don't think so, I don't have modemmanager installed smile

Why are you looking at dbus-daemon logs btw? I would expect most of the relevant logs to come from kernel or systemd (or a specific process causing the hold up). I usually use journalctl -e. That flag starts you off at the bottom of the log, making it easy to find the latest boot log.

Astral Axiom wrote:

I also am running an IntelCore i3.  Mine is in a Toshiba laptop that I got in 2013.  I wonder if it is processor specific or maybe an intel ucode issue.

Intel i5-4200U here, on a Lenovo Yoga 2 Pro (2013).

Good to know there's a bug report open. Will keep an eye on that. Calling up a vt isn't too bad of a solution in the meantime, so long as it's temporary.

Last edited by Arclight (2018-04-30 21:28:54)

Offline

#9 2018-04-30 21:38:57

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

Archlight wrote:

Why are you looking at dbus-daemon logs btw? I would expect most of the relevant logs to come from kernel or systemd (or a specific process causing the hold up). I usually use journalctl -e. That flag starts you off at the bottom of the log, making it easy to find the latest boot log.

because the output of

journalctl

only contains those errors that have to do with the dbus-daemon and I saw the command I ran in the man pages for journalctl.  Thanks I did not know about the -e option that is very useful, I am new to Arch and am only just now approaching an intermediate skill level in Linux in general.

-Doesn't the "session bus" have something to do with the integration of the entire desktop session?

Last edited by Astral Axiom (2018-04-30 22:06:51)


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#10 2018-04-30 22:18:27

loqs
Member
Registered: 2014-03-06
Posts: 17,194

Re: Long boot time after last update

Arclight wrote:

Good to know there's a bug report open. Will keep an eye on that. Calling up a vt isn't too bad of a solution in the meantime, so long as it's temporary.

Can you downgrade the kernel to 4.16.3-1 to test if it is the same issue as the same commits for the 4.16.y series were added in 4.16.4
Unfortunately a bug report on the arch bug tracker for an upstream issue will not lead to it being fixed.

Offline

#11 2018-05-01 00:38:11

v2vm
Member
Registered: 2018-03-03
Posts: 19

Re: Long boot time after last update

I have exactly the same problem, and this is not specific to sddm, I tried lightdm and gdm, all behave the same.

The bug report suggests this is a kernel bug in linux-lts, which is what I've been using. However, this problem also occurs with the stable kernel linux 4.16.5-1.

Offline

#12 2018-05-01 00:55:55

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

v2vm wrote:

I have exactly the same problem, and this is not specific to sddm, I tried lightdm and gdm, all behave the same.

The bug report suggests this is a kernel bug in linux-lts, which is what I've been using. However, this problem also occurs with the stable kernel linux 4.16.5-1.

Your right, I did not see that earlier.  I am running 4.16.5-1 not the linux-lts and I am having the issue.

Last edited by Astral Axiom (2018-05-01 00:58:43)


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#13 2018-05-01 12:07:53

Arclight
Member
Registered: 2018-04-30
Posts: 4

Re: Long boot time after last update

loqs wrote:

Can you downgrade the kernel to 4.16.3-1 to test if it is the same issue as the same commits for the 4.16.y series were added in 4.16.4

Downgrading to linux-4.16.4-1 the issue remains, in this instance a 24s delay

May 01 13:49:13 arclight systemd[1]: Startup finished in [...]
May 01 13:49:37 arclight kernel: random: crng init done

Downgrading to linux-4.16.3-1 the issue is no longer present

May 01 13:53:20 arclight systemd[1]: Startup finished in [...]
May 01 13:53:20 arclight kernel: random: crng init done

Last edited by Arclight (2018-05-01 13:00:21)

Offline

#14 2018-05-01 14:42:58

loqs
Member
Registered: 2014-03-06
Posts: 17,194

Re: Long boot time after last update

The same rng related commits were added to both 4.14.36 and 4.16.4.
Edit:
https://bbs.archlinux.org/viewtopic.php … 1#p1782871 kernel bisection instructions
change in the PKGBUILD

_srcname=linux

to

_srcname=linux-stable

and

source=('git+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#tag=v4.16'
        #'git+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#tag=vX.X.Y'

to

source=(#'git+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#tag=v4.16'
        'git+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#tag=v4.16.4'

In the instructions use `cd linux-git/src/linux-stable` in place of `cd linux-git/src/linux` also substitute 4.16.3 for 4.15 and 4.16.4 for 4.16

Last edited by loqs (2018-05-01 16:10:04)

Offline

#15 2018-05-02 10:57:38

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,425

Re: Long boot time after last update

Another potential stop gap workaround could be to install and enable haveged that way there should be enough entropy available even though this bug is present that it shouldn't really be noticable.

However that is still a workaround, and the proper fix should be done in the kernel.

Last edited by V1del (2018-05-02 10:59:11)

Offline

#16 2018-05-04 17:35:53

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

So for me it is not switching to a tty that triggers the completion of the boot and brings up DM, it is simply pressing and holding the ALT key for about 1 second.  When boot hangs on the flashing cursor screen I just press ALT for about a second and the boot process continues and brings up DM login screen and all is normal, I do not have any freezes during normal operation.  I am upgraded to the 4.16.6-1 kernel.

Last edited by Astral Axiom (2018-05-04 18:07:36)


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#17 2018-05-05 10:28:35

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,425

Re: Long boot time after last update

As it's the random seed that needs entropy you could also just hammer away at any keys you have, the more random the better tongue

Offline

#18 2018-05-05 17:38:44

d_fajardo
Member
Registered: 2017-07-28
Posts: 1,563

Re: Long boot time after last update

Haveged, as V1del suggested, works for me. After the latest kernel update, I disabled it and the long boot returned and so my strategy now is to just keep using it and just test disabling it after every kernel upgrade to see if it's still needed.

Offline

#19 2018-05-05 18:16:50

loqs
Member
Registered: 2014-03-06
Posts: 17,194

Re: Long boot time after last update

The problem with waiting for upstream to fix it is it assumes upstream is aware of the issue to fix it.
Edit:
Fedora is working with upstream on the issue https://bugzilla.redhat.com/show_bug.cgi?id=1572944#c23
the cause is https://git.kernel.org/pub/scm/linux/ke … 8976029f8d in 4.16.4
and https://git.kernel.org/pub/scm/linux/ke … 91240b8f18 in 4.14.36
Edit2:
On an affected kernel can you determine what from userspace is calling the rng?  systemd-analyze between an affected kernel and an unaffected one might highlight it.

Last edited by loqs (2018-05-05 23:23:00)

Offline

#20 2018-05-11 16:12:12

Astral Axiom
Member
Registered: 2018-03-06
Posts: 27

Re: Long boot time after last update

V1del wrote:

As it's the random seed that needs entropy you could also just hammer away at any keys you have, the more random the better tongue

Your right, it is a press and hold any key to continue kind of situation.


"There are times when you get hit upon, try hard but you cannot give
Other times you'd gladly part with what you need to live
Don't waste the breath to save your face when you have done your best
When even more is asked of you, fate will decide the rest."  -Robert Hunter- {Built to Last}

Offline

#21 2018-05-11 16:41:44

Arclight
Member
Registered: 2018-04-30
Posts: 4

Re: Long boot time after last update

Just updated to yesterday's 4.16.8-1, the issue persists.

According to this, Fedora found a fix to the issue and deployed it for testing a few days ago. Guess that means we can expect a fix in Arch at some point? Until then, I find hammering my keys actually makes me boot up faster than prior to having this issue at all, heh.

edit: turns out that page was slightly misleading tongue Thanks Eschwartz for the clarification.

Last edited by Arclight (2018-05-11 18:45:51)

Offline

#22 2018-05-11 18:11:11

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Long boot time after last update

They didn't "fix" it, they reverted the kernel commit because they decided that hanging boot was worse than the security fix it came to prevent.

Meanwhile, their kernel experts are among the group of people looking at the kernel to see if a proper fix can be found.

Last edited by eschwartz (2018-05-11 18:12:07)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#23 2018-09-18 17:23:36

t0ken
Member
Registered: 2012-06-29
Posts: 29

Re: Long boot time after last update

I've run into this issue after upgrading to 4.18.8-1 (oddly enough, I hadn't had the issue until I upgraded to that kernel -- doesn't appear to be an issue on 4.17.6-1, FWIW).

Offline

Board footer

Powered by FluxBB