wiki/src/bugs/buggy_smem_on_shutdown.mdwn

   1 Problem with [[todo/erase_memory_on_shutdown]]: when closing Amnesia
   2 and shutting down, my PC shows rows upon rows of SQUASHFS errors, and
   3 it doesn't seem to stop. I tried to ppress CTRL+C but nothing happens.
   4
   5 What should I do, besides radically unplugging the PC? Any advice
   6 would be most welcome.
   7
   8 > This is a bug that needs to be fixed. In the meanwhile, yes, you can
   9 > unplug the PC.
  10
  11 >> This bug has been fixed along with the
  12 >> [[todo/smem_progress_report]]. Not tagging as `done` or `pending`
  13 >> has this work has neither been merged into our master
  14 >> `live-initramfs` branch yet, nor been integrated into our main repo
  15 >> as a custom `.deb`.
  16
  17 >>> Now in Git =>  pending => done.
  18
  19 >>>> I hate it but we must reopen this bug. The squashfs errors
  20 >>>> strikes back in 0.5 although I'm pretty sure we had got rid of
  21 >>>> them at some point. A solution based on `/dev/shm` might be more
  22 >>>> robust wrt. caching the necessary files. Else the heavy, never
  23 >>>> released Perl version could still be pulled back.
  24
  25 >>>> The current error message (Lenny image built from Git on 20100903)
  26 >>>> is:
  27
  28         I/O error, dev sr0, sector 43576
  29         Buffer I/O error on device sr0, logical block 10894
  30         Buffer I/O error on device sr0, logical block 10895
  31         Buffer I/O error on device sr0, logical block 10896
  32         Buffer I/O error on device sr0, logical block 10897
  33         Buffer I/O error on device sr0, logical block 10898
  34         Buffer I/O error on device sr0, logical block 10899
  35         Buffer I/O error on device sr0, logical block 10900
  36         Buffer I/O error on device sr0, logical block 10901
  37         SQUASHFS error: squashfs_read_data failed to read block 0x88105b
  38
  39 >>>>> Now that the smem process is pretty quick we could avoid
  40 >>>>> ejecting the CD before erasing the memory => this might be
  41 >>>>> enough to fix this bug.
  42
  43 >>>>>> Fixed by the new kexec-based sdmem system implemented in the
  44 >>>>>> devel branch.
  45
  46 >>>>>> This was tested using [[contribute/release_process/test/erase_memory_on_shutdown]] and
  47 >>>>>> seems to work as expected.
  48
  49 >>>>>>> Removed the pending tag, the new implementation still has a bug : the
  50 >>>>>>> machine isn't rebooted or shutdown after memory wiping. The system
  51 >>>>>>> hangs on the line "Starting new kernel" without any way for the user to
  52 >>>>>>> be sure the memory wiping went fine.
  53
  54 >>>>>>>> I believe we need to move your bug report to a dedicated one,
  55 >>>>>>>> where more information (e.g. hardware, RAM) can be provided:
  56 >>>>>>>> the new system has problem with your test machine, but it
  57 >>>>>>>> generally works. Indeed, it has been shown to be working on a
  58 >>>>>>>> few other test systems. The only bugs we have seen are
  59 >>>>>>>> display corruption on KMS-enabled systems, probably due to
  60 >>>>>>>> failure from the kernel to init the display from a
  61 >>>>>>>> non-fresh-boot graphic mode.
  62
  63 >>>>>>>>> Seems that this situation happened only on very specific and probably
  64 >>>>>>>>> not really functionnal hardware, so should be fine to just mark it as
  65 >>>>>>>>> [[done]]
  66
  67 >>>>>>> This might due to the /sbin/halt binary being wiped in memory (as long
  68 >>>>>>> as all the initramfs).
  69
  70 >>>>>>>> I am not sure about it, but I doubt the kernel would let an
  71 >>>>>>>> userspace process wipe the initramfs from the memory.
  72
  73 >>>>>>> This script should at least be able to shutdown the machine or output to
  74 >>>>>>> the user that he/she can power it off when the sdmem process has
  75 >>>>>>> finished, otherwise the user might be lost in front of this freezed
  76 >>>>>>> screen.
  77
  78 >>>>>>>> On the systems that were used for development and testing,
  79 >>>>>>>> the new system does shutdown/reboot the machine accordingly
  80 >>>>>>>> to what the user initially asked. About the need for feedback
  81 >>>>>>>> in case of failure: I do agree it would be nice, but we have
  82 >>>>>>>> to diagnose first *when* your test system is crashing. If -as
  83 >>>>>>>> I suspect- it crashes during early initramfs stages (e.g.
  84 >>>>>>>> graphics initialization) we cannot do anything about it...
  85 >>>>>>>> but fix the crash.
  86
  87 >>>>>>> This might also conflict with the
  88 >>>>>>> [[memory erasement on media removal feature|todo/erase_memory_when_the_USB_stick_is_removed]],
  89 >>>>>>> which would require to have the machine quicly shutdown.
  90
  91 >>>>>>>> I am sorry not to understand this one.