You are not logged in.
My secondary HDD died last night, and so i had to remove it. Not a big problem, since Arch Linux was installed in my primary SDD, and only the SWAP partition and a non-essential data partition were lost. After I removed the entries from /etc/fstab I was able to boot again.
However, I was greeted with and increased boot time (more than 1 minute). After looking at the logs (journalctl), the problem seems to be with this exact line:
kernel: random: crng init doneAfter which the boot will continue. Looking at the Net I've found two causes:
1. An old kernel bug (which doesn't seem to be the case - the kernel didn't change).
2. A SWAP partition that has been deleted (which seems to be the case).
However, the solutions I found were for debian-based systems (for example this), and don't work for Arch. But I tried to solve it using my knowledge (aka the notes I took during the installation).
What I did so far
1. Remove the entries from /etc/fstab
2. Run swapoff
3. Remove resume option from /boot/loader/entries/arch.conf
4. Remove resume HOOK from /etc/mkinitcpio.conf
5. Regenerate initramfs with mkinitcpio -P
But the problem is still here. What more can I do?
EDIT:
1. Full journaltcl -b log if needed
2. Output of systemd-analyze (don't make too much sense).
Startup finished in 5.346s (firmware) + 94ms (loader) + 1.763s (kernel) + 1.734s (userspace) = 8.939s
graphical.target reached after 1.734s in userspaceLast edited by Roboron (2019-08-20 20:06:50)
Offline
If the system supports RDRAND you could try adding the boot parameter random.trust_cpu=on if it does not try installing and enabling haveged.
Last edited by loqs (2019-08-20 19:49:33)
Offline
If the system supports RDRAND you could try adding the boot parameter random.trust_cpu=on if it does not try installing and enabling haveged.
The first solution worked flawlessly. Thank you very much, looks like I was wrong with the swap causing it : |
Offline