Contents
Summary
Since systemd is now a required component, we should use it in the initial ramdisk also.
Owner
- Name: Colin Guthrie
- Email: colin@mageia.org
Resources
Colin Guthrie (systemd and dracut maintainer)
Current status
- Targeted release: Mageia 4
- Last updated: 2013-09-17
- Percentage of completion: 10%
Currently this is possible and it works for those who have tested it. Further tests are still needed before it's enabled in the installer.
Detailed Description
Mageia uses the dracut initrd generator. It has support to use systemd within the initrd as to handle the early boot process.
Why it would be good for Mageia to include it
It reduces the differences between a booted system and the early boot. It also allows some tricks to be adopted to work around the issues of initialising e.g. raid with corresponding mdmon processes in such a way as to prevent killing of the mdmon processes before they should be (see the systemctl patches to mdad in fedora and the mdmon-offroot@.service)
This also allows early boot logs to be preserved in the systemd journal making the boot process more debuggable.
Test case
Make sure it boots!
Software / Packages Dependencies
Support should be present in both systemd and dracut upstream and thus we just need to enable the module by default.
What could disrupt development of this new feature
Not much. It may expose an existing bug more obviously. i.e. when doing distro upgrades, the initrd should be regenerated at the end of the package installation process, not when the kernel is updated. This can be worked around by users by adding kernel-*-latest to their skip lists when doing the upgrade, but this requires user knowledge of the problem. As stated however, this is not a new problem.
Planning
Not much needed other than enabling the systemd module in dracut.
Contingency
Don't use systemd in dracut :)
