Comment 5 for bug 1506139

Revision history for this message
Hadmut Danisch (hadmut) wrote :

> From your description it sounds like something is destroying sda3 itself (i. e. the outer encrypted LUKS partition), *not* the unencrypted sda3_crypt, right?

Right.

I've created the partitions with the graphical xubuntu installer from xubuntu 15.10 beta 1 cdrom put on a usb stick, and created both sda2 and sda3 as encrypted volumes, then put a swap in sda2_encrypted and btrfs in sda3_encrypted. This worked well with 14.04.

After booting I've realized that the machine had no swap, even no links to the partition under /dev/disks/by-uuid, and thus could not open the device manually.

I found that the partition was completely filled with random data, no luks header. cryptsetup isLuks said it is not a luks device, and xxd should no trace of a luks header anymore, completely overwritten.

I assumed it was a problem of the installer, not of the running system. My first suspicion was a corrupted partition table, but I did not find any problem with the partition itself. My next suspicion was a fault in the storage device, since I had replaced the old hard disk with a brand new SSD for the fresh install, but except from that problem I do not see any problems with storage, and I experienced these problems on two distinct machines. I do not see any problems on the other partitions and their file systems so far.

> - What do you precisely do to "repair the swap manually"?

cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/sda2 (and enter the same password as for the root partition sda3)
cryptsetup luksOpen /dev/sda2 xxx
mkswap /dev/mapper/xxx

On one of the two machines (office machine, I'm using right now) this helped and the problem did not reoccur so far. That's why I first assumed that it was just a problem of the installation process (graphical xubuntu installer), because I had experienced more trouble with the installer used in the lubuntu 15.10 beta cdrom image.

I did the very same thing at my machine at home, also ran into that problem, again assumed that it was a problem of the xubuntu installer, fixed it as described above, but it reoccured. (Meanwhile there's more trouble with this machine, systemd hangs in the boot process, except when I open an emergency root session.)

>- After that, please copy&paste the output of ...

I'll reply to that once I am back home at that particular machine.