<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Michael, Axel</div><div><br></div><div>I had a system crash yesterday, during an upgrade. Udev, Grub and mdadm were <br></div><div>all involved in the upgrade. The system went down during the postinst stage, leaving</div><div>some packages uncofigured.</div><div>Even if i can't reproduce running</div><div><pre class="gmail-message">udevadm control --reload-rules</pre>I think it's the same problem.</div><div>Also, i had 2 similar crashes during an upgrade in October and December 2018. Looking at</div><div>apt logs i found that both udev and grub were involved in those upgrades.</div><div>I can reproduce the crash with the following</div><div><br></div><div># dpkg -i -i udev_240-4_amd64.deb mdadm_4.1-1_amd64.deb</div><div>also this works as well (in crashing my system)</div><div>#dpkg -i udev_240-4_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb</div><div>while the both the following don't lead to a crash</div><div># dpkg -i mdadm_4.1-1_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb</div><div># dpkg -i udev_240-4_amd64.deb && dpkg -i grub-pc_2.02+dfsg1-10_amd64.deb</div><div><br></div><div><br></div><div><pre class="gmail-message">>Is this specific to version 240-2?
>Could you try downgrading udev to either 239-15 or 240-1 and report back
>with the results.</pre></div><div>Downgraded udev down to udev-239-7, wich looks safe to me while udev 239-8</div><div>is affected; i'm currently with 239-8.</div><div><br></div><div><pre class="gmail-message">>Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
>only process which survives this issue and hence might be involved.</pre></div><div>i don't have sysvinit-core installed, init is runit.</div><div><br></div><div><pre class="gmail-message">>So I wonder what part of my setup causes this:
>
>* 2x LVM on LUKS on MD RAID1 (2 spinning HDDs and 2 SSDs)
>* an (internal) USB 3.0 SD card reader which lets LVM throw warnings
> about "no medium found" for all devices from /dev/sde to /dev/sdk or so.
>* Three screens (1x HDMI, 1x DP, 1x DVI-D)
>* Logitech USB dongle with Solaar
</pre></div><div>I have</div><div>* runit as PID 1</div><div>* /home is on RAID mirror</div><div>* mdadm is installed</div><div>* systemd is not installed</div><div>* kernel is 4.18.0-1-amd64<br></div><div><br></div><div><pre class="gmail-message">>I can't reproduce this problem.
>Neither with a 4.18 (4.18.20-2), 4.19 (4.19.12-1) or 4.20 (4.20-1~exp1)
>kernel. Tested both with systemd as PID 1 and inside a VM with sysvinit
>as PID 1.<br></pre></div><div>That's not my enough, i suspect you need also one (or more than one) of</div><div>the following:</div><div>* no systemd installed</div><div>* mdadm installed</div><div>* a RAID setup (althought i'm not sure this one is feasible in virtualbox)</div><div><br></div><div>Anything else i can do to help solving this?</div><div>Thanks,</div><div>Lorenz<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><pre class="gmail-message"><br></pre></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 16 gen 2019 alle ore 15:49 Dmitry Bogatov <<a href="mailto:KAction@debian.org">KAction@debian.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
[ More eyes is better, so please use <a href="mailto:sysvinit@packages.debian.org" target="_blank">sysvinit@packages.debian.org</a><br>
instead personally me for sysvinit-related issues. I read list<br>
carefully. ]<br>
<br>
[2019-01-15 16:17] Axel Beckert <<a href="mailto:abe@debian.org" target="_blank">abe@debian.org</a>><br>
> Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the<br>
> only process which survives this issue and hence might be involved.<br>
> (Dmitry: Please tell me if I should rather send this to the<br>
> mailing-list.)<br>
> <br>
> I will probably also check if an earlier sysvinit version, like e.g.<br>
> 2.88dsf-59.11 (as 2.88dsf-60 IIRC had some issues of its own), makes<br>
> the issue go away, just to be sure (like with udev 239-15).<br>
<br>
Yes, please compare with sysvinit-core=2.88dsf-59.9 (version from<br>
stable), but I doubt it have something to do with sysvinit, since the<br>
only way sysvinit interacts with udev is 'Should-Start: udev'<br>
dependency of some bin:initscripts.<br>
<br>
</blockquote></div>