Closed RossComputerGuy closed 2 months ago
samueldr
commented
2 months ago It works for the most part but does take away time from booting the system. The goal with this issue is to improve the reliability of the boot process and speed up booting.
You should explain how (1) it takes away time from booting the system and (2) you would improve the reliability of the boot process.
I can maybe help by pointing out why this figurative Chesterton's fence is there.
RossComputerGuy
commented
2 months ago Startup finished in 3.105s (kernel) + 6.468s (userspace) = 9.573s
graphical.target reached after 6.468s in userspace.I just feel like we could streamline the boot process. Having it kexec on some devices also feels clunky. Fixing these errors would be great as well:
WARNING: Error loading fallback font in FT_New_Face: 1
Error in FT_New_Face: 1
Error: Could not load font; falling back to built-in Roboto@22... (/build/source/hal.c #117)
libinput error: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput: failed to find data files
libinput error: Failed to load the device quirks from /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput and /etc/libinput/local-overrides.quirks. This will negatively affect device behavior. See https://wayland.freedesktop.org/libinput/doc/1.25.0/device-quirks.html for details.
libinput error: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput: failed to find data files
libinput error: Failed to load the device quirks from /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput and /etc/libinput/local-overrides.quirks. This will negatively affect device behavior. See https://wayland.freedesktop.org/libinput/doc/1.25.0/device-quirks.html for details.
libinput error: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput: failed to find data files
libinput error: Failed to load the device quirks from /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libinput-1.25.0/share/libinput and /etc/libinput/local-overrides.quirks. This will negatively affect device behavior. See https://wayland.freedesktop.org/libinput/doc/1.25.0/device-quirks.html for details.
[splash] Listening on: ipc:///run/mobile-nixos-init-messagesI, [2024-06-21T20:18:19.659571//1.0564 #1] INFO -- : Running Tasks::AutoResize...I just feel like we could streamline the boot process.
Again: how? This feels like someone asking a game dev to "just optimize" their game...
Having it kexec on some devices also feels clunky.
Already deprecated and intended for deletion. And you have to understand why the feature was desirable. Using stage-0 kexec was intended to work around hostile bootloader stages where a NixOS generation can't be selected.
Fixing these errors would be great as well:
These are literally not errors, despite what is written. They might be a bit of noise in the logs, sure, but it's not like any time is spent doing any of this.
libinput is being noisy for no good reason in this situation. The quirks are added on an as-needed basis in stage-1 so it doesn't balloon-up in size, since it needs/needed to fit in small footprints for made-for-android devices.RossComputerGuy
commented
2 months ago Well, thank you for the clarification.
samueldr
commented
2 months ago Just to be clear, feel free to make anything you want, but you'll want to have clear goals and measured issues to handle.
There is AFAIK only one "slow" part during boot: waiting for the display+input devices before handling LUKS decryption or SwitchRoot... LUKS decryption is self-explanatory, and the time spent inputting the passphrase dwarfs the rest of the stage-1 runtime... And for SwitchRoot, it's required to handle the "recovery" menu semantics.
Though this does trigger one "weird" pattern that could be improved by short-circuiting it somehow: The boot happens quick enough that by the time the splash can be shown, it's already time for stage-2, so you get the progress bar shown uselessly for the time of the animation (I'd guess ~600ms total). Heuristics could be made that when the only task needed to be resolved for SwtichRoot is the Splash, to skip it entirely, I suppose. (I guess racing the tasks would work?)
I'll add a side-note that the semantics of it all are also built for what was a quite larger scope of vendor-based kernels too, which adds to the perceived complexity.
Currently, there's a framework of Ruby files which enables the boot process. It works for the most part but does take away time from booting the system. The goal with this issue is to improve the reliability of the boot process and speed up booting.