On Thu, May 28, 2015 at 1:36 PM, Rich Freeman <ri...@gentoo.org> wrote: > > On Thu, May 28, 2015 at 2:11 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > > > > Actually, it does work (see attached screenshot). I set my root= kernel > > command line parameter wrong on purpose, and systemd (inside dracut) dropped > > me inside a rescue shell. > > Interesting. Perhaps it just enables shell access. > > There is a separate option that configures whether dracut drops to a > shell at all, or if it just hangs on failure. The latter might be > desirable for security purposes in some cases. > > Are you sure that you don't get a shell if you don't pass emergency on > the command line, but still have an invalid root=?
I wasn't sure, I did a couple of tests more. I comment them below. > >> Usually when somebody > >> wants a rescue shell, they want it in their root filesystem, and not > >> in their initramfs before it has pivoted. That is why dracut has > >> options like rd.break. > > > > But that doesn't help you at all when the problem is exactly that you cannot > > mount your root filesystem. With the rescue shell of systemd (inside > > dracut), you can analyze the problem, or perhaps even mount your root > > filesystem and continue the boot process; the initramfs should have all the > > necessary tools to do that. > > rd.break DOES give you a shell before root is mounted, if you tell it to. > > rd.shell tells dracut to give you a shell if something fails > > rd.break forces a shell at the specified point, whether something fails or not. > > The official docs do not list emergency as a valid dracut option. > Obviously systemd uses it, but again the fact that you had to mangle > your root= option sugests that systemd within dracut ignores it if it > can mount your root. No, if you set emergency or rescue, systemd will go to emergency.target and rescue.target, respectively. > >> If the problem were with systemd/services/etc in the actual root > >> filesystem (once the actual distro has started booting), then putting > >> emergency on the command line should get you a rescue shell. > > > > Again, what if the problem is before *that*? > > Then you tell dracut to drop to a shell. I wasn't aware that the > emergency option actually made a difference, though I'm still not 100% > sure that was what did it. I'm now pretty sure it DOESN'T make a difference when the problem is before you can mount root. > >> The same generally applies to openrc - if the initramfs isn't mounting > >> your root filesystem, then passing instructions to openrc won't do > >> anything since in that case openrc isn't even running. > > > > But in this case, systemd *is* inside the initramfs: > > > > # ls usr/lib/systemd/ > > network systemd-cgroups-agent systemd-journald systemd-shutdown > > systemd-vconsole-setup > > system systemd-fsck systemd-modules-load systemd-sysctl > > system-generators > > systemd systemd-hibernate-resume systemd-reply-password systemd-udevd > > > > That's my initramfs. With dracut, systemd *is* the initramfs init system. > > Sure, and that is how mine works as well. But, obviously systemd in > dracut is configured to ignore that parameter when root= is valid, No, it doesn't ignore it, even if root= is valid. > otherwise you'd get a shell every time. I'd have to check the docs, > but I suspect that the behavior is configurable, and systemd within > the initramfs is configured differently. If nothing else they could > just make the rescue target launch the default target/etc. As I said, I did the following tests: 1. Adding "emergency" to the kernel command line, with a valid root=. 2. Adding "rescue" to the kernel command line, with a valid root=. 2. Leaving root= invalid without adding neither "emergency" nor "rescue". If root= is valid, with emergency systemd drops you to a shell with your root filesystem mounted read-only. With rescue, systemd drops you to a shell with all your filesystems mounted read-write. If root= is invalid, it doesn't matter if you use emergency, rescue, or neither, *dracut* drops you to a shell, still inside the initramfs obviously. It takes a while; I didn't took the time, but I think it was 3 minutes. Inside this shell, you can use systemd normally, and if you manage to mount the root filesystem, I'm sure you could continue the normal boot process. You'll have to pivot root manually, though. Hope that makes it clear. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
