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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
<!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=%3C4EEB3B0A.4060200%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="010523.html">
<LINK REL="Next" HREF="010526.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=%3C4EEB3B0A.4060200%40colin.guthr.ie%3E"
TITLE="[Mageia-dev] Issues with dracut">mageia at colin.guthr.ie
</A><BR>
<I>Fri Dec 16 13:35:22 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="010523.html">[Mageia-dev] Issues with dracut
</A></li>
<LI>Next message: <A HREF="010526.html">[Mageia-dev] Issues with dracut
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#10524">[ date ]</a>
<a href="thread.html#10524">[ thread ]</a>
<a href="subject.html#10524">[ subject ]</a>
<a href="author.html#10524">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Hiya,
'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble:
><i> After those couple previous thread it looks like move to dracut is
</I>><i> ongoing, so I decided to try it.
</I>
Good! This is exactly the kind of feedback we need!
><i> I found a couple problems:
</I>><i>
</I>><i> - dracut inists on loading nouveau driver. With mknitrd, just booting with nokmsboot
</I>><i> works. Booting with a dracut generated initrd ignores that. I think it is plymouth
</I>><i> that forces it, even if I added 'blacklist nouveau' in a .conf file in modprobe.d:
</I>><i>
</I>><i> dracut -f:
</I>
I'll include it but if it's blacklisted, it shouldn't ultimately be used
in the ramfs even if it's included. That said, it's clearly inefficient
to include it if it is blacklisted so we should try and fix that. Anssi,
could this be your code to detect the h/w that causes it to bypass any
blacklist checks (not sure if there are actually any blacklist checks
when building the initrd... not relaly looked at it much)
I think the nokmsboot parameter is not working in dracut because the
udev rule that interprets it uses the grep command and that is not
currently included in the ramdisk. I could hack it in easy enough, but
we should maybe see if a more minimal method of detecting it in the
commandline is possible.
><i> - initrd from dracut fails to detect one of my drives, and booting stops:
</I>
OK, this is more interesting.
><i> systemd[1]: Job dev-sdd1.device/start timed out.
</I>><i> systemd[1]: Job fedora-autorelabel.service/start failed with result 'dependency'.
</I>><i> systemd[1]: Job fedora-autorelabel-mark.service/start failed with result 'dependency'.
</I>><i> systemd[1]: Job mandriva-boot-links.service/start failed with result 'dependency'.
</I>><i> systemd[1]: Job local-fs.target/start failed with result 'dependency'.
</I>><i> systemd[1]: Triggering OnFailure= dependencies of local-fs.target.
</I>><i> systemd[1]: Job export-video.mount/start failed with result 'dependency'.
</I>><i> systemd[1]: Job home-shared-media-video.mount/start failed with result 'dependency'.
</I>><i> systemd[1]: Job dev-sdd1.device/start failed with result 'timeout'.
</I>
When this happens you should get an emergency shell right? In this shell
you should be able to do: "mount /home/shared/media/video" and it should
work, then you should be able to do "systemctl start local-fs.target"
and it should succeed. And you can then do "systemctl start
graphical.target" to continue to a normal boot.
><i> If I rengerate initrd with mkinitrd, system boots fine.
</I>
Sadly mkinitrd fails with anything relating to LVM when used with
systemd so we really do need to solve the problem with dracut to get
this nailed. I'm sure it's possible :)
><i> fstab is like:
</I>><i>
</I>><i> /dev/sda1 / ext4 acl,relatime 1 1
</I>><i> none /proc proc defaults 0 0
</I>><i> /dev/sda2 /opt ext4 acl,relatime 1 2
</I>><i> /dev/sda3 swap swap defaults 0 0
</I>><i> /dev/sdb1 /home ext4 acl,relatime 1 2
</I>><i> /dev/sdc1 /home/shared/media/music ext4 acl,relatime 1 2
</I>><i> /dev/sdd1 /home/shared/media/video ext4 acl,relatime 1 2
</I>><i>
</I>><i> /home/shared/media/music /export/music bind bind 0 0
</I>><i> /home/shared/media/video /export/video bind bind 0 0
</I>><i> /home/shared/in /export/in bind bind 0 0
</I>><i> /opt/soft /export/soft bind bind 0 0
</I>
That all looks OK to me.
><i> lsscsi:
</I>><i> werewolf:~# lsscsi
</I>><i> [3:0:0:0] disk ATA ST3500418AS CC38 /dev/sdd
</I>
I guess sdd translates to ata4...
><i> ata4: SATA max UDMA/133 abar <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">m2048 at 0xf9ffe800</A> port 0xf9ffea80 irq 43
</I>
><i> ata4.00: ATA-8: ST3500418AS, CC38, max UDMA/133
</I>><i> ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
</I>><i> ata4.00: configured for UDMA/133
</I>
Hmm.
Well, systemd uses the information in udev to determin when the disks
are ready/available, so it seems that some kind of metadata goes missing
somewhere.
Can you try and boot with the dracut again, verify you can ultimately
make it to a regular boot via the commands I listed above from the
emergency shell.
You can pass splash=verbose to disable any graphical stuff and and you
can also pass rd.debug=1 to get extra info.
If you boot like that and them post the dmesg, that might offer some clues.
There is also some udevadm stuff to run too after booting.
udevadm info --query env --name=/dev/sdd1
It's this info systemd uses to work out if the disk is ready or not, so
this is probably quite important.
All the best
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="010523.html">[Mageia-dev] Issues with dracut
</A></li>
<LI>Next message: <A HREF="010526.html">[Mageia-dev] Issues with dracut
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#10524">[ date ]</a>
<a href="thread.html#10524">[ thread ]</a>
<a href="subject.html#10524">[ subject ]</a>
<a href="author.html#10524">[ 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>
|
