I noticed today that at some point between OS 6.4 and 6.7, several dependencies required for Plymouth to display text on the splash screen were removed. Specifically, /usr/lib/plymouth/label.so and its dependencies (Pango, Cairo, freetype etc).
Was this a deliberate decision or a consequence of some upstream change? Would it be possible to have these restored? We take advantage of this ability in some aspects of our OS customization as a means to provide messages to the user when no graphics stack may be present.
Naturally it would be possible for us to reinsert these libraries with a custom OS build, but before we go down that route I’d like to understand the reason (if any) for this change.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello BW908,
Thank you for reaching out with your question. It seems that between Toradex OS versions 6.4 and 6.7, certain dependencies required for Plymouth, such as /usr/lib/plymouth/label.so and its related libraries (Pango, Cairo, freetype), were removed. This change might be due to upstream modifications or efforts to streamline the OS by removing components that are less commonly used.
If these components are essential for your OS customization, you can reintroduce them by creating a custom OS build using the Yocto Project. This approach allows you to tailor the OS to meet your specific needs, including restoring any removed libraries. The Yocto Project provides a flexible framework for building custom Linux distributions, which can help you maintain the functionality you require for displaying text on the splash screen during boot.
While I can’t provide specific details on whether this was a deliberate decision by Toradex or a result of upstream changes, creating a custom build is a viable solution to ensure your system continues to function as needed.
If you have further questions or need assistance with the Yocto Project, feel free to ask.
Best regards,
Toradex AI Assistant.
Please, also check if these links can help you solve your problem:
You can see the reasoning in the full commit message, but yes this was a delibrate choice on our side, but not for any “major” reason per se. Since we start the Plymouth splash screen in initramfs, we thought to optimize the size of this since ideally an initramfs should be minimal. We weren’t using this aspect of plymouth and we didn’t think anyone else was either, which led to this decision to remove it. We thought it was okay since no one has complained about this change, until now that is.
Since we removed this purely for optimization reasons I can open a request to re-consider this past decision and see if it’s fine to add these back in.
Thanks for the explanation. We only noticed this recently while moving one of our projects forward to 6.7; we never noticed it on the first one we moved up (and the second already has a custom Yocto build for x64 that mitigates this change - at the time I assumed it was a torizon-common vs official torizon difference rather than looking too deeply at why)
I can certainly appreciate the desire to have a smaller initramfs image for a faster boot time. If that’s a concern and the size increase is unacceptable for the general use case (16M is nothing to sneeze at), I would be perfectly happy if you were to continue leaving them out of the initrd for optimization reasons but restore their presence in the OS itself for our own use cases.
To elaborate on what we are doing with this feature:
A low-level diagnostic tool which can extract logs and other diagnostic data from the system onto a USB drive should the main application have failed and become inoperable.
Our OS update application scheme, for communicating update progress when applying an offline update.
In both cases the scripts interface with Plymouth to put it into system-upgrade mode (for the progress bar) and display additional textual details about what’s going on.
Alright I’ve created the internal request for the team to discuss and reconsider this previous change we did. I will inform you once there’s news to share.
In both cases the scripts interface with Plymouth to put it into system-upgrade mode (for the progress bar) and display additional textual details about what’s going on.
That sounds like a very interesting use of Plymouth. I’d be curious one of these days to learn more about how you do this.
We can definitely connect sometime to go over the details! If I recall, the idea of a Toradex site visit at our HQ was floated during one of our past video calls, or of course you’re welcome to connect with me directly at your convenience as you have my contact info.
During my own work to mitigate this (until there’s an upstream fix) it looks like with newer versions of Plymouth, there are now two variants for label.so - it has been split into label-pango.so and label-freetype.so. Perhaps the non-pango version has fewer dependencies and might be more palatable for re-inclusion in initrd.
it has been split into label-pango.so and label-freetype.so. Perhaps the non-pango version has fewer dependencies and might be more palatable for re-inclusion in initrd.
Thanks for the information, I’ll pass this along.
After much discussion within the team, they came to the following conclusions.
They are against reverting the original commit. The reasoning is that such a change would impact the entire customer-base using Torizon OS. Namely it would lead to an increase in the size of updates.
The possibility of somehow adding this to only the main rootfs and not the initramfs is unknown. It would require an in-depth investigation to see if it is even possible to do in Yocto. An investigation that, bluntly speaking, we’re not sure when we’d be able to commit resources to.
Just adding a note for reference should any others stumble across this topic - the current version of Plymouth (as used in 7.1.0) is bugged and using the freetype dependency for label.so does not work; strace reveals it is still attempting to load label-pango.so when rendering text to the splash screen. So at this time the pango dependency (and associated bloat) is unavoidable for this feature.
