Linda is just in a mood for: "They see me trollin, they hatin".
2014-06-10 13:52 GMT+02:00 Anton Aylward
On 06/10/2014 04:56 AM, Linda Walsh wrote:
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.
I don't understand what point you are trying to make here.
I can change a unit and reboot and immediately see the changes. I don't have to regenerate initrd. I don't understand why people told me to regenerate initrd to change my X driver.
You keep saying that systemd HAS to do this or CANNOT do that. The fact is that most of the assertions you make are not in fact so.
Do you know all the files that go into your initrd?
Why? I don't "know" all the files that are /usr/bin or /usr/lib, or all the fonts that are available to me in ... Wherever they live. But I can run 'ls' to find out and I can RTFM and find they live in /usr/share/fonts and run 'ls' on the directories there to see.
And in just the same way I can run 'lsinitrd' to see what files go into my 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.
Ah. ' Micromanaging'. When I boot, which as I say is very rarely, I don't micromanage. I get a mug of coffee. When I install a new release (and yes I can do that with my spell checker turned on, Felix) and something goes wrong, as it often does with new releases which are really just the iteration that comes after the beta test and which all to often was released to a deadline (and anyone who has ever been a programmer knows what *that* means) then I can make use of the pages in my book of cheat sheets. See my earlier posting in this thread about command line options for booting for details on that.
But as I say, I boot so rarely and when I do it always seems to work 'just fine'. I don't need to micromanage.
Heck, I'm sure I could get the system to tell me every library that was referenced with every program I start, but why bother? They work. I'm not a developer doing a trace to debug a new creation.
Perhaps I'm being unfair in calling you a 'micro-manager', Linda. We've already agreed that you run a very non-standard version that has been much modified. Perhaps you NEED to watch things very carefully because they are so non-standard.
I don't reboot often, as I said. Once upon a time I shut down my desktop and the server under my desk every evening. Perhaps this was a mis-guided thought about saving electricity. (Perhaps I need to tie my treadmill to a generator and storage battery and run my desktop of low voltage batteries...) But it was hell on the hard disk.
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.
Just how often do you boot? Just how often do you rebuild your kernel?
But the whole point of systemd was to be able to bring the system up without the need for a shell.
---- Without the need is 1 thing, but since I do development on my system, things sometimes get hosed. If I can't get to a console, restoration is alot more painful.
I don't understand your complaint. I've referenced the pages with boot command options for debugging boot in general and ones for the huge number of options available for systemd debugging, which include confirmation at each step and breaking out into a shell.
Please stop saying that systemd can't do things that it very clearly can do, things that are well documented, things that appear in a quick google and things that I've explicitly pointed out very recently.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
----- 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).
Andrey has already discussed this so I won't repeat his points here.
I will point out that you are attributing to systemd a problem with - as you point out - *legacy* scripts.
---- That's not where the problems come in -- but when libs don't load due to conflicts and you can't login because pam won't approve you. IT's not bugs in the shell scripts but in how the SW is or is not linked together.
So you are blaming systemd for PAM and library problems?
Linda, sometimes its hard to tell whether the problems you describe are intrinsic to the distribution, a result of specific configuration misalignments (PAM can be a terror at times, just like AppArmour!) or are a result of the heavy customization you have made to your system.
What you are describing here sounds like the latter. Identification and Authentication problems involving PAM, library search problems due to incorrect or absent LIBPATH (Under normal circumstances, you only need LIBPATH if shared libraries are located in different directories at run time from those that they are in at compile time, and I think that applies to your case) all have nothing to do with systemd or initrd.
---- If my system is down I can't google. That's perhaps another difference. The system that systemd affects is my only route to the internet.
You only have a single machine? I'm glad I have the Closet of Anxieties and can pull out on old banger. (Many people might keep old bangers in their basement.) I'm glad I have my father's old XP laptop. I'm glad I have my cellphone. I'm glad I have my tablet.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation.
Yes, but this thread isn't about how to survive when you have no access at all and the assertions you are making, the mis-information you are spreading, is being done when you have a usable machine and access to the net and manuals
-- /"\ \ / 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
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org