[Mageia-dev] New Dracut: Please test

[Thomas Backlund]

Colin Guthrie skrev 15.2.2012 11:35:
> 'Twas brillig, and David W. Hodgins at 14/02/12 23:21 did gyre and gimble:
>> On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie
>> <mageia at colin.guthr.ie>  wrote:
>>
>>> Can everyone please test the new dracut please? Especially those of you
>>
>> I'll test it shortly.  I think there is a slight problem when dracut gets
>> updated at the same time as the kernel, udev, or anything else that is
>> going to get installed in the initramfs.
>>
>> Rather then triggering the running of dracut when the kernel gets
>> installed,
>> I think it would be better to have something that runs at the end of urpmi
>> or MageiaUpdate, that check to see if dracut or anything in the existing
>> initramfs has been updated, and if so, then run dracut.

The best I can do from kernel pov is to change %post into %posttrans so 
creating initrd would happend at end of install transaction

>
> Strangely enough I was thinking vaguely along the same lines. My issue
> was udev specifically. Sadly working out exactly when to rebuild the
> initramfs is pretty tricky, e.g. if lvm or dm tools are updated do we
> really need them in this particular setup's initramfs? Should we rebuild
> anyway (it should be safe) and accept the unnecessary work in those
> cases? Might be a reasonable thing to do...
>

"it should be safe" - famous last words... :)

> I guess then a filetrigger could be written that checks for files
> certain locations and triggers an initrd rebuild. For the kernel it
> would only build one, but for udev, dm, lvm etc. it would rebuild all of
> them...
>

We should _never_ rebuild all initrds.
If/when one of the updated packaged has a critical systemcrashing bug, 
we render the whole system unbootable.

> Might confuse some people however and create cases working systems are
> hosed unnecessarily, and I'm not sure how much of real, practical
> problem it is to simply have a slightly outdated tools in the initram
> fs? Perhaps we just need to get ordering better on updates such that
> udev, lvm, dm etc. are all ordered before kernel during updates? Maybe
> that will solve 95% of the issues?
>

That could be an option of we can get the tools to differentiate between
high-priority (glibc/rpm/urpm*/...), priority (udev/lvm/dm/...) and the 
rest...

Otoh, most of the issues we see now is Cauldron -> Cauldron updates.
in a stable release many of the packages wont change.

Of course that still leaves distro upgrades, but maybe that can be 
handled in the installer or by adding versionated conflicts to kernel
to help urpmi figure out the order to update...

--
Thomas