Summary: | RFE: add question what shell to use when starting rescue mode | ||
---|---|---|---|
Product: | systemd | Reporter: | Kwpolska <kwpolska> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED NOTABUG | QA Contact: | systemd-bugs |
Severity: | minor | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Kwpolska
2013-12-30 10:29:04 UTC
How often would that be useful? That would be useful whenever: * the shell is broken * the libraries used by the shell are broken (by a system update, by ID10-T error…) * the config of the shell is broken * root has a fancy shell set that fails to work well in tty1/takes a long time to startup/… After all: rescue mode is meant to be started when something is broken badly, and fanciness is not allowed (also, you should’ve seen my face when systemd told me it mounts my drives, I almost thought it doesn’t recognize the ‘single’ kernel parameter) (In reply to comment #2) > That would be useful whenever: ... Yes, but how often do those things happen? In case of extreme breakage, systemd itself links to a bunch of libraries. With the exception of ncurses, bash links to a subset. So if bash is broken, systemd is very likely to be broken too. What if bash is not broken, but zsh/fish/[insert sysadmin’s favorite shell which is the shell of root] is? Or if .bashrc/what-you-have is unusable? In such rare case where systemd still works, but root's shell is broken, init=/bin/sh (or whatever) is the solution. It is pretty unlikely that in such case "emergency" will work. There is no need to cover such unlikely and exotic failure cases with systemd tools, and hope that systemd will still work. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.