1

I suspect there's a bug in Ubuntu's default whole disk encryption setup.

Here's what happens, repeatably:

  1. I make a fresh install, Ubuntu 15.10 with whole disk encryption, overwriting the whole disk
  2. It boots and seems to work just fine
  3. A few reboots later, programs start crashing. "Ubuntu has experienced an internal error", Firefox will crash immediately on startup, etc.
  4. Finally, after an additional reboot or two, it will boot to busybox. Running fsck finds and fixes tons of errors.
  5. Go to step 2

Not cool.

Conclusions so far:

  • I'm quite sure it's not disk failure. I reproduced this from scratch with two different drives. In both cases, the SMART data looks healthy, and running self tests thru gnome-disks comes up clean.

Beyond that... I have no idea.

Details:

  • System76 Galago Ultrapro
  • 64-bit desktop Ubuntu 15.10
  • Kernel 4.2.0-18-generic
  • Default Ubuntu whole-disk encryption setup: ext2 boot partition, dm-crypt+LUKS+ext4 main partition.
  • I ran into this first with a 256GB Samsung 840 EVO, then reproduced it on a 512GB Samsung 830. I got the same problems in both cases: works fine for a while, but becomes unusable after a few reboots. Installing Ubuntu without disk encryption works.

Has this happened to anyone else?

I've checked the syslog and couldn't find anything incriminating.

Does anyone know how I could figure out what's going on here?

Improve this question
5
  • I had a nearly identical setup running my personal home server. I saw a very similar corruption. I got frustrated, and now I have a Fedora home server-- but I do think you're on to something with the whole-disk encryption being the culprit.
    – sam
    Dec 8, 2015 at 4:43
  • It wouldn't be the first time: I had corruption problems back in 2006 that turned out to be a kernel bug in dm-crypt when used on top of mdadm. I haven't had any problems (since then) with full-disk encryption in Debian, though, even with the latest kernels in the unstable branch.
    – Wyzard
    Dec 8, 2015 at 5:42
  • * Did both disk work OK for a longer time when not encrypted? * Why don't you try ext3 or ReiserFS, or do they have the same problems?
    – SPRBRN
    Dec 8, 2015 at 8:56
  • SSD + crytpsetup = not good! Use an actual hard-drive or drop encryptions. You might have a TRIM problem.
    – cylgalad
    Dec 8, 2015 at 9:08
  • I've encountered similar issues (on 14.04), but apparently only when I'm using suspend: unix.stackexchange.com/questions/222320/… If I'm using just shutdown/reboot, the issues no longer seem to happen. Have you noticed any difference when not using suspend? Does it still occur?
    – Jack
    Feb 27, 2016 at 15:58

1 Answer 1

Reset to default
0

There have been constant reports of corruption bugs with ext4 file systems, with varying setups. Lots of people complaining in forums. The bug seems to affect more people with RAID configurations.

However, they are supposedly fixed in 4.0.3.

"4.0.3 includes a fix for a critical ext4 bug that can result in major data loss."

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672

There are other ext4 bugs, including bugs fixed as of the 30th of November [of 2015].

https://lists.ubuntu.com/archives/foundations-bugs/2015-November/259035.html

There is also here a very interesting article talking about configuration options in ext4, and possible corruption with it with power failures.

http://www.pointsoftware.ch/en/4-ext4-vs-ext3-filesystem-and-why-delayed-allocation-is-bad/

I would test the setup with other filesystem other than ext4.

Improve this answer
1
  • Thanks! I'll try reproducing the problem with other filesystems if I have more time. For now, the solution I've found is to use home-folder encryption instead of whole-disk encryption. It's still disconcerting that such a standard setup would have such a nasty bug. Vanilla Ubuntu + laptop designed to run Ubuntu + the default whole disk encryption setup.
    – dcposch
    Jan 5, 2016 at 7:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .