Michael, I grabbed
https://people.debian.org/~biebl/udev/test0/libudev1_215-17+deb8u2~test0_amd64.deb <https://people.debian.org/%7Ebiebl/udev/test0/libudev1_215-17+deb8u2%7Etest0_amd64.deb> https://people.debian.org/~biebl/udev/test0/udev_215-17+deb8u2~test0_amd64.deb <https://people.debian.org/%7Ebiebl/udev/test0/udev_215-17+deb8u2%7Etest0_amd64.deb> https://people.debian.org/~biebl/udev/test1/libudev1_215-17+deb8u2~test1_amd64.deb <https://people.debian.org/%7Ebiebl/udev/test1/libudev1_215-17+deb8u2%7Etest1_amd64.deb> https://people.debian.org/~biebl/udev/test1/udev_215-17+deb8u2~test1_amd64.deb <https://people.debian.org/%7Ebiebl/udev/test1/udev_215-17+deb8u2%7Etest1_amd64.deb> I presume you want me to test these testN pairs independently -- as there are TWO candidate fixes we're testing? I'll start with the 'test1' pair first then. ........ Sorry this took so long. we'd been debugging and broke out the SAS 6i/R setup to do two standalone disks with MD RAID in an attempt to see if the controller would respond sooner if it wasn't HW RAID-1, so i had to put the system back together. Due to lots of issues, this took a lot longer. I discovered, that our FAI server, which i thought was not using systemd-udevd, is in fact using that. But, it is a hit/miss whether the system hits the bug or not, leading to an occasional window where the system can get installed (booting the installed OS is always a no-go, however, so something in the FAI environment is giving us a slight edge). Also, i had to fight with residual turds from the MD RAID install borking my FAI install -- blowing away all the partitions, 'wipefs', etc weren't working, anyway.... that's all over So in the fai install at the final block before reboot to installed-OS, i did: ------------------------------------------------------------------------- root@hammett:/tmp/fai# chroot /target # cd /root # ls hammett-jessie-fai.dpkg README.FAI sfdisk.out tmp udev-fixes # cd udev-fixes # ls getit test0 test1 # cd test1 # ls libudev1_215-17+deb8u2~test1_amd64.deb udev_215-17+deb8u2~test1_amd64.deb X Y # dpkg -i libudev1_215-17+deb8u2~test1_amd64.deb udev_215-17+deb8u2~test1_amd64.deb (Reading database ... 251068 files and directories currently installed.) Preparing to unpack libudev1_215-17+deb8u2~test1_amd64.deb ... Unpacking libudev1:amd64 (215-17+deb8u2~test1) over (215-17+deb8u1) ... Preparing to unpack udev_215-17+deb8u2~test1_amd64.deb ... Unpacking udev (215-17+deb8u2~test1) over (215-17+deb8u1) ... Setting up libudev1:amd64 (215-17+deb8u2~test1) ... Setting up udev (215-17+deb8u2~test1) ... A chroot environment has been detected, udev not started. A chroot environment has been detected, udev not started. update-initramfs: deferring update (trigger activated) Processing triggers for systemd (215-17+deb8u1) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for libc-bin (2.19-18) ... Processing triggers for initramfs-tools (0.120) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 ------------------------------------------------------------------------- The system DOES boot successfully, after a long pause (as expected)... but it DOES boot. I am going to reboot a few more times with this setup (test1) to make sure it's consistent, and then try installing the 'test0' pair of .debs and get back to you, but i wanted to confirm that at least on initial glance, the 'test1' .debs solve my problem. --stephen On Fri, Aug 28, 2015 at 2:26 PM, Michael Biebl <bi...@debian.org> wrote: > Am 28.08.2015 um 21:41 schrieb Stephen Dowdy: > > I've not built debian source package stuff before, and wasn't quickly > able > > to determine how to even do it on the systemd-215 download, > > so prebuilt packages for amd64 would help greatly. > > > > I'm also not entirely sure if this is happening in the initrd level or in > > the /lib/systemd/systemd-udevd, so can i simply extract the > > 'systemd-udevd' from your package and drop onto the target disk > directory, > > or should i 'dpkg -i' on it from the chroot of my FAI install before > > reboot, or do i need to run a mkinitramfs or > > some other higher-level debian initrd rebuild binary? Just let me know > > what i need to do to if it involves something more complex than either a > > pgk->disk extraction or 'dpkg -i' > > I've uploaded test packages to https://people.debian.org/~biebl/udev/ > The one in the test0 folder have the patch for udev-event.c, the on in > test1 have the patch for udevd.c > > Download the udev and libudev1 deb and install them via dpkg -i. > > Please let me know, if the test0 or test1 package works. > > Simply installing the packages via dpkg will be enough for having the > initrd regenerated. > > > Michael > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/ On Fri, Aug 28, 2015 at 2:26 PM, Michael Biebl <bi...@debian.org> wrote: > Am 28.08.2015 um 21:41 schrieb Stephen Dowdy: > > I've not built debian source package stuff before, and wasn't quickly > able > > to determine how to even do it on the systemd-215 download, > > so prebuilt packages for amd64 would help greatly. > > > > I'm also not entirely sure if this is happening in the initrd level or in > > the /lib/systemd/systemd-udevd, so can i simply extract the > > 'systemd-udevd' from your package and drop onto the target disk > directory, > > or should i 'dpkg -i' on it from the chroot of my FAI install before > > reboot, or do i need to run a mkinitramfs or > > some other higher-level debian initrd rebuild binary? Just let me know > > what i need to do to if it involves something more complex than either a > > pgk->disk extraction or 'dpkg -i' > > I've uploaded test packages to https://people.debian.org/~biebl/udev/ > The one in the test0 folder have the patch for udev-event.c, the on in > test1 have the patch for udevd.c > > Download the udev and libudev1 deb and install them via dpkg -i. > > Please let me know, if the test0 or test1 package works. > > Simply installing the packages via dpkg will be enough for having the > initrd regenerated. > > > Michael > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/
