Is it possible to load a script in Emergency Mode?

Hello all, I am hoping that someone can help me with a problem I have.

I currently have a tablet with broken ACPI tables related to XHCI, and no update available from the manufacturer. I make custom images for it using Kiwi based on 42.1. The problem I had was that if I had xhci_hcd and xhci_pci modules loaded in the initrd, the system would fail to reboot or shutdown completely. The OS would halt correctly, but the hardware would not shut off.

To work around this problem, I blacklisted the xhci modules and rebuilt the initrd, then on system boot I reload the modules using /etc/init.d/after.local and everything shuts down and reboots normally. This works great, however my problem is that the USB ports (ie keyboard) will not work until the /etc/after.local script is loaded. This is not really a problem until the system needs to boot into emergency mode (like if it needs to run a filesystem check) for whatever reason. It is my understanding that no scripts in /etc/init.d/ will run when in emergency mode.

Is there any way to load the xhci modules when in emergency mode? If not, is there any way to remove the xhci modules in Kiwi and only use the older ehci or ohci drivers?

I apologize in advance if this is in the wrong location or if I didn’t include enough information. I have not been using Linux for that long, and even shorter experience with openSUSE. Thank you for any pointers.

You can exclude specific kernel drives from initrd by using omit_drivers parameter (see man dracut.conf). Did you try it?

Otherwise you can explicitly pull your local service into emergency.target. But I would suggest trying the above first, it looks more clean.

Wildly speculating,
Have you considered invoking your scripts by some other way than init.d?

eg
/etc/sysctl
or as a statement in something like the systemd Unit multi-user.targetdirectly or indirectly)
(And, I’m sure there are other potential similar ways)

The methods I suggest load long after the initrd and don’t know how critical that is, but can be used for instance for Loadable Kernel Modules. And, with systemd you might find you have better control over exactly when your script runs

TSU

Thank you for the pointers, guys. I was able to call a script from the emergency mode systemd service that re-enables the modules. I will try to use a cleaner way, but at least I know I now have a working method.