diff options
author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
---|---|---|
committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2012-February/011980.html | |
parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
download | archives-1be510f9529cb082f802408b472a77d074b394c0.tar archives-1be510f9529cb082f802408b472a77d074b394c0.tar.gz archives-1be510f9529cb082f802408b472a77d074b394c0.tar.bz2 archives-1be510f9529cb082f802408b472a77d074b394c0.tar.xz archives-1be510f9529cb082f802408b472a77d074b394c0.zip |
Diffstat (limited to 'zarb-ml/mageia-dev/2012-February/011980.html')
-rw-r--r-- | zarb-ml/mageia-dev/2012-February/011980.html | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-February/011980.html b/zarb-ml/mageia-dev/2012-February/011980.html new file mode 100644 index 000000000..7650c82e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-February/011980.html @@ -0,0 +1,179 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] New Dracut: Please test + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20New%20Dracut%3A%20Please%20test&In-Reply-To=%3C4F3B8D06.40505%40colin.guthr.ie%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="011977.html"> + <LINK REL="Next" HREF="011984.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] New Dracut: Please test</H1> + <B>Colin Guthrie</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20New%20Dracut%3A%20Please%20test&In-Reply-To=%3C4F3B8D06.40505%40colin.guthr.ie%3E" + TITLE="[Mageia-dev] New Dracut: Please test">mageia at colin.guthr.ie + </A><BR> + <I>Wed Feb 15 11:46:30 CET 2012</I> + <P><UL> + <LI>Previous message: <A HREF="011977.html">[Mageia-dev] New Dracut: Please test +</A></li> + <LI>Next message: <A HREF="011984.html">[Mageia-dev] New Dracut: Please test +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#11980">[ date ]</a> + <a href="thread.html#11980">[ thread ]</a> + <a href="subject.html#11980">[ subject ]</a> + <a href="author.html#11980">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>'Twas brillig, and Thomas Backlund at 15/02/12 10:09 did gyre and gimble: +><i> Colin Guthrie skrev 15.2.2012 11:35: +</I>>><i> 'Twas brillig, and David W. Hodgins at 14/02/12 23:21 did gyre and +</I>>><i> gimble: +</I>>>><i> On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie +</I>>>><i> <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">mageia at colin.guthr.ie</A>> wrote: +</I>>>><i> +</I>>>>><i> Can everyone please test the new dracut please? Especially those of you +</I>>>><i> +</I>>>><i> I'll test it shortly. I think there is a slight problem when dracut +</I>>>><i> gets +</I>>>><i> updated at the same time as the kernel, udev, or anything else that is +</I>>>><i> going to get installed in the initramfs. +</I>>>><i> +</I>>>><i> Rather then triggering the running of dracut when the kernel gets +</I>>>><i> installed, +</I>>>><i> I think it would be better to have something that runs at the end of +</I>>>><i> urpmi +</I>>>><i> or MageiaUpdate, that check to see if dracut or anything in the existing +</I>>>><i> initramfs has been updated, and if so, then run dracut. +</I>><i> +</I>><i> The best I can do from kernel pov is to change %post into %posttrans so +</I>><i> creating initrd would happend at end of install transaction +</I>><i> +</I>>><i> +</I>>><i> Strangely enough I was thinking vaguely along the same lines. My issue +</I>>><i> was udev specifically. Sadly working out exactly when to rebuild the +</I>>><i> initramfs is pretty tricky, e.g. if lvm or dm tools are updated do we +</I>>><i> really need them in this particular setup's initramfs? Should we rebuild +</I>>><i> anyway (it should be safe) and accept the unnecessary work in those +</I>>><i> cases? Might be a reasonable thing to do... +</I>>><i> +</I>><i> +</I>><i> "it should be safe" - famous last words... :) +</I> +:<i>) +</I> +>><i> I guess then a filetrigger could be written that checks for files +</I>>><i> certain locations and triggers an initrd rebuild. For the kernel it +</I>>><i> would only build one, but for udev, dm, lvm etc. it would rebuild all of +</I>>><i> them... +</I>>><i> +</I>><i> +</I>><i> We should _never_ rebuild all initrds. +</I>><i> If/when one of the updated packaged has a critical systemcrashing bug, +</I>><i> we render the whole system unbootable. +</I> +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. + +>><i> Might confuse some people however and create cases working systems are +</I>>><i> hosed unnecessarily, and I'm not sure how much of real, practical +</I>>><i> problem it is to simply have a slightly outdated tools in the initram +</I>>><i> fs? Perhaps we just need to get ordering better on updates such that +</I>>><i> udev, lvm, dm etc. are all ordered before kernel during updates? Maybe +</I>>><i> that will solve 95% of the issues? +</I>>><i> +</I>><i> +</I>><i> That could be an option of we can get the tools to differentiate between +</I>><i> high-priority (glibc/rpm/urpm*/...), priority (udev/lvm/dm/...) and the +</I>><i> rest... +</I>><i> +</I>><i> Otoh, most of the issues we see now is Cauldron -> Cauldron updates. +</I>><i> in a stable release many of the packages wont change. +</I> +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. + +><i> Of course that still leaves distro upgrades, but maybe that can be +</I>><i> handled in the installer or by adding versionated conflicts to kernel +</I>><i> to help urpmi figure out the order to update... +</I> +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 +<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A> + +Day Job: + Tribalogic Limited <A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A> +Open Source: + Mageia Contributor <A HREF="http://www.mageia.org/">http://www.mageia.org/</A> + PulseAudio Hacker <A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A> + Trac Hacker <A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A> +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="011977.html">[Mageia-dev] New Dracut: Please test +</A></li> + <LI>Next message: <A HREF="011984.html">[Mageia-dev] New Dracut: Please test +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#11980">[ date ]</a> + <a href="thread.html#11980">[ thread ]</a> + <a href="subject.html#11980">[ subject ]</a> + <a href="author.html#11980">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |