[Mageia-dev] New Dracut: Please test

[Colin Guthrie]

'Twas brillig, and Thomas Backlund at 15/02/12 10:09 did gyre and gimble:
> 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.

Did we not used to do it when e.g. the bootspash theme changed? I
remember a while back I had a problem as my /boot was quite modest and
it ended up getting filled up with lots of .old files for the initrds....

That said, I can't really disagree.

>> 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.

Yeah I think overall Cauldron->Cauldron is not that important in the
overall scheme of things. Users hear should be able to rebuild their
initrd with a quick command or two easily enough when needed.

> 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...

Yeah, that's probably a good shout. Just before release, we can put a
"Conflicts: udev < $latest" and similar stuff into the kernel... that
would likely catch most potential problems.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/