Some debugging information for the udev-watchdog CD eject bug.

wiki/src/bugs/sdmem_on_eject_broken_for_CD.mdwn

 In Tails 0.8-rc1, sdmem on eject works when booting from USB, but has
 no visible effect when booting from CD.
+
+The problems seem to have something to to with udev not sending events
+(e.g. the "change" uevent we wait for) until the device is unmounted.
+The following was tested on a secondary CD-ROM drive (so not the boot
+device which may or may not invalidate this theory):
+
+1. Insert a CD in the seconday CD-ROM drive (say it's /dev/sr1) and
+mount it.
+2. Run: udev-watchdog <udev path for /dev/sr1> cd
+3. Eject the CD.
+4. Observe that the watchdog sees nothing and that the device remains
+mounted. Trying to access the mounted filesystem will produce I/O
+errors.
+4. Run: umount /dev/sr1
+5. Observe that the watchdog finally sees the "change" action.
+
+Furthermore, in lack of hardware, I tested this in VirtualBox, which
+may behave different than real hardware. So YMMV.
+
+When building 0.8-rc1 with the stable kernel (2.6.32-5-486) this issue
+does not arise, which suggests that the issue is with the linux kernel
+and was introduced somewhere after 2.6.32. Otoh, on my up-to-date
+wheezy system (linux 3.0.0-1-amd64, udev 172-1, etc.) I do not have
+this issue using udev-watchdog, wich could suggest a compatibility
+issue with some other package (we also have i386 vs amd64, of course).
+Updating to unstable's udev (172-1) in hope of it playing better with
+linux 3.0.0-1 from unstable did not solve the issue either, however.