Plymouth falling back to text mode

[Enrico Tagliavini]

Thank you very much for the quick fix Harald.

And thank you very much to you too Ray, for taking a look at this.

Much appreciated.

Best regards
Enrico

On 4 June 2014 13:32, Harald Hoyer <harald at redhat.com> wrote:
> http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=78c982667a6e7855f28540bd914c249e6c53dfa9
>
> Added the udev rules to the udev-rules dracut module.
>
> Thanks! :)
>
> On 03.06.2014 20:56, Enrico Tagliavini wrote:
>> Hi Ray,
>>
>> well moving the udev rules to plymouth module doesn't sounds right to
>> me, to be honest. If you are using the systemd dracut module, which
>> uses seats tags (to my knowledge, correct me if I'm wrong), but not
>> the plymouth dracut module you have the same problem, but the other
>> way around.
>>
>> I agree having some file copied twice is not elegant..... but it is
>> not really wrong. It is like package dependencies, two RPM packages
>> can both depend on a third one. In this case two dracut modules
>> depends on these udev rules, so the only right solution is to call
>> inst_rules in both of them.
>>
>> It is surely possible to make it more elegant, but this requires quite
>> some work on dracut (like tracking every file a package wants to
>> install), and I'm not sure this is worth it.
>>
>> The point of making the change on plymouth or on dracut..... well I
>> still think it is better to do that on plymouth, so you don't need a
>> corresponding change to dracut every time you change something in
>> plymouth. More over the initrd scripts included in plymouth might be
>> useful to other initramfs generation tools, so having them including
>> all the needed files is a good thing.
>>
>> That said if you prefer to keep this in dracut, I'm very happy with it
>> as well. We can adjust the dependencies on version with the package
>> manager so this is a way to solve it. It would be nice to have the
>> minimum required version stated somewhere though.
>>
>> I'm also subscribed to the dracut ML, so I can send an email there and
>> see if anybody has something to say about it, if you like.
>>
>> Kind regards
>> Enrico
>>
>>
>> On 2 June 2014 15:18, Ray Strode <halfline at gmail.com> wrote:
>>> Hi,
>>>
>>> (cc'ing Harald, dracut maintainer)
>>>
>>>> I'm the maintainer of the plymouth package for gentoo. I'm trying to
>>>> update to plymouth 0.9.0 and I found a strange issue, so I subscribed
>>>> to this list hoping I can get some help.
>>> Sure.
>>>
>>>> but misses a seat tag, so plymouth ingnores it (had a very quick
>>>> glance at the code, hope I understood it correctly)
>>> Yea, sounds like you got a pretty good grip on the problem.
>>>
>>>> I checked the generated initramfs and the file
>>>> /lib/udev/rules.d/71-seat.rules is missing. Dracut includes this file
>>>> only if the systemd module is enabled, and indeed the problem is
>>>> solved if I enable the systemd module in the dracut config.
>>>> The problem is in gentoo systemd is not the default init system. It is
>>>> very well supported (and this is what I use for the record), but the
>>>> default is still openrc. Moreover it would be nice to use plymouth
>>>> even when not using systemd.
>>>
>>> Ah okay.  Yea, the udev rule installation should probably be moved to the
>>>
>>> 50-plymouth/module-setup.sh
>>>
>>> from
>>>
>>> 98-systemd/module-setup.sh
>>>
>>>> But is this a plymouth bug or a dracut one? Dracut provides the
>>>> plymouth modules, but it calls the plymouth-populate-initrd script.
>>>> Both of them are not including the needed udev rule to properly mark
>>>> seats.
>>> I think it's a dracut bug because dracut is currently the thing that sets
>>> up udev rules in the initrd.  If we put it in say plymouth-populate-initrd, then
>>> there's a potential for rules to get copied more than once.  It's better if
>>> we do it all in one place I think.
>>>
>>>> And, if I can digress for a moment, why not include the dracut
>>>> plymouth module in plymouth? That way it is granted they are in sync.
>>> I could personally go either way on this one.  Harald, what do you think?
>>>
>>> --Ray
>