Bug 156956 - cannot format lvm volume
Summary: cannot format lvm volume
Keywords:
Status: CLOSED DUPLICATE of bug 159669
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-05 17:26 UTC by Avi Kivity
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-08 15:37:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Avi Kivity 2005-05-05 17:26:52 UTC
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):
lvm2-2.01.08-2.1

How reproducible:
Always

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 18:06:34 UTC
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 18:26:26 UTC
And is selinux enabled? If so, is it logging any errors?

Comment 3 Avi Kivity 2005-05-05 18:45:47 UTC
turned out fixfiles restore /dev/mapper/* fixed this.

doesn't feel right.

Comment 4 Alasdair Kergon 2005-05-05 19:10:51 UTC
Duplicate of bug 156862 ?

Comment 5 Alasdair Kergon 2005-05-05 19:12:03 UTC

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

Comment 6 Avi Kivity 2005-05-07 07:14:52 UTC
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
/dev/mapper/VolGroup00-dummy
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 18:53:56 UTC
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 07:25:14 UTC
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
/dev/mapper/VolGroup00-test
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 13:46:38 UTC
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 15:03:30 UTC
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
directory)
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
directory)
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 15:37:17 UTC

*** 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.