Anton Aylward wrote:
On 06/08/2014 05:02 PM, Linda Walsh wrote:
Soon as you show me how to upgrade root w/o rebooting, let me know. I have updated /usr w/o a full reboot and certainly /usr/share is fairly trivial.
Depending on your definition, yes I do all the time.
---- I mean your root partition -- how do you resize or reformat it on a live system? /usr, /usr/share... I can format and restore from backup running from root. I can't restore root except by running from a rescue disk, but it won't have my my lvm & fstsab info if it unmounts root.
If you mean kernel updates, that's another matter.
---- Not really meaning that, but the next closest thing are the kexec features--- which I usually turn off, because my console never gets re-setup correctly after executing one of those.
Again it depends on your definition. If you mean 'get to the 'graphical login' the lets compare apples to apples. Sysvinit required the shell, grep, some awk and more, as well as utilities such as mount and more to get to that point.
I don't use a GUI on my linux system. It comes up in run level 3.
If we drawn the line at where the old sysvinit started running the scripts in /etc/rc5.d or /etc/rc3.d as having completed boot and now starting user services then I think we can have a meaningful discussion, but I don't think that's where YOU are drawing the line.
----- There are 3 points we could talk about. 1 is only used for emergency and that is coming up prior to having run any 'boot.d' scripts.... so no proc, no /sys, no /dev/ no udev, no disks... etc... Second is having brought up base machine to point of being ready to start bringing up the machine -- i.e. usually after boot.d, but before rc3.d scripts. According to the systemd 'dogma', they want the ability to bring up the GUI in parallel with mounting disks -- that means /usr/share + /usr + /. What I would have found fine is -- let me start it up to point with disks mounted (including lvm, since my /usr/share/ is on lvm). Then it could have started systemd and brought up 3 or 5 (or 1)... I would have been ok w/that... But having it have to go from before 'B' (by being the init-shell), to full system allowed no common ground. My system still comes up in all those states -- before 'B', /usr isn't mounted -- it is mounted in 'b', before anything else comes up. But when startup scripts or startup problems prevent my system from coming up, I could boot into the beginning of 'B', and run scripts 1-by-1 to see where the problem was. Let see the systemd follks do that... does it provide an interactive shell at beginning of boot where you can load each item that is part of the boot manually or in a script like for i in S*;do $i start [&] done --- systemd has no such abilities for low level debugging and fixing. If it doesn't boot what are you going to do?... It is init!... That's why going with a simple 'init' that requires nothing, is a good thing--- it's not likely to break.
But if you do mean 'get to the 'graphical login' when you say 'boot' then your assertions about what's required by systemd needs to be compared to what is required - all the functions & libraries and resources used - by sysvinit to get to the same point. When we factor out the common parts I don't think its anywhere near that dramatic.
One of the purposes of systemd was to be able to get many services up and running without needing to make use of shell or shell tools.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org