You are not logged in.
This is my first install. I managed to get to the point where I can boot but when I setup the network I'm stumped.
I looked at the wiki on network configuration. ip link shows dev eno1 is down as expected so I moved on to network manager. I used the systemd one because I think that is the standard one now. So I started systemd-networkd and that failed because a fatal signal was delivered causing the control process to dump core.
systemctl status just confirmed the signal=ABRT
journalctl shows that the service start request repeated too quickly and then the abort. Sorry I can't share that information but with the network down I can't ssh in and capture the logs.
This install was per the wiki as of yesterday and the kernel is 4.20.0-arch1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64
Jim A
Last edited by jfabernathy (2019-01-03 19:32:22)
Offline
"I think that is the standard one now"
Hardly.
eno1 sounds like a wired connection and if that's all you use, just use dhcpcd - more than sufficient for the task.
https://wiki.archlinux.org/index.php/Dhcpcd
You can just "dhcpcd eno1" for the beginning.
Ensure no other network managing services are running.
If you want to know why systemd-networkd aborted, you can post the coredumps and system statūs and whatnot once you've an established network. Or you do the usb walk.
Offline
At your suggestion I disabled all network managing services and used dhcpcd eno1 to get going. I enabled dhcpcd.service, then installed openssh and enabled it's service. Couple of issues though:
1. after a reboot it takes minutes after the login prompt on the main console before ssh is available to login from a remote compute.
2. There are applications I work with that have used the systemd services to control that they don't start running until after the network is up and they use systemd-networkd-wait-online.service. I'm concerned that I may have a problem with that if i can't get systemd-networkd working.
Offline
1) You probably need a random number generator like rngd or haveged.
2) Afaik systemd-networkd-wait-online.service does not require systemd-networkd.
Last edited by schard (2019-01-03 14:50:17)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Or on newer kernels, just pass "random.trust_cpu=on" to the kernel commandline (read up eg. https://www.phoronix.com/scan.php?page= … -RNG-Trust on details)
Offline
The random.trust_cpu=on kernel commandline had no impact.
Offline
However if I login to the console first then ssh login is immediately accepted
Offline
Sounds a lot like an entropy issue, try installing & enabling haveged and post "cat /proc/cmdline" to check the kernel parameters.
Offline
Sounds a lot like an entropy issue, try installing & enabling haveged and post "cat /proc/cmdline" to check the kernel parameters.
installing & enabling haveged fixed it.
initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID="69333ee4-6342-41c3-8758-5c744c2f72ba" rw random.trust_cpu=on
Offline
should I remove the kernel cmdline "random.trust_cpu=on"
Offline
I'd rather worry why it doesn't provide the expected entropy.
But since haveged provides it, you can remove the parameter, yes.
Offline
random.trust_cpu=on requires the CPU supports RDSEED or RDRAND (RDSEED is much newer than RDRAND so if the CPU does not support RDRAND it will not support RDSEED)
lscpu | grep --color rdrandEdit:
@seth could be Sandy Bridge or earlier Intel not sure on AMD.
Last edited by loqs (2019-01-03 16:08:10)
Offline
random.trust_cpu=on is now gone. ssh still works right after boot and before console is logged into.
lscpu | grep --color rdrand produces nothing.
Thanks,
Offline