Bug 156956 - cannot format lvm volume
cannot format lvm volume
Status: CLOSED DUPLICATE of bug 159669
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Depends On:
  Show dependency treegraph
Reported: 2005-05-05 13:26 EDT by Avi Kivity
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-08 10:37:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Avi Kivity 2005-05-05 13:26:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3

Description of problem:
if I create an lvm volume, I can't format it:

[root@blast ~]# lvcreate -n fc4x86_64 -L 10G VolGroup00
  Logical volume "fc4x86_64" created
[root@blast ~]# mkfs -t ext3 /dev/mapper/VolGroup00-fc4x86_64
mke2fs 1.37 (21-Mar-2005)
Could not stat /dev/mapper/VolGroup00-fc4x86_64 --- Permission denied

strace shows stat64 returning EACCES:

stat64("/dev/mapper/VolGroup00-fc4x86_64", 0xbf896798) = -1 EACCES (Permission denied)

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

How reproducible:

Steps to Reproduce:
1. lvcreate -L 10G -n blah VolGroup00
2. mkfs -t ext3 /dev/mapper/VolGroup00-blah

Actual Results:  mke2fs 1.37 (21-Mar-2005)
Could not stat /dev/mapper/VolGroup00-fc4x86_64 --- Permission denied

Expected Results:  formatted a new volume

Additional info:
Comment 1 Alasdair Kergon 2005-05-05 14:06:34 EDT
Check how /dev is mounted.   (cat /proc/mounts)
Check /dev/mapper nodes are right (ls -l;  dmsetup info -c)

Comment 2 Alasdair Kergon 2005-05-05 14:26:26 EDT
And is selinux enabled? If so, is it logging any errors?
Comment 3 Avi Kivity 2005-05-05 14:45:47 EDT
turned out fixfiles restore /dev/mapper/* fixed this.

doesn't feel right.
Comment 4 Alasdair Kergon 2005-05-05 15:10:51 EDT
Duplicate of bug 156862 ?
Comment 5 Alasdair Kergon 2005-05-05 15:12:03 EDT

*** This bug has been marked as a duplicate of 156862 ***
Comment 6 Avi Kivity 2005-05-07 03:14:52 EDT
udev-057-4, which fixes bug 156862, does not resolve this.

the problem here is that newly-created volumes have the wrong security context.
for example:

[root@blast ~]# lvcreate -n dummy -L 100M VolGroup00
  Rounding up size to full physical extent 128.00 MB
  Logical volume "dummy" created
[root@blast ~]# ls --lcontext /dev/mapper/VolGroup00-*
brw-rw----  1 root:object_r:device_t           root disk 253, 3 May  7 09:59
brw-rw----  1 system_u:object_r:fixed_disk_device_t root disk 253, 0 May  4
18:00 /dev/mapper/VolGroup00-fc4i386
brw-rw----  1 system_u:object_r:fixed_disk_device_t root disk 253, 2 May  5
20:47 /dev/mapper/VolGroup00-fc4x86_64
brw-rw----  1 system_u:object_r:fixed_disk_device_t root disk 253, 1 May  4
18:00 /dev/mapper/VolGroup00-swap

the 'dummy' volume has the wrong security context, and selinux won't let me
format it. lvm or udev, whichever is responsible for creating the device node,
needs to take care of the security context, not just the old unix permissions.

a reboot between lvcreate and ls --lcontext works around the problem: the volume
appears with the correct security context.
Comment 7 Alasdair Kergon 2005-05-13 14:53:56 EDT
If lvm2 creates it, the security context should get set correctly (this happens
inside libdevmapper).

Did you add some udev rules that are interfering with lvm2 operations?

Run the lvcreate command with debugging enabled (-vvvv) and add 'activate = 1'
to the log section of /etc/lvm/lvm.conf.  [Remove that entry afterwards]
Look for the 'Setting SELinux context for'  message.
Comment 8 Avi Kivity 2005-05-16 03:25:14 EDT
no local udev rules here.

running with verbose logging shows the problem:

#activate/fs.c:176       Linking /dev/VolGroup00/test -> /dev/mapper/VolGroup00-test
#misc/selinux.c:25       Setting SELinux context for /dev/VolGroup00/test

selinux contexts are set only for the symlink (/dev/vg/lv), not for the device
node (/dev/mapper/vg-lv)

[root@blast ~]# ls --lcontext /dev/VolGroup00/test /dev/mapper/VolGroup00-test
brw-rw----  1 root:object_r:device_t           root disk 253, 4 May 16 10:19
lrwxrwxrwx  1 system_u:object_r:device_t       root root     27 May 16 10:19
/dev/VolGroup00/test -> /dev/mapper/VolGroup00-test
Comment 9 Alasdair Kergon 2005-05-16 09:46:38 EDT
That's from a completely different part of the code.

The code that creates the /dev/mapper node doesn't print anything unless it goes
wrong.  (You should get another debug selinux message though if activation
logging is enabled.)

Alternatively use 'strace' to look for the mknod.
Comment 10 Avi Kivity 2005-05-16 11:03:30 EDT
very well, here is an strace, grepped for 'test' (my lv name):

execve("/usr/sbin/lvcreate", ["lvcreate", "-n", "test", "-L", "1G",
"VolGroup00"], [/* 21 vars */]) = 0
stat("/dev/mapper/VolGroup00-test", 0x7fffffcdb700) = -1 ENOENT (No such file or
mknod("/dev/mapper/VolGroup00-test", S_IFBLK|0660, makedev(253, 4)) = 0
chown("/dev/mapper/VolGroup00-test", 0, 6) = 0
lstat("/dev/VolGroup00/test", 0x7fffffcda6d0) = -1 ENOENT (No such file or
symlink("/dev/mapper/VolGroup00-test", "/dev/VolGroup00/test") = 0
lsetxattr("/dev/VolGroup00/test", "security.selinux",
"system_u:object_r:device_t", 27, ) = 0
stat("/dev/VolGroup00/test", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4),
...}) = 0
stat("/dev/VolGroup00/test", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4),
...}) = 0
stat("/dev/VolGroup00/test", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4),
...}) = 0
open("/dev/VolGroup00/test", O_RDWR|O_DIRECT|0x40000) = 3
write(1, "  Logical volume \"test\" created\n", 32  Logical volume "test" created

as you can see, lsetxattr is called for the symlink, but not for the node itself.
Comment 11 Alasdair Kergon 2006-03-08 10:37:17 EST

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

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