On 15/07/17 08:02 PM, L A Walsh wrote:
Anything that isn't setup, *by default* at the time the problem occurs is *NOT AVAILABLE*. There is no "can set up" its either is included or not. Your answer confirms it isn't available.
That's a specious argument if ever I heard one, especially coming from you, Linda, who modifies systems so they diverge well 'out of the box'. The whole point of something like Linux and having text based configuration files is that you can manipulate them, make use of the standard interfaces. You seem to think nothing of writing a script that isn't "default", but the idea of setting up a unit rather than a script is a no-no for you. Sorry, your argument is false.
2) I can try starting 1 more services manually.
Yes you can still do that with systemd.
---- By default, before anything is loaded other than kernel and a shell from the rootfs?
*sigh* You don't seem to have assimilated, if you read that is, the references I pointed to. The answer is yes.
3) I can look at all of the startup operations in one place for a given service. If I need to make a change in a utility's startup while in emergency -- I can.
By my interpretation of what you are asking for, yes I can do that under systemd.
---- Very little was available in emergency mode when I encountered it. Again -- is it there by default, or does someone have to know how to configure it in advance?
They answer is yes to both ways. I'm assuming that we're not talking about someone new to Linux who has never seen a systemd implementation before, loading it for the very first time, never having read the documentation, man pages or any of the 'how-to' available. As I said above, you seem to be OK with preparing scripts and other facilities that can be added, but not in doing other preventive or pre-diagnostic things where systemd is concerned. Perhaps you should just forget your approach and use a LiveCD, then use the debug and diagnostic tools on the CD. There are many such in the LiveCD list. But basically, if you mount the RootFS and get a shell, even in emergency mode, all the functions of 'systemctl' are available to you as well as all the tools in /{usr/,}bin, and the out-of-the-box configuration will let you run 'journalctl -b' in its various forms to let you see what went wrong with the previous boot. of course you would know this if you'd read the documentation. That's how I found out about. I then took the time out to experiment so that I knew in advance what to do if there was a real life problem. And documented it. But then the corporate culture I grew up in practised 'fire drills' and the IT culture exercised it DR plans.
4) When I have worked around a problem, I can continue to boot.
That is entirely dependent on HOW you worked around the problem.
That has never been true before in any of the cases I encountered.
Then you've only ever encountered a small and limited set of problems. On the list, we've had reports of 'bad kernel' (or perhaps bad installation) that even went so far as to damage the RootFS. So you repair the RootFS and reboot WITH A DIFFERENT KERNEL. That happened to me with an early version of BtrFS. I'm sure I'm not alone in such.
It may be that with the problem dealt with you can simply reboot.
--- Rebooting reapplies the error condition.
I said "with the problem dealt with". If its deal with then rebooting happens without the problem.
I didn't say a patch was in place or the problem was fixed. I made a change (like mounting a disk, or configuring a network, or did a modload of a needed kernel module.
Then what's the point of this discussion if you aren't going to fix the problem? . A few months ago I tried installing the stable "leap"
into a VM. Wouldn't boot because a supported config, configured by setup didn't load a needed kernel module. I manually loaded the module but could not continue. Rebooting unloaded the module. So: FAIL.
This is not a boot problem, this is not a systemd problem. Its probably a VM problem. You don't say why you can't continue after manually loading the module. You don't say HOW you loaded the module. You don't say what was in dmesg after loading the module. Did you note any of these? Did you log in your daybook any of these? It may be the module was loaded incorrectly or in the wrong order. Without checking the documented order and dependencies and method of loading, who knows. The loading of kernel modules is a kernel issue and not a systemd issue
It may be that you want to step though each stage of the boot, one unit at a time, to make sure that there are not further ... complications.
It may be so, and as far as I can see and have practised, you can. But what you are describing above is to do with the kernel loading, which is quite a different aspect of the boot process. Systemd, the init(1) process, is to do with starting and managing user level processes. They may make system calls. You're asking me to prognosticate in the absence of adequate detail.
Once again, there are many ways to interpret your requirement.
You mean there are many ways to ask questions that are not relevant to what I asked. You could also ask if I needed the interface in Chinese because I didn't specify the interface language
You're being quite ridiculous, Linda. As I went into above, you simply don't give adequate information for a comprehensive reply. if the questions I ask seem irrelevant it is because the context you give is ambiguous.
I've had network problems due to naming issues that were very difficult to work with and I wanted the system "up" so I could work on them.
Are we talking about device names, names of the ethernet devices, for example? We've had many threads on that issue!
--- Threads are irrelevant. (Network is down at that point, among other reasons).
That is why I have other machines, my laptop, my table, with which I can read this list and access the list archives and search the net. Like many others on this list I have separate hardware that act as my CPE router/firewall and my wifi, so even if my Suse box gets hosed I can still communicate. I really find it hard to believe that you in your setting don't have similar facilitates available to you. Heck, if I were to have everything zapped buy a power surge that got though my UPS, a lightening strike, Then I can always walk across the road to a coffee shop or the library and use the wifi there. You are getting quite ridiculous, Linda.
As I understand it, the modern tools allow for over-riding the naming and other tools allow any dynamic naming to be determined.
---- Tools were irrelevant. They didn't exist the first time it happened.
You contradict yourself. I'm not talking about 3rd party tools, I'm talking about things that are out-of-the-box in a normal distribution; in my case that is the NetworkManager. You are being ridiculous.
Even after fixes (not patches) were applied, future xD policy changes forced the problem again, and again, things broke.
Assertions like that are meaningless without details, Linda. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org