Bug 467193 - RuntimeError: Device has no UUID.
RuntimeError: Device has no UUID.
Status: CLOSED DUPLICATE of bug 471801
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cryptsetup-luks (Show other bugs)
5.3
i386 Linux
high Severity high
: rc
: ---
Assigned To: Milan Broz
Release Test Team
:
Depends On: 471801
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-16 06:19 EDT by Alexander Todorov
Modified: 2013-02-28 23:06 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 771903 (view as bug list)
Environment:
Last Closed: 2008-12-02 09:50:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anacdump.txt (170.61 KB, text/plain)
2008-10-16 06:19 EDT, Alexander Todorov
no flags Details

  None (edit)
Description Alexander Todorov 2008-10-16 06:19:27 EDT
Created attachment 320537 [details]
anacdump.txt

Description of problem:
Anaconda tracebacks on xen pv guest install with encrypted partitions.

Version-Release number of selected component (if applicable):
anaconda-11.1.2.136-2

How reproducible:
always

Steps to Reproduce:
1. Create a xen virtual machine with non-initialized disk images:
virt-install -n linux -r 512 --vnc -f /root/disk1 -s 10 -f /root/disk2 -s 10 -p -l http://server/tree
2. at partitioning screen in anaconda select custom layout.
3. Create the following partitioning table:
/dev/xvda1 ext3          100MB /boot
/dev/xvda2 software RAID 5000MB
/dev/xvda3 software RAID 5000MB (approximately)
/dev/xvdb1 software RAID 5000MB
/dev/xvdb2 software RAID 5000MB
/dev/md0, ext3, RAID5 (all of above partitions), /, encrypted
4. Continue with entering pass phrase and selecting packages. 
  
Actual results:
Traceback (most recent call first):
  File "/usr/lib/anaconda/cryptodev.py", line 195, in openDevice
    raise RuntimeError, "Device has no UUID."
  File "/usr/lib/anaconda/fsset.py", line 2537, in setupDevice
    self.crypto.openDevice()
  File "/usr/lib/anaconda/fsset.py", line 611, in clobberDevice
    device = entry.device.setupDevice(chroot)
  File "/usr/lib/anaconda/fsset.py", line 1835, in formatEntry
    entry.fsystem.clobberDevice(entry, chroot)
  File "/usr/lib/anaconda/fsset.py", line 1913, in makeFilesystems
    self.formatEntry(entry, chroot)
  File "/usr/lib/anaconda/packages.py", line 162, in turnOnFilesystems
    anaconda.id.fsset.makeFilesystems (anaconda.rootPath)
  File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1151, in nextClicked
    self.anaconda.dispatch.gotoNext()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 251, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 1178, in handleRenderCallback
    self.currentWindow.renderCallback()
RuntimeError: Device has no UUID.


Expected results:
RAID5 array is created and is encrypted.

Additional info:
See attached file
Comment 1 Alexander Todorov 2008-10-16 07:29:27 EDT
same configuration worked for HVM guest, so the problem is in the PV guest probably.
Comment 2 David Lehman 2008-10-16 13:53:30 EDT
It looks like cryptsetup is segfaulting. See the last 10 or so lines in syslog.
Comment 3 Milan Broz 2008-10-17 04:51:32 EDT
"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.
Comment 4 Alexander Todorov 2008-10-17 07:23:38 EDT
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
Comment 5 Alexander Todorov 2008-10-17 07:24:58 EDT
Dave,
any ideas why anaconda fails to format the device ?
Comment 6 David Lehman 2008-10-17 15:50:56 EDT
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
Comment 7 Chris Lalancette 2008-10-18 08:15:46 EDT
(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
Comment 8 Milan Broz 2008-11-12 10:33:14 EST
(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.
Comment 10 Milan Broz 2008-11-14 06:52:14 EST
Pleas can you answer question in comment #8?
Comment 11 Alexander Todorov 2008-11-14 11:16:32 EST
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
Comment 12 Milan Broz 2008-11-14 11:30:23 EST
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.
Comment 13 Alexander Todorov 2008-11-14 12:17:16 EST
Fails also when I try to setup encrypted root partition which is simpler:

/dev/xvda1 /boot 100M, ext3
/dev/xvda2 /     10G, ext3, encrypted
Comment 15 Milan Broz 2008-11-14 13:22:23 EST
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...
Comment 16 Milan Broz 2008-11-16 11:54:16 EST
We are using cryptsetup linked with -static libraries, the crash is in uuid library call. See the bug 471801.
Comment 17 Milan Broz 2008-11-16 12:00:56 EST
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
Comment 18 Denise Dumas 2008-11-17 11:53:54 EST
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.
Comment 19 Milan Broz 2008-11-27 08:12:11 EST
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.
Comment 20 Brock Organ 2008-12-02 09:50:58 EST

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

Note You need to log in before you can comment on or make changes to this bug.