Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1

Fri Aug 28 23:52:17 BST 2015

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 at 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 <biebl at 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   -  sdowdy at ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/

On Fri, Aug 28, 2015 at 2:26 PM, Michael Biebl <biebl at 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   -  sdowdy at ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150828/68184093/attachment-0002.html>