Bug 467193

same configuration worked for HVM guest, so the problem is in the PV guest probably.

It looks like cryptsetup is segfaulting. See the last 10 or so lines in syslog.

"Device has no UUID" is not a cryptsetup message, please check syslog and if there is any message pointing too cryptsetup, add version and config of underlying device which cryptsetup fails.

on tty5 I can only see:
mdadm: array /dev/md0 started

and from tty2:
# cryptsetup isLuks /dev/md0
/dev/md0 is not a LUKS partition


the error in subject comes from cryptodev.py:getUUID() function. The execution order is:
formatDevice()
openDevice()
  getUUID()
     luksUUID()


formatDevice() does `cryptsetup luksFormat` and luksUUID() checks if device is a LUKS device using `cryptsetup isLuks` which in this case fails, no UUID is returned and anaconda throws an exception. 

last lines in anaconda.log are:
10:09:43 INFO    : going to run: ['/usr/sbin/mdadm', '--create', '/dev/md0', '--run', '--chunk=256', '--level=5', '--raid-devices=4', '/dev/xvda2', '/dev/xvda3', '/dev/xvdb1', '/dev/xvdb2']
10:09:44 INFO    : formatting md0 as LUKS



The problem is probably in this part of code from formatDevice() since the log message is written in the logs:

        log.info("formatting %s as %s" % (device, self.getScheme()))
        p = os.pipe()
        os.write(p[1], "%s\n" % (self.passphrase,))
        os.close(p[1])

        rc = iutil.execWithRedirect("cryptsetup",
                                    ["-q", "luksFormat",
                                     "%s/%s" % (devPrefix, device)],
                                    stdin = p[0],
                                    stdout = "/dev/null",
                                    stderr = "/dev/tty5",
                                    searchPath = 1)
        self.format = 0

Dave,
any ideas why anaconda fails to format the device ?

My money says it is related to these messages, which I know do not understand, from the syslog:

<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
<4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac

(In reply to comment #6)
> My money says it is related to these messages, which I know do not understand,
> from the syslog:
> 
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac
> <4>4gb seg fixup, process cryptsetup (pid 491), cs:ip 73:080b9aac

It's possible, but unlikely.  That is basically a warning in the Xen kernel having to do with older glibc's.  I won't go into the details, mostly because I don't remember them, but it basically means that the kernel is going to trap on a bunch of memory accesses (and hence things will be slower).  So that's *probably* not the problem, but stranger things have happened :).

Chris Lalancette

(In reply to comment #4)
> and from tty2:
> # cryptsetup isLuks /dev/md0
> /dev/md0 is not a LUKS partition

please can you check, that first bytes on the device are 'LUKS'?
if not, it is really not LUKS formated and the problem is somewhere else.

Pleas can you answer question in comment #8?

i386: host: -1006.0 guest: -1006.0 - FAIL
i386: host: -1006.0 guest: -1113.1 - FAIL

After the failure:
# dd if=/dev/md0 of=dd.out bs=4 count=1 
# hexdump dd.out 
0000000 0000 0000                              
0000004

i386: host: -1113.1 guest: -1113.1 - FAIL
# dd if=/dev/md0 of=dd.out bs=4 count=1 
# hexdump dd.out 
0000000 0000 0000                              
0000004

/dev/mapper/luks-* not present. 

x86_64: host: -1113.1 guest: -1006.0 - PASS
# dd if=/dev/md0 of=dd.out bs=4 count=1 
# hexdump dd.out 
0000000 554c 534b                              
0000004

# dd if=/dev/mapper/luks-835d3baf-f7b2-4e45-9e22-0c8dc97d5c22 of=dd.out bs=4 count=1 
# hexdump dd.out 
0000000 554c 534b                              
0000004

I'll reassing this to anaconda, there is apparently not created LUKS header, so cryptsetup correctly says that there is no LUKS UUID.

Format device in installer should create LUKS header here.

Fails also when I try to setup encrypted root partition which is simpler:

/dev/xvda1 /boot 100M, ext3
/dev/xvda2 /     10G, ext3, encrypted

Well, I saw the cryptsetup luksFormat segafaults, cryptsetup create works.
There is probably a bug in cryptsetup, but the former problem is different.

One difference between create and luksFormat is that reads master key from /dev/urandom first.

I cannot reproduce it at all, but please can you try that /dev/urandom really works there?

hexdump /dev/urandom should be enough to test

Anyway, I need reproducer for that, coredump or anything to catch why it fails.

On normal machine it works, tried snapshot3 install cd...

We are using cryptsetup linked with -static libraries, the crash is in uuid library call. See the bug 471801.

XEN related problem, it hits even host (not only VM) system.
See the bug 471801 for simple reproducer (without using cryptsetup, just plain uuid_generate() call)

# cryptsetup luksFormat /dev/mapper/x

WARNING!
========
This will overwrite data on /dev/mapper/x irrevocably.

Are you sure? (Type uppercase yes): YES
Segmentation fault

# rpm -q kernel-xen cryptsetup-luks
kernel-xen-2.6.18-92.1.18.el5
cryptsetup-luks-1.0.3-4.el5

# uname -a
Linux proliant06 2.6.18-92.1.18.el5xen #1 SMP Wed Nov 5 09:30:07 EST 2008 i686 i686 i386 GNU/Linux

Changing component to cryptsetup. 
Per Milan:  
https://bugzilla.redhat.com/show_bug.cgi?id=471801 blocking this.
Maybe cryptsetup will work without any change then (if the bug is in kernel)
or (if the bug is in linked library and not in Xen kernel)
cryptsetup need recompilation after the uuid library is fixed.
It is not anaconda bug for sure.

Seems that no change to cryptsetup package will be needed when patch from bug #471801 reach kernel used during instalation.
(On my test system it works in Dom0.)

I keep this bug open just to verify it really works during installation on guest, later it should be closed as dup of bug above.

*** This bug has been marked as a duplicate of bug 471801 ***