Bug 526626

can you reproduce this with selinux in permissive mode? (Use 'setenfoce 0' as root, you can use 'setenforce 1' to turning it back to enforcing mode later)

(In reply to comment #1)
> can you reproduce this with selinux in permissive mode? (Use 'setenfoce 0' as
> root, you can use 'setenforce 1' to turning it back to enforcing mode later)  

I am seeing this problem, too.  I attempted the steps that you described, above, but I used the graphical tool provided with Fedora 11, namely 'system-config-selinux.py' (accessible in Gnome via the menu at System/Administration/SELinux Management).  After switching the System Default Enforcing Mode to Permissive, I rebooted and checked /var/log/messages.  The error messages described above were displayed.

$ ls /dev/tw*
ls: cannot access /dev/tw*: No such file or directory

$ sudo /sbin/service smartd status
smartd (pid 1656) is running...

$ rpm -q selinux-policy smartmontools
selinux-policy-3.6.12-83.fc11.noarch
smartmontools-5.38-13.fc11.x86_64

$ uname -r
2.6.30.8-64.fc11.x86_64

Running 'smartctl' recreates the necessary '/dev/twe*' files:

$ sudo smartctl -H -d 3ware,0 /dev/twe0
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

$ ls /dev/tw*
/dev/twe0   /dev/twe11  /dev/twe14  /dev/twe3  /dev/twe6  /dev/twe9
/dev/twe1   /dev/twe12  /dev/twe15  /dev/twe4  /dev/twe7
/dev/twe10  /dev/twe13  /dev/twe2   /dev/twe5  /dev/twe8

There were problems with selinux-policy for /dev/twe files, but they were resolved in https://bugzilla.redhat.com/show_bug.cgi?id=485489

I'm running with selinux off (too many nfs mounted directories).  So selinux is not blocking the device creation.

fixed in smartmontools-5.38-14.fc11

smartmontools-5.38-14.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/smartmontools-5.38-14.fc11

smartmontools-5.38-18.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/smartmontools-5.38-18.fc12

Tested smartmontools-5.38-14.fc11 and /dev/twe* devices are created when smartd is started as expected.  Appears to be fixed.

(In reply to comment #5)
> smartmontools-5.38-14.fc11 has been submitted as an update for Fedora 11.
> http://admin.fedoraproject.org/updates/smartmontools-5.38-14.fc11  

Has this update gotten lost somewhere?  Although it was submitted on Oct 5th, I am still unable to download this update using the Software Update tool or yum.

$ date
Wed Oct 14 12:10:07 EDT 2009

$ sudo yum install smartmontools
...
Setting up Install Process
Package 1:smartmontools-5.38-13.fc11.x86_64 already installed and latest version
Nothing to do

No, update is not lost, it's just obsoleted by newer update smartmontools-53.8-18.fc11

Package goes to updates-testing first, this is the reason why your yum install command can't find anything newer. This message should be added here by update bot, but it's missing I don't know why. (Bot usually adds message "submitted as an update" and then "has been pushed to updates(-testing) repository, use ... command for updating this package")

If you want to install this update simply use:

sudo yum update --enablerepo=updates-testing smartmontools

After some time in updates-testing repository updates are moved to regular updates repository. This usually takes 3 weeks after update has been pushed to updates-testing. Package can be moved to regular updates repository sooner if it gets at least 3 positive "karmas" (at least 3 users add comment they've tested it and it works).

also see: https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10315

smartmontools-5.38-18.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.