chimera-linux / dinit-chimera Goto Github PK

using cbuild:

$ ./cbuild install main/dinit-chimera
OK: 195 distinct packages available
=> cbuild: updating software in /build/chimera/bldroot container...
=> cbuild: removing autodeps...
OK: 360 MiB in 66 packages
=> dinit-chimera-0.1-r0: building [makefile] for x86_64...
   [runtime] dinit>=0: found (0.12.0-r0)
   [runtime] util-linux>=0: found (2.37.2-r0)
=> dinit-chimera-0.1-r0: running do_fetch hook: 00_sources...
=> dinit-chimera-0.1-r0: running do_extract hook: 00_sources...
=> dinit-chimera-0.1-r0: running init_patch hook: 00_env_pkg_config...
=> dinit-chimera-0.1-r0: running do_patch hook: 00_patches...
=> dinit-chimera-0.1-r0: running pre_configure hook: 02_script_wrapper...
=> dinit-chimera-0.1-r0: running do_build...
Nothing to be done here.
=> dinit-chimera-0.1-r0: skipping check (disabled by template)
=> dinit-chimera-0.1-r0: running do_install...
install -d /destdir/dinit-chimera-0.1/usr/bin
install -d /destdir/dinit-chimera-0.1/usr/share
install -d /destdir/dinit-chimera-0.1/etc
install -d /destdir/dinit-chimera-0.1/usr/share/man/man8
install -d /destdir/dinit-chimera-0.1/etc/etc/dinit.d
install -d /destdir/dinit-chimera-0.1/etc/etc/dinit.d/early-scripts
install -d /destdir/dinit-chimera-0.1/etc/etc/dinit.d/scripts
install -d /destdir/dinit-chimera-0.1/etc/etc/dinit.d/boot.d
touch /destdir/dinit-chimera-0.1/etc/etc/dinit.d/boot.d/.empty
for conf in rc.conf; do  install -m 644 etc/$conf /destdir/dinit-chimera-0.1/etc;  done
...

plausible fix:

@@ -3,7 +3,7 @@
 BINDIR     ?= $(PREFIX)/bin
 DATADIR    ?= $(PREFIX)/share
 MANDIR     ?= $(DATADIR)/man/man8
-DINITDIR   ?= $(SYSCONFDIR)/etc/dinit.d
+DINITDIR   ?= $(SYSCONFDIR)/dinit.d
 
 BIN_PROGRAMS = modules-load

These currently rely on Chimera's implementations (which are derived from Debian's implementations). It should be possible to plug these early services into any distro-specific infra.

It would be nice to have systemd-style sysusers.d support so that it can be managed with a unit/trigger (and eliminate the need for package post-install hooks in stuff that adds users/groups).

chimera-linux/cports#243

There should be a generic target for syslog at very least.

Currently no effort is made to mount network/auxiliary filesystems. We should probably have another stage that will run. Some thought will need to go into ordering/making it generic, because in some cases there may be cycles.

Some stuff where we currently rely on external binaries, e.g. sysctl, from util-linux, could be replaced with custom special-purpose helpers to eliminate external dependencies.

I have two drives in an x86_64 pc, both encrypted with luks2. One is my root, and the other is a second drive mounted on /mnt/extra mounted through fstab, and decrypted with a keyfile specified in crypttab.

Whenever I reboot or shutdown, my pc hangs on "stopping remainging crypto disks". However, if I ummount and luksClose the drive mounted on /mnt/extra, my pc shutsdown properly.

When hwclock helper is called without explicit clock type arguments, it falls back to localtime - contrary to what is suggested in documentation

More precisely:

• here we init the default for rtc_mod_guess():
  

  dinit-chimera/helpers/hwclock.c

  Line 75 in bc74b83

  mod_t ret = MOD_LOCALTIME;

• here we fall back to localtime if /etc/adjtime is missing, which conveys wrong logic, as according to adjtime_config(5) default clock mode is "UTC" if the file is missing:
  

  dinit-chimera/helpers/hwclock.c

  Line 79 in bc74b83

  return MOD_LOCALTIME;

• here we expect /etc/adjtime to have UTC override, which contradicts the default expectation. We should be checking for LOCAL instead:
  

  dinit-chimera/helpers/hwclock.c

  Line 85 in bc74b83

  ret = MOD_UTC;

So unless you explicitly set utc inside /etc/hwclock (and doc says misleadingly this is an option, not requirement), you will end up with system time being set assuming hardware clock is localtime, resulting it some confusion and clock not respecting timezone setting or other issues.

Suggestion is either to correct the fallback setting to UTC, or adjust the doc with actual behavior description.

Currently we rely on systemd-udev. At very least eudev should be a build-time option, plus possibly options for systems that don't use udev at all.

Just installed this in a VM and noticed this..

.

We currently rely on systemd-tmpfiles for tmpfiles.d handling, but building that is clunky and we'd be better off with an integrated helper.

All the targets at very least need to be documented (manpages).