Tails

#1 Updated by intrigeri 2014-06-01 10:15:38

We’ve had many, many similar video corruption issues on various
hardware since we have introduced the kexec-based memory wiping years
ago, so I don’t get why this specific one (even if it’s a regression)
would be a blocker for 1.1 (which the target version indicates), or
even priority higher than normal.

(Yeah, I know, I’m the one usually insisting for setting priority >> normal for regressions :)

#2 Updated by sajolida 2014-06-01 10:32:09

> We’ve had many, many similar video corruption issues on various
> hardware since we have introduced the kexec-based memory wiping years
> ago, so I don’t get why this specific one (even if it’s a regression)
> would be a blocker for 1.1 (which the target version indicates), or
> even priority higher than normal.

Actually, emergency shutdown doesn’t break the video here. If I pull out
the USB stick, the memory wipe message appears as expected.

The video gets broken only if I do a proper shutdown, which makes me
think this is not directly related to kexec and memory wipe.

> (Yeah, I know, I’m the one usually insisting for setting priority >> normal for regressions :)

Well… that’s exactly why I set its priority to Elevated :)

#3 Updated by intrigeri 2014-06-01 11:55:21

> Actually, emergency shutdown doesn’t break the video here. If I pull out the USB stick, the memory wipe message appears as expected.

OK, got it. I think my main point is still valid: given that many computers expose graphics corruption when shutting down Tails (be it caused by kexec, or not, users don’t really care), why would this one be a blocker for 1.1, and not others?

Anyway: thanks for the clarification, it’ll certainly help solving this bug :)

#5 Updated by intrigeri 2014-06-03 05:27:09

Anyone interested in looking into this:

• the emergency shutdown (when pulling out the boot medium) lives in /usr/local/sbin/udev-watchdog-wrapper, and what makes it work fine with X61 is probably in the do_stop method (I bet killing GDM3 and chvt’ing to console 1 is the trick);
• the “normal” shutdown just calls halt via the shutdown-helper-applet.

My next steps would be to:

1. try and reproduce after purging all plymouth packages
2. try and reproduce on a regular Debian Wheezy system
3. try and reproduce on a regular Debian Wheezy system + Linux from Debian unstable

#6 Updated by sajolida 2014-06-04 03:20:35

• Assignee: sajolida

#7 Updated by BitingBird 2014-06-04 06:43:12

sajolida, it looks like you have a problem - it writes “assignee:sajolida”, but it doesn’t set you as assignee (i saw a similar problem yesterday with something else).

#10 Updated by intrigeri 2014-06-25 09:34:06

It might be that if we properly re-enable plymouth at shutdown time (which is the most plausible solution to Feature #5417 I guess), this bug will vanish.