On 06/09/2014 07:54 PM, Linda Walsh wrote:
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.
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. My opinion is that many people create problems for themselves by the choices they make. If they had made different choices they wouldn't have those problems. I say that about myself too; my problems arise from my choices. The real issue is that most people don't want to admit that, they want to blame other people.
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 + /.
NOT! That's mis-information. The difference between sysvinit and systemd is that the latter identifies things that can be done in parallel. The unit can be parsed to construct a dependency tree. '/usr/share' can be mounted at the same time as '/home' but both are dependent on '/' being mounted. And do on. That is the case with sysvinit as well, but sysvinit does EVERYTHING sequentially. It fails to exploit any inherent parallelism. I recall from my days of C programming, one of the tools was a a call graph generator. It could scan both source code files and object libraries to show what functions depended on what others. With languages such as ALGOL and PASCAL this is clear from the lexical layout, but with C everything is 'top level' lexically. But once libraries come into the operation things can get quite involved: http://domseichter.blogspot.ca/2008/02/visualize-dependencies-of-binaries-an... We also use dependency trees in Zypper/Yast.
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.
Again I'm not clear what you're saying. Are you saying that you could accept a systemd that was simply a replacement for /etc/init.d/rc*.d operations? That what you're objecting to is that it covers the whole deal because it is process 1.
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
But the whole point of systemd was to be able to bring the system up without the need for a shell. And your example of backgrounding each script after starting them in sequential order also strikes me as risky. Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that. Lennart discussed this in some of his early posting on this subject. If you are going to decry systemd than please do get your facts about it straight and accurate. There's been enough misinformation about systemd and historic UNIX promulgated in these threads already.
systemd has no such abilities for low level debugging and fixing.
I must admit I've never needed it. The declarative form of systemd avoid programming mistakes that might appear in shell scripts such as sysvinit uses. However your assertion is incorrect. It does. Having such must at the very least been a part of the development cycle: how else could the developers have seen what was going on? But more specifically: http://freedesktop.org/wiki/Software/systemd/Debugging/ I presume you've read http://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd and goggled for information on debugging systemd? The latter produced quite a bit of interesting stuff. For example, you can add any of this to the boot command line in grub/grub2 rootwait ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug mminit_loglevel=4 udev.log_priority=8 loglevel=8 earlyprintk=vga,keep log_buf_len=10M print_fatal_signals=1 apm.debug=Y i8042.debug=Y drm.debug=1 scsi_logging_level=1 usbserial.debug=Y option.debug=Y pl2303.debug=Y firewire_ohci.debug=1 hid.debug=1 pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y shpchp.shpchp_debug=Y apic=debug show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled I would suggest tying break=y first.
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.
If it doesn't boot than I'll try the above. Also https://wiki.archlinux.org/index.php/systemd#Diagnosing_boot_problems Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM. RTFM? Why yes, there is quite a lot of mention of debugging modes and facilities there. --test Determine startup sequence, dump it and exit. This is an option useful for debugging only. --confirm-spawn Ask for confirmation when spawning processes. --system, --user [...] These options are hence of little use except for debugging. And that's quite apart from things to do woth analysis of the tree, dumping and crash exits. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org