[Mageia-dev] New Dracut: Please test
mageia at colin.guthr.ie
Wed Feb 15 11:46:30 CET 2012
'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
>>> 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
>>> 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
>>> I think it would be better to have something that runs at the end of
>>> 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
> 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
> 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.
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the Mageia-dev