3 ms·
Is there a good reason for this? The last I read [0], Dave didn't think that mkinitcpio was the way forward. I've since migrated my setup to use dracut and have
by throwmkinit 5y ago
Is there a good reason for this? The last I read [0], Dave didn't think that mkinitcpio was the way forward. I've since migrated my setup to use dracut and haven't looked back. Is it just inertia that's kept mkinitcpio alive?
[0]: https://lists.archlinux.org/pipermail/arch-dev-public/2019-May/029570.html https://lists.archlinux.org/pipermail/arch-dev-public/2019-M...
- Foxboron 5y agoNo, the last update was that the plan is to keep mkinitcpio and other alternatives maintained. https://lists.archlinux.org/pipermail/arch-dev-public/2021-February/030344.html https://lists.archlinux.org/pipermail/arch-dev-public/2021-F... This is also why I started writing up the feature.
- random53 5y agoHow was the migration? Any potential pitfalls?
- throwmkinit 5y agoRelatively straight-forward once you read up on alpm hooks [0] to make sure you're rebuilding the init at the right times. The wiki [1] has working examples that are drop-in dracut replacements for /usr/share/libalpm/scripts/mkinitcpio-{install,remove}. Dracut also makes it easy to build unified kernel images that can be signed for secure boot, which I never figured out how to do with mkinitcpio. [0] https://man.archlinux.org/man/alpm-hooks.5 https://man.archlinux.org/man/alpm-hooks.5 [1] https://wiki.archlinux.org/title/Dracut https://wiki.archlinux.org/title/Dracut