search

troglobit / finit

Fast init for Linux. Cookies included
https://troglobit.com/projects/finit/
MIT License
633 stars 63 forks source link

hwclock[TIME plugins] failed to execute #110

Closed xhebox closed 4 years ago

xhebox commented 6 years ago

But it works once my system get started. My guess is that it lacks a /dev/xxx before udevd started. Do you have any idea on how to adjust the order?

troglobit commented 6 years ago

Hmm, that should not be a problem as long as the kernel is built with CONFIG_DEVTMPFS, which is strongly recommended for other purposes as well ... or maybe you don't have a /dev/rtc0 module loaded?

xhebox commented 6 years ago

Confirm. My suggestion is making it a task.

EDIT: btw, i think this should be changed to a run/task too, since udevd may not run at the time.

/* Debian has this little script to copy generated rules while the system was read-only */
        if (udev && fexist("/lib/udev/udev-finish"))
                run_interactive("/lib/udev/udev-finish", "Finalizing udev");
troglobit commented 6 years ago

The hwclock plugin could possibly as a task ... but for my embedded systems I'd really want it to run as soon as possible so kernel + userspace have the correct time. But I'll look into it.

The udev-finish thing is currently not possible to move to a run/task because the event loop starts too late. I've been meaning to try to start the event loop much earlier to facilitate relocating parts of the boot process to run/tasklets in the bootstrap runlevel. It's on the TODO list ... sorry.

xhebox commented 6 years ago

I see, maybe make both methods available at the same time, that's also a good workaround. But yes, redesign to let event loop start really earlier is the best solution. We could even make a more generic system to replace plugin&service system if that's possible, so that tty/plugin in c/service/task or so, could all be controlled by one single system, simple and efficient.

It's not a big deal, no matter :).

abucodonosor commented 6 years ago

@troglobit

I think you should check whatever /dev/rtc* exists before running any hwclock commands.

If you don't find any just print a message an that is .. 'Hwclock plugin in use but missing kernel support , skipping.." .. or similar

troglobit commented 6 years ago

@abucodonosor Yup, and we should probably add .conf support for which /dev/rtcN to use (defaulting to /dev/rtc obvs.). The system could have several ...

troglobit commented 4 years ago

I believe this has been fixed, in two parts: