You are not logged in.
Where is it explicitly stated that you should replace udev with systemd in mkinitcpio.conf?
systemd-205 update advices:
The "timestamp" hook for mkinitcpio no longer exists. If you used this hook, you must remove it from /etc/mkinitcpio.conf. A "systemd" hook has been added which provides this functionality, and more.
I did that on my system (which booted fine w/o udev hook) and replacing timestamp by systemd broke boot. Replacing systemd hook by udev (as suggested in this thread - thanks!) fixed it.
Offline
It is not suggested that you use the systemd hook. It is perfectly fine to use udev etc.
If you have a simple configuration, you may use the systemd hook, if you wish.
If you have a more complex setup, the systemd hook will not work.
The only thing you must change is that you must remove the timestamp hook if you used it. Since this is inessential, you can remove this without replacing it with anything. All I did was remove this hook. That's all.
In summary:
1. Simple setup?
- 2 options:
(1) replace relevant hooks with systemd;
(2) do nothing except removing timestamp (if applicable).
2. Complex setup?
- 1 option:
(1) do nothing except removing timestamp (if applicable).
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Just upgraded to systemd-208. The problem persists.
PS. This is happening with both udev and systemd HOOKS.
-- Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Offline
Are there any updates for this problem? I'm having the same issue.
graphical.target @16.984s
└─multi-user.target @16.984s
└─systemd-logind.service @16.906s +77ms
└─basic.target @16.898s
└─timers.target @16.890s
└─systemd-tmpfiles-clean.timer @6.251s
└─sysinit.target @6.250s
└─systemd-update-utmp.service @6.080s +169ms
└─systemd-tmpfiles-setup.service @5.873s +203ms
└─local-fs.target @5.862s
└─local-fs-pre.target @5.862s
└─systemd-remount-fs.service @2.102s +3.758s
└─systemd-readahead-replay.service @1.327s +681ms
I could not get any further info from journalctl
Oct 18 14:07:45 AspireOne systemd[1]: Starting Sockets.
Oct 18 14:07:45 AspireOne systemd[1]: Reached target Sockets.
Oct 18 14:07:45 AspireOne systemd[1]: Starting Daily Cleanup of Temporary Directories.
Oct 18 14:07:56 AspireOne systemd[1]: Started Daily Cleanup of Temporary Directories.
Oct 18 14:07:56 AspireOne systemd[1]: Starting Timers.
Oct 18 14:07:56 AspireOne systemd[1]: Reached target Timers.
Oct 18 14:07:56 AspireOne systemd[1]: Started Manage Sound Card State (restore and store).
Oct 18 14:07:56 AspireOne systemd[1]: Starting Restore Sound Card State...
Oct 18 14:07:56 AspireOne systemd[1]: Starting Basic System.
Oct 18 14:07:56 AspireOne systemd[1]: Reached target Basic System.
Also, is it normal for systemd-remount-fs.service to take nearly 4s to start?
Offline
I have same issue too https://bbs.archlinux.org/viewtopic.php?id=172179
Offline
Possible fix: https://bbs.archlinux.org/viewtopic.php … 6#p1344596
Offline
Hi, first post here.
I've had the same problem with an increasing boot time (since install) and just thought I'd share something that reduced it for me: http://forums.fedoraforum.org/showthread.php?t=286921 (clearing out the content of /var/log/journal). This cut down boot time with about ten seconds for me.
So if I notice an increase in boot time again I think I'll restrict the size of the journal kept by systemd as described here: https://wiki.archlinux.org/index.php/Sy … size_limit.
Hope this can help someone in the future!
Offline