[Mageia-dev] New Dracut: Please test

Wed Feb 15 11:09:12 CET 2012

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