On Tue, Jun 10, 2014 at 12:56 PM, Linda Walsh
Anton Aylward wrote:
I'm confused by the way you've phrased all that. My root is a LVM partition. It been possible to use a LVM partition for some while now. So long as you choose a file system that can be expanded live such as my default choice, reiserFS, then its not a problem.
---- Its the fact that you boot from a ramdisk first, which then boots your hard disk.
That's fine if that's your want. But I like the ability to *see* what I am booting... If I change a script in /etc/init.d/XXX.d and reboot, I immediately see the changes. I don't have to regenerate an opaque blob of an initrd.
Do you know all the files that go into your initrd? I have a pretty good idea of the files that my system boots from because they are in front of my eyes all the time. But the files in an initrd are not -- they are in an enclosed blob that you need to go out of your way to peer into and become familiar with. I like being familiar with my system's boot procedure -- I tend to read the boot log nearly every time it comes up --- usually because it's a new kernel and I look for changes. If it boots up off an opaque blob, it is human nature not to look to crack open your initrd and read it on a weekly basis.
Here I tend to agree. Since Solaris switched to using boot archive, "boot archive out of sync" was common source of problems. Fortunately, Solaris also provided simple and documented procedure to fix it. Unfortunately it could not cover all the cases, making it sometimes necessary to still boot from installation media to fix. [...]
Systemd *didn't* do the choke points very well. If followed dependencies starting order, but didn't wait for them to finish. This was especially true of legacy scripts and another reason I steered away from systemd. Too many times it tried to mount the lvm volumes BEFORE lvm was finished running. (as one example -- there were others).
Sigh ... it has nothing to do with systemd. The same problem existed always, also using sysvinit. But large amount of shell code added significant delays to hide this problem in common cases. I went through debugging such issues and I know how painful it is. Systemd offers an interface where daemon can inform init that it has finished initialization and is now ready, so init can proceed with starting any service that depends on this daemon. It is now up to daemon author to use it - but do not blame systemd if daemon author prefers to not implement it. How can you do the same with sysvinit? How can /sbin/rc know when daemon is ready? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org