Hi Michael, Axel I had a system crash yesterday, during an upgrade. Udev, Grub and mdadm were all involved in the upgrade. The system went down during the postinst stage, leaving some packages uncofigured. Even if i can't reproduce running
udevadm control --reload-rules I think it's the same problem. Also, i had 2 similar crashes during an upgrade in October and December 2018. Looking at apt logs i found that both udev and grub were involved in those upgrades. I can reproduce the crash with the following # dpkg -i -i udev_240-4_amd64.deb mdadm_4.1-1_amd64.deb also this works as well (in crashing my system) #dpkg -i udev_240-4_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb while the both the following don't lead to a crash # dpkg -i mdadm_4.1-1_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb # dpkg -i udev_240-4_amd64.deb && dpkg -i grub-pc_2.02+dfsg1-10_amd64.deb >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. Downgraded udev down to udev-239-7, wich looks safe to me while udev 239-8 is affected; i'm currently with 239-8. >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. i don't have sysvinit-core installed, init is runit. >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 I have * runit as PID 1 * /home is on RAID mirror * mdadm is installed * systemd is not installed * kernel is 4.18.0-1-amd64 >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. That's not my enough, i suspect you need also one (or more than one) of the following: * no systemd installed * mdadm installed * a RAID setup (althought i'm not sure this one is feasible in virtualbox) Anything else i can do to help solving this? Thanks, Lorenz Il giorno mer 16 gen 2019 alle ore 15:49 Dmitry Bogatov <kact...@debian.org> ha scritto: > > [ More eyes is better, so please use sysvi...@packages.debian.org > instead personally me for sysvinit-related issues. I read list > carefully. ] > > [2019-01-15 16:17] Axel Beckert <a...@debian.org> > > 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. > > (Dmitry: Please tell me if I should rather send this to the > > mailing-list.) > > > > I will probably also check if an earlier sysvinit version, like e.g. > > 2.88dsf-59.11 (as 2.88dsf-60 IIRC had some issues of its own), makes > > the issue go away, just to be sure (like with udev 239-15). > > Yes, please compare with sysvinit-core=2.88dsf-59.9 (version from > stable), but I doubt it have something to do with sysvinit, since the > only way sysvinit interacts with udev is 'Should-Start: udev' > dependency of some bin:initscripts. > >
