From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-February/012314.html | 142 +++++++++++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-February/012314.html (limited to 'zarb-ml/mageia-dev/2012-February/012314.html') diff --git a/zarb-ml/mageia-dev/2012-February/012314.html b/zarb-ml/mageia-dev/2012-February/012314.html new file mode 100644 index 000000000..f6fc6280b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-February/012314.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] New dracut - please test + + + + + + + + + +

[Mageia-dev] New dracut - please test

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Feb 25 11:59:39 CET 2012 +

+
+ +
'Twas brillig, and David W. Hodgins at 25/02/12 07:35 did gyre and gimble:
+> On Fri, 24 Feb 2012 06:42:01 -0500, Colin Guthrie
+> <mageia at colin.guthr.ie> wrote:
+> 
+>> The other big change here is to automatically generate a much bigger
+>> initramfs when doing an upgrade from mga1. This will include a lot more
+>> stuff (e.g. lvm, raid etc) that may or may not be needed on a given
+>> setup, but until you boot with dracut you cannot generate an initramfs
+>> that will be able to detect only what is needed for boot.
+> 
+> Looking at the current version of the init script, it's clear
+> what the problem is ...
+> 
+>     check_finished && break
+> 
+>     udevsettle
+> 
+>     check_finished && break
+> 
+> The above statement will always be true on a single core
+> system, so the following code never gets executed.
+
+As I've said before, I really do not think this is anything to do with
+number of cores. I do see that there is a chicken and egg problem, but
+why would the number of cores affect this? Nothing runs in the
+background here.
+
+As stated earlier
+(https://www.mageia.org/pipermail/mageia-dev/2012-February/011709.html),
+the problem is simply that there are no calls to wait_for_dev for the
+lvm drives and thus the whole initqueue stuff just glosses over things
+and doesn't ever activate them.
+
+What is different to the last time is that now for hostonly initrds (not
+the one you generated), the wait_for_dev call WILL be added. I had hoped
+this different approach would have fixed your problem.
+
+However, due to me now doing this fallback non-hostonly initrd, the
+original problem still manifests itself.
+
+Can you test that generating a new initrd after booting via dracut (and
+thus getting a hostonly one) does actually activate your usr partition?
+I'm not 100% convinced there will not still be a problem with the
+"resume" support and swap partitions, but it will hopefully give you a
+smooth boot even if resume support is busted.
+
+The non-hostonly problem does need a fix and I'll see what can be done.
+
+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/
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1