[Mageia-dev] New Dracut: Please test

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
+>> 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/
+