Sweets / hummingbird

Hummingbird init system for Linux based operating systems.
MIT License
247 stars 7 forks source link

help with runit #8

Closed lieux closed 5 years ago

lieux commented 5 years ago

Distribution: Void Linux

I tried using hummingbird along with runit's process supervision using this guide. The guide seems pretty outdated because runsvdir-start does not exist from my current install. So instead, I changed the line having /sbin/runsvdir-start with /etc/runit/2 (source). I also installed tcsh because the guide indirectly says so.

Upon booting up, it shows these lines and stops (I can confirm because I waited for about half an hour):

hummingbird - Linux 4.19.48_1
* Applying /usr/lib/sysctl.d/10-void.conf ...
kernel.core_uses_pid = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.kptr_restrict = 1
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 2
kernel.kexec_load_disabled = 1
kernel.yama.ptrace.scope = 1
* Applying /etc/sysctl.conf ...
/usr/bin/udevd

And when I press enter a couple of times, it goes to the login tty while shooting this error infinitely:

ln: failed to create symbolic link '/run/runit/runsvdir/current/current': File exists
Sweets commented 5 years ago

This seems more like it's going to be a runit-related issue, which unfortunately is beyond the scope of my understand. However, I'll try my best.

What does your .local file look like? Something is linking in a loop, which isn't really a good thing off the bat, which is causing those errors. In addition to this, they're blocking the init, so a personal suggestion while debugging is that I'd just have your system boot as normal but having the process supervision be forked into the background, while outputting errors to a log file.

[whatever the runit command is] 2> /tmp/runit.log &

Also, I don't see any reason why you'd need to install tcsh specifically and couldn't use your system shell, but that's just from a quick Google search, I could be incorrect.

lieux commented 5 years ago

I found the loop. It's in the /etc/runit/2 having the following line:

[ -x /etc/rc.local ] && /etc/rc.local

So I commented that line and tried again. But still, I'm stuck in the /usr/bin/udevd line. Pressed enter a couple of times, and it brings me to the login tty without errors.

However, I can't login. It says the password is incorrect.

I guess it has something to do with the rc.init. I commented everything inside the setup_hotplug function except these lines (I don't have mdevd installed):

udevd --daemon
udevadm trigger --action=add --type=subsystems
udevadm trigger --action=add --type=devices
udevadm settle

And again, I'm stuck at the same block of lines but this time, without the /usr/lib/udevd line.

Sweets commented 5 years ago

You can just comment out setup_hotplug inside main. Everything you commented out was just the other methods for setting up hotplugging. Try commenting out where .local is called in the main rc.init file. It may just be executing them twice, unless I'm misinterpreting what you've said.

The way I think you've got the system set is to that runlevel 2 starts the local init, but so does the normal init anyways. So try without .local and see if it gets the system to boot. If so, from there it's something within .local.

lieux commented 5 years ago

I've already commented that line on the other file. This is what my current setup is supposed to be:

  1. rc.init runs (all the setup functions)
  2. rc.init calls rc.local
  3. rc.local calls /etc/runit/2
  4. rc.init proceeds to the login tty

But my problem is that I can't even get past the first step. It stops on the setup_hotplug function. Does this have something to do with udevd?

lieux commented 5 years ago

Okay. Runit is working now. But something's still bothering me. After these lines had appeared:

hummingbird - Linux 4.19.48_1
* Applying /usr/lib/sysctl.d/10-void.conf ...
kernel.core_uses_pid = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.kptr_restrict = 1
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 2
kernel.kexec_load_disabled = 1
kernel.yama.ptrace.scope = 1
* Applying /etc/sysctl.conf ...
/usr/bin/udevd

I still have to press enter thrice before proceeding to the login tty.

lieux commented 5 years ago

Please be patient. Now, I went stupid and started adding printf's inside all the rc.init functions. And I found out that the script stopped/paused at the setup_random function.

lieux commented 5 years ago

I found it. The issue is on the dd command. I fixed it. Thanks for the help!

Sweets commented 5 years ago

Sorry for the late response (and lack of responses as well); I got really busy and wasn't home yesterday. Anyways, the reason for the keyboard pressing is due to the kernel needing to collect entropy for /dev/random. See your PR for further elaboration.

lieux commented 5 years ago

Hey, I'm sorry, I had to reopen. I followed what you asked me to do from the PR but it seems that it is still slow. I have tried rebooting/shutting down but it it still slow. I'm pretty sure I didn't miss a step.

lieux commented 5 years ago

I diagnosed the problem. And it looks like shutting down or rebooting does not create a random.seed because once I boot, it always goes to this line instead of cat-ing the /tmp/random.seed file which is supposed to be created during shutdown/reboot.

Sweets commented 5 years ago

Alright, so that's the root issue then. Thanks for testing that. I'll do some edits to your PR and we'll fix it all up from there.

lieux commented 5 years ago

Great! Thanks! Re-closing.

lieux commented 5 years ago

I did another test, by the way. I tried changing all /tmp/random.seed into /var/tmp/random.seed on both rc.init and rc.shutdown and it seemed to work.

Sweets commented 5 years ago

It may be that runit cleans the main temporary directory but not variable temporary directory in a run-level.

lieux commented 5 years ago

I may have found the conflict. Is this because my /tmp is mounted on tmpfs? Those were the defaults in Void, though.

Sweets commented 5 years ago

Not entirely sure because I've yet to see the runit source or configurations, but I'm not too worried about how runit handles mounting tmpfs onto /tmp; as long as hummingbird works out in the end lol.

lieux commented 5 years ago

From what I've read, anything inside tmpfs is cleared on shutdown/reboot. So maybe this is what's causing the issue in the first place.