viv...@gmail.com wrote: > First problem udev/SD has is that it can't see all the file system labels, > for some reason it only see sda and sdb so it's able to partly proceed in > the boot sequence, mount / (root) but can't mount anything else.
What software parses the filesystem labels when you boot with openrc? (I ask because I never use labels myself.) > a) SD does not re-calculate it's deptree/services when exiting from rescue > shell, it still try to start the "virtual" services as fstab would have > never modified, a reboot is needed systemctl --system daemon-reload ? > b) since it does not work even after reboot, there must be something else, > but what? this bring us to the point I'm not contesting that there is a problem with your systemd setup, and maybe it is a problem with systemd, but unless you know for sure maybe it's premature to say that "it" is systemd? I would investigate what the problem really is. > SD has mainly two things to debug boot `systemctl dump` and > `systemd-journal` Hm, debug boot like how? I mean: what problem did you want to resolve when you say that you were debugging boot? > impossible even to understand WHAT failed to start, not to mention WHY There are no logfiles for the individual services? > the magnificient binary log^W^W journal is kept on tmpfs (in ram) so > it's not even available at boot in different situation. I'm not sure what the purpose of the binary log is, maybe it makes sense to have it per session, but in any case I guess the services should be doing some logging of their own? > every try needed many minutes because SD wait for a long timeout before > going to the rescue shell I would be interested in understanding why there was a long wait, I mean: what was systemd waiting for? > - SD does not see anything else than systemd for boot. > Interaction with SD from a livecd, is difficult, almost all tools don't > work because SD is not running. I just work with the files on disk. The only time I use tools is if systemd is running and needs to get told about updates. I don't think there are any files that are not plain text, so I don't think any tools are actually required. > transported on remote server administration this is a *nightmare* If there's a way to boot into a shell prompt, even if it is just bash running as pid 1, then any system can be fixed. It requires knowing a lot about how the system works though, so a lot about systemd if the system uses systemd. Ie. knowing what files to change how in order to accomplish desired results. > various provider offer livecd like system which don't offer SD. > so no easy migration, no easy first install, every failure is > definitive, a no go I don't understand this at all. Even if we go with what you write, then I expect that some providers will start to offer an ecosystem of systemd-optimized experiences for those who want it - but I do not believe for a second that those would somehow be exclusive to other systems. > - the journal will never become simpler, can only grow, debugging things in > the shell will be nearly impossible for excess of data (and lack of useful > one if it continue this way) Configure it to write into files? > - virtual/autogenerated services are and will be difficult to cope with, > impossible to disable Hm, do they matter? > - every change in the early boot procedure will require reboot Is that different from another pid 1? > - which sum to: SD will work until it work, when something does not will be > a royal pain to solve _and_ nothing else other than SD will be available to > alleviate the pain This does not match my experience at all. I don't know what you did wrong though, your email wasn't very specific. :\ //Peter
