Anton Aylward wrote:
On 15/07/17 06:11 AM, L A Walsh wrote:
1) Recovery means I can run xfsrestore from repair mode.
Yes, you can set up a unit to do that, out of the normal boot sequence but accessible via the boot command line.
Not a problem.
--- 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.
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?
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?
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. Short of needing to run from a different kernel -- anything but that. Again, no advance preparation was required.
It may be that with the problem dealt with you can simply reboot.
--- Rebooting reapplies the error condition. 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. 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.
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.
--- Wasn't what I asked. If that was the case, I'd move on to the next problem.
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 -- but again if I didn't mention it, then the default would taken. Default: not start single stepping after a an error dumps you into the error console and you've applied a fix.
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).
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. Even after fixes (not patches) were applied, future xD policy changes forced the problem again, and again, things broke. That was fixed, but somewhere along the line it broke again -- fortunately after the 2nd break I had already introduced my own override script to set the names regardless of changing policies and config methods -- something that wouldn't work under xD, as it requires being done as part of the HW bringup (that also mounts /usr) because /usr became a requirement for starting OS functions. If xD people want to make these recovery mechanisms available by default, without someone needing to have pre-configured things before their first encounter w/a problem, then you can say these issues are handled by xD. But until then, they are not. BTW, your answers are overwhelmingly unrelated to the original problem of xD not being flexible or configurable. You can't claim it is because it isn't designed to be easily modified by the user -- and certainly not at boot/emergency repair time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org