dracut

dracut copied to clipboard

Signed-off-by: Zoltán Böszörményi [email protected]

Changes

Added new modules: plymouth-ng and boot-animation, the second being a meta-module. plymouth-ng is an alternative to the plymouth module. The difference is that it doesn't rely on plymouth's "populate initrd" script.

Checklist

• [x] I have tested it locally
• [ ] I have reviewed and updated any documentation if relevant
• [x] I am providing new code and tests for it

Hmm I think we either need to carry a full blown plymouth module ourselves or drop the support for it altogether and let whoever host the actual? module maintain it altogether. This whole few bits here, few bits there is not a sustainable approach and bound to be broken on either end.

Hmm I think we either need to carry a full blown plymouth module ourselves or drop the support for it altogether and let whoever host the actual? module maintain it altogether. This whole few bits here, few bits there is not a sustainable approach and bound to be broken on either end.

Will you accept a full rewrite without using external "populate" scripts? I.e. with everything added to module-setup.sh?

'> Will you accept a full rewrite without using external "populate" scripts? I.e. with everything added to module-setup.sh?

I would yes but it should be in a new module + a meta module ( to be able to differentiate between the two or we turn the old one into a meta module ) so we dont break existing setups for x amounts of time until we drop the old plymouth module.

As I said I dont see any value in having a piece of a module here and a piece of the module elsewhere, each only providing partial functionality to consumers.

It wont do anyone any good having it that way, not us, not the upstream with the other half of the module and certainly not the consumer or the downstream vendor to us.

'> Will you accept a full rewrite without using external "populate" scripts? I.e. with everything added to module-setup.sh?

I would yes but it should be in a new module + a meta module ( to be able to differentiate between the two or we turn the old one into a meta module ) so we dont break existing setups for x amounts of time until we drop the old plymouth module.

If I create a new module+meta module, leaving the old one in place, I would still need the current fix for the old one.

Also, before going into implementing the new module, I have to ask: what would be the good name for the new setup?

My suggestions:

The meta module name should be "splash" so it wouldn't clash with anything from https://en.wikipedia.org/wiki/Bootsplash#Linux_distributions Currently it doesn't conflict with any other module name in dracut, either.

The new backend module using plymouth may be called plymouth-ng or plymouth2 until the old one is removed.

As I said I dont see any value in having a piece of a module here and a piece of the module elsewhere, each only providing partial functionality to consumers.

It wont do anyone any good having it that way, not us, not the upstream with the other half of the module and certainly not the consumer or the downstream vendor to us.

Hmm let's call the meta module for what it actually is boot animation as in boot-animation ( as opposed to splash ) and I probably should mention that from a industry point of view, boot animation has been considered obsoleted on a uefi capable hw and the computer manufacturer logo should be displayed instead ( which is why windows dropped support for it in windows 8+ ) so if and then when Fedora and other distribution catch up to the industry and decide to only support uefi capable hw then plymouth and other boot animators will probably be dropped from those distributions ( or atleast their desktop variants ).

Hmm let's call the meta module for what it actually is boot animation as in boot-animation ( as opposed to splash )

Ok, renamed. Thanks for the better name.

and I probably should mention that from a industry point of view, boot animation has been considered obsoleted on a uefi capable hw and the computer manufacturer logo should be displayed instead

Also an industry point of view is that there are a whole lot of non-EFI capable machines used in the point-of-sale industry that must be supported for a long time. Also, POS vendors like to show off so the boot animation will be based on the vendor logo, regardless of the machine's EFI boot logo.

But apart from such politics, I have a technical question: the plymouth module still wants to be included despite these lines in its module-setup.sh:

check() {
    ...
    dracut_module_included boot-animation && return 1
    dracut_module_included plymouth-ng && return 1
    ...
}

This means that dracut --add boot-animation isn't enough, I need dracut --omit plymouth --add boot-animation. Do you know why this happens?

It would help to have tests for this new module. Perhaps we can just switch over some of the existing tests from plymouth module to use the new meta module ?

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

It would help to have tests for this new module. Perhaps we can just switch over some of the existing tests from plymouth module to use the new meta module ?

Done for tests 01, 02, 03 and 04.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

It should be in a new module ... so we dont break existing setups for x amounts of time until we drop the old plymouth module.

I was wondering if you can avoid making a duplicate copy of many of the module files (e.g. plymouth-pretrigger.sh) while we maintain both plymouth and plymouth-ng modules - as this would significantly help with the maintenance upstream.

One way to do this is to make plymouth-ng module dependent on plymouth the module and plymouth-ng could drops a flag to indicate to plymouth not to execute plymouth-populate-initrd.

Another way to achieve reuse is to make plymouth module dependent on plymouth-ng the module and plymouth-ng module could to drop a dracut-plymouth-populate.sh file and plymouth module would have a preference to execute dracut-plymouth-populate.sh over plymouth-populate-initrd .

When the time is right we would remove plymouth module from the tree and and at that time we would remove the dependencies between these 2 modules.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

Moving to draft since this is still a work in progress.

I was wondering if you can avoid making a duplicate copy of many of the module files (e.g. plymouth-pretrigger.sh) while we maintain both plymouth and plymouth-ng modules - as this would significantly help with the maintenance upstream.

I was using something like this approach originally (via symlinks instead of copies) and I was explicitly discouraged here:

https://github.com/dracutdevs/dracut/pull/1774#issuecomment-1088351031

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.