summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2012-February/011709.html
blob: 325e7785e7d44776d1f0112a6f9eb1275b5d803b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-dev] Issues with dracut
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Issues%20with%20dracut&In-Reply-To=%3C4F2C04AF.5050007%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="011703.html">
   <LINK REL="Next"  HREF="011935.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] Issues with dracut</H1>
    <B>Colin Guthrie</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Issues%20with%20dracut&In-Reply-To=%3C4F2C04AF.5050007%40colin.guthr.ie%3E"
       TITLE="[Mageia-dev] Issues with dracut">mageia at colin.guthr.ie
       </A><BR>
    <I>Fri Feb  3 17:00:47 CET 2012</I>
    <P><UL>
        <LI>Previous message: <A HREF="011703.html">[Mageia-dev] Issues with dracut
</A></li>
        <LI>Next message: <A HREF="011935.html">[Mageia-dev] Issues with dracut
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#11709">[ date ]</a>
              <a href="thread.html#11709">[ thread ]</a>
              <a href="subject.html#11709">[ subject ]</a>
              <a href="author.html#11709">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>'Twas brillig, and David W. Hodgins at 03/02/12 08:04 did gyre and gimble:
&gt;<i> On Tue, 17 Jan 2012 07:22:30 -0500, Colin Guthrie
</I>&gt;<i> &lt;<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">mageia at colin.guthr.ie</A>&gt; wrote:
</I>&gt;<i> 
</I>&gt;&gt;<i> Are things working OK for you now with dracut or is it still busted?
</I>&gt;<i> 
</I>&gt;<i> Just to clarify why I think the problem is happening on single
</I>&gt;<i> core systems.
</I>&gt;<i> 
</I>&gt;<i> On a multi-core system, the bash and udevd processes will be
</I>&gt;<i> running on different cores.
</I>&gt;<i> When the script executes the udev settle command, it continues
</I>&gt;<i> to execute, so the loop checking to see if udev is done finds
</I>&gt;<i> it isn't, so it then looks for/runs the initqueue jobs.
</I>&gt;<i> 
</I>&gt;<i> On a single core system, the bash script waits for the settle
</I>&gt;<i> command to finish, so then finds it's done, and exits without
</I>&gt;<i> even trying to run the initqueue jobs.
</I>&gt;<i> 
</I>&gt;<i> The patch in my prior message is effectively changing the script
</I>&gt;<i> from &quot;udev done or jobs done&quot; to &quot;udev done and jobs done&quot;.
</I>
Hmm, actually thinking about this more, I'm not 100% sure I agree with
this argument. The number of cores should be irrelevant here as the
program itself should be dealing with things synchronously anyway.

I'm wondering if it's more of an issue relating to the fact that it's
not specifically waiting for the LVM device to be ready. I guess your /
is either not on LVM or is in a different Volume Group? In my tests it
worked, but perhaps the dual core machine is simply that bit faster (and
it's speed, not #cores that is important)?

In the file parse-lvm.sh, it does a for loop and has a wait_for_dev
call. This function will put stuff into the initqueue that should
prevent the exiting of the loop until that device exists...

    for dev in $(getargs rd.lvm.vg rd_LVM_VG=) $(getargs rd.lvm.lv
rd_LVM_LV=); do
        wait_for_dev &quot;/dev/$dev&quot;
    done

Now according to the man page, these options are only meant to be used
to restrict what devices are activated so they shouldn't be needed per-se.

But it brings an important point... there does not appear to be any
&quot;wait_for_dev&quot; calls for the usrmount module  So nothing is going to be
waiting for the device to exist. If it takes a little while to come up
it could lead to your error.

And herein we have chicken and egg... we don't know where /usr is (i.e.
which /dev/foo) until we mount /  (as we have to read /etc/fstab). But
by the time we've mounted /, we've already exited this loop and thus
cannot re-enter the loop to wait for more devices.

Tricky, and certainly something I'll discuss with Harald this weekend.
He does have a separate branch that deals with usr mounting in a more
holistic way (i.e. it handles /usr/bin being a separate mount if that
floats your boat!), but I've not looked at this for a while to see if
he's progressed any with it.

All in all, it's perhaps just the fact that the first call to udevadm
settle is skipped due to there being nothing in your initqueue/finished/
folder? You can check via passing rd.break=initqueue and looking in the
folder.

If so, then all that should be needed to get this into shape is to put a
dummy file in there as part of the 98usrmount module, have that file
delete itself and return and error code, thus causing check_finished()
to return non zero and thus the call to udevsettle will be reached.


If this is NOT the issue, then it should just be a timing thing plain
and simple. To confirm, this you should simply be able to pass
rd.break=pre-pivot to the command line, wait a little while and then
just type exit to continue the boot process. This extra time should be
sufficient for udev to &quot;see&quot; the LVM stuff and for the mount command to
succeed (I hope!)

Sorry for the long reply. You will likely have to poke in the dracut
code to understand everything I'm saying, but it looks like you're doing
that happily already :D

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="011703.html">[Mageia-dev] Issues with dracut
</A></li>
	<LI>Next message: <A HREF="011935.html">[Mageia-dev] Issues with dracut
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#11709">[ date ]</a>
              <a href="thread.html#11709">[ thread ]</a>
              <a href="subject.html#11709">[ subject ]</a>
              <a href="author.html#11709">[ 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>