On Sun, Aug 4, 2019 at 7:46 AM L A Walsh <suse@tlinx.org> wrote:
On 2019/08/04 02:46, Simon Lees wrote:
Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped).
so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem.
I find that mounting /usr/{bin,lib,lib64,sbin} on /{...}, is relatively trivial** on my setup.
FWIW, I mount /usr in the 1st boot script to maximize compatibility after that.
**--just because it is trival doesn't mean I would want to do it as it brings a cost. Rather than having a lightweight "miniboot"/rescue in root, I'd have a 65G partition at over 70% usage. Given how often I need to restore a file due to some self-inflicted shot in the foot, a restore would take significantly longer, if I had the disk space for it.
Whether I'm doing development or not, it's still true that I'm an engineer and scientist that experiments and sometimes needs to clean up a mess. AFAIK, systemd doesn't allow you to bring up your system to full running, for example, from an emergency boot.
That's not true. In an emergency boot scenario (particularly early boot failures), you have the opportunity to fix the issue and then have systemd attempt to continue to normal boot without restarting. If that's not working in SUSE distributions, then there's a problem. I've used that in the past on CentOS and Fedora, so I know the facility exists.
To Be clear -- there are several good features in systemd that I like. I've said so for years, but I didn't like the way it was designed to be monolithic such that you have to accept it being pid 1 and its process control to get anything else.
Actually, most of the supplementary services provided by the systemd project don't require systemd running as pid 1. systemd requires the journal, but I don't think any service requires systemd. Certainly nspawn and udev can be used without systemd as pid 1.
I work on scripts to support undoing port-damage and my system. Most things are in the 'need to write code' phase, though I haven't fully thought through my 'init' replacement, as I need to provide a way to capture dead pids so I can provide them to a subscriber that might need them.
Just like linux allows multiple schedulers, and multiple security models, I can't see how resource control might not also be a place for multiple models.
It also seems a bit myopic to not provide a way for different monitors to have access to the list of dead pids caught by pid 1.
As for merging things. Have you thought of using a base of binaries in /bin that supports a miniroot, and then mounting /usr/bin via the overlay-fs, though you could mount /bin on /usr/bin and then mount the rest of usr/bin from another dir as an overlay over the original /usr/bin that contained boot+repair binaries).
The need for this is obviated by our usage of initramfs for early boot, which is a more flexible mechanism that serves this purpose already. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org