From: <s.c...@wa...> - 2007-08-17 23:28:01
|
Hello I'm running an Ubuntu feisty with udev and 2.6.22 kernel. I've got a 3ware 9650 with 8 Seagate harddrives Unfortunately I can't run smartmontools Might be an udev problem because /dev/tweN or /dev/twaN nodes doesn't exists on my server ... On the smartmontools dev tell that is implemented since 5.33 and I'm running 5.36 So I can't do smartctl --all --device=3ware,0 /dev/tweN ... Doesn't work no more with /dev/sda ... Thanks for your help //san1> /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-50 OK - - 256K 2793.91 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 465.76 GB 976773168 9QG1LB6F p1 OK u0 465.76 GB 976773168 9QG0Y4BH p2 OK u0 465.76 GB 976773168 9QG0Z9YY p3 OK u0 465.76 GB 976773168 9QG1KW4W p4 OK u0 465.76 GB 976773168 9QG1N9PJ p5 OK u0 465.76 GB 976773168 9QG1NAX0 p6 OK u0 465.76 GB 976773168 9QG0XSH0 p7 OK u0 465.76 GB 976773168 9QG1MFP9 Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 0 xx-xxx-xxxx //san1> /c0/p0 show status model serial firmware capacity /c0/p0 Status = OK /c0/p0 Model = ST3500630AS /c0/p0 Serial = 9QG1LB6F /c0/p0 Firmware Version = 3.AAK /c0/p0 Capacity = 465.76 GB (976773168 Blocks) #dpkg -l smartmontools smartmontools 5.36-8 control and monitor storage systems using S.M.A.R.T. Regards |
From: Bruce A. <ba...@gr...> - 2007-08-18 06:21:06
|
Could you please send some more details about your system to the list? The contents of /proc/devices and lsmod output would be helpful, as would a summary list of the hardware. Bruce On Sat, 18 Aug 2007, Sébastien CRAMATTE wrote: > Hello > > I'm running an Ubuntu feisty with udev and 2.6.22 kernel. > I've got a 3ware 9650 with 8 Seagate harddrives > > Unfortunately I can't run smartmontools > Might be an udev problem because /dev/tweN or /dev/twaN nodes doesn't > exists on my server ... > > On the smartmontools dev tell that is implemented since 5.33 and I'm > running 5.36 > > So I can't do > > smartctl --all --device=3ware,0 /dev/tweN ... > > Doesn't work no more with /dev/sda ... > > Thanks for your help > > > //san1> /c0 show > > Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache > AVrfy > ------------------------------------------------------------------------------ > u0 RAID-50 OK - - 256K 2793.91 ON > OFF > > Port Status Unit Size Blocks Serial > --------------------------------------------------------------- > p0 OK u0 465.76 GB 976773168 > 9QG1LB6F > p1 OK u0 465.76 GB 976773168 > 9QG0Y4BH > p2 OK u0 465.76 GB 976773168 > 9QG0Z9YY > p3 OK u0 465.76 GB 976773168 > 9QG1KW4W > p4 OK u0 465.76 GB 976773168 > 9QG1N9PJ > p5 OK u0 465.76 GB 976773168 > 9QG1NAX0 > p6 OK u0 465.76 GB 976773168 > 9QG0XSH0 > p7 OK u0 465.76 GB 976773168 > 9QG1MFP9 > > Name OnlineState BBUReady Status Volt Temp Hours LastCapTest > --------------------------------------------------------------------------- > bbu On Yes OK OK OK 0 > xx-xxx-xxxx > > > //san1> /c0/p0 show status model serial firmware capacity > /c0/p0 Status = OK > /c0/p0 Model = ST3500630AS > /c0/p0 Serial = 9QG1LB6F > /c0/p0 Firmware Version = 3.AAK > /c0/p0 Capacity = 465.76 GB (976773168 Blocks) > > #dpkg -l smartmontools > smartmontools > 5.36-8 control and monitor storage > systems using S.M.A.R.T. > > Regards > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: <s.c...@wa...> - 2007-08-18 09:18:10
|
Hello It's strange because "twa" device appear in /proc/devices but not in /dev ... My server is a supermicro with X7DBE+ motherboard. The RAID controller is a 9650SE-8LP pci express I practicaly sure that is an "udev" issue but I don't know how can I resolve this ... Surely I must create a rules file ... #cat /proc/devices Character devices: 1 mem 2 pty 3 ttyp 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 89 i2c 128 ptm 136 pts 180 usb 189 usb_device 253 usb_endpoint 254 twa Block devices: 2 fd 3 ide0 7 loop 8 sd 65 sd 66 sd 67 sd 68 sd 69 sd 70 sd 71 sd 128 sd 129 sd 130 sd 131 sd 132 sd 133 sd 134 sd 135 sd 254 device-mapper #lsmod Module Size Used by i2c_dev 5576 0 xt_limit 1856 2 nf_conntrack_ipv4 9040 6 xt_state 1664 6 nf_conntrack 36124 2 nf_conntrack_ipv4,xt_state ipt_LOG 5184 2 xfs 454664 1 dm_snapshot 10888 0 dm_mirror 13824 0 bonding 68768 0 dm_mod 38608 2 dm_snapshot,dm_mirror usb_storage 26692 0 usbhid 11844 0 sd_mod 12672 1 floppy 50088 0 rtc 8376 0 i2c_i801 8532 0 r8169 19472 0 bitrev 1536 1 r8169 i2c_core 14592 2 i2c_dev,i2c_i801 crc32 3648 1 r8169 ehci_hcd 23820 0 uhci_hcd 18072 0 usbcore 93872 5 usb_storage,usbhid,ehci_hcd,uhci_hcd e1000 160704 0 3w_9xxx 29060 1 scsi_mod 63024 3 usb_storage,sd_mod,3w_9xxx #lspci 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1) 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA Storage Controller AHCI (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 06:00.0 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01) 06:00.1 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01) 09:00.0 RAID bus controller: 3ware Inc Unknown device 1004 (rev 01) 0b:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) Note that I have the same problem whit another server that embed an MSI P35 platinum motherboard with the same RAID controller, same kernel, same ditribution ! Regards Bruce Allen escribió: > Could you please send some more details about your system to the list? > The contents of /proc/devices and lsmod output would be helpful, as > would a summary list of the hardware. > > Bruce > > > On Sat, 18 Aug 2007, Sébastien CRAMATTE wrote: > >> Hello >> >> I'm running an Ubuntu feisty with udev and 2.6.22 kernel. >> I've got a 3ware 9650 with 8 Seagate harddrives >> >> Unfortunately I can't run smartmontools >> Might be an udev problem because /dev/tweN or /dev/twaN nodes doesn't >> exists on my server ... >> >> On the smartmontools dev tell that is implemented since 5.33 and I'm >> running 5.36 >> >> So I can't do >> >> smartctl --all --device=3ware,0 /dev/tweN ... >> >> Doesn't work no more with /dev/sda ... >> >> Thanks for your help >> >> >> //san1> /c0 show >> >> Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache >> AVrfy >> ------------------------------------------------------------------------------ >> >> u0 RAID-50 OK - - 256K 2793.91 ON >> OFF >> >> Port Status Unit Size Blocks Serial >> --------------------------------------------------------------- >> p0 OK u0 465.76 GB 976773168 >> 9QG1LB6F >> p1 OK u0 465.76 GB 976773168 >> 9QG0Y4BH >> p2 OK u0 465.76 GB 976773168 >> 9QG0Z9YY >> p3 OK u0 465.76 GB 976773168 >> 9QG1KW4W >> p4 OK u0 465.76 GB 976773168 >> 9QG1N9PJ >> p5 OK u0 465.76 GB 976773168 >> 9QG1NAX0 >> p6 OK u0 465.76 GB 976773168 >> 9QG0XSH0 >> p7 OK u0 465.76 GB 976773168 >> 9QG1MFP9 >> >> Name OnlineState BBUReady Status Volt Temp Hours >> LastCapTest >> --------------------------------------------------------------------------- >> >> bbu On Yes OK OK OK 0 >> xx-xxx-xxxx >> >> >> //san1> /c0/p0 show status model serial firmware capacity >> /c0/p0 Status = OK >> /c0/p0 Model = ST3500630AS >> /c0/p0 Serial = 9QG1LB6F >> /c0/p0 Firmware Version = 3.AAK >> /c0/p0 Capacity = 465.76 GB (976773168 Blocks) >> >> #dpkg -l smartmontools >> smartmontools >> 5.36-8 control and monitor storage >> systems using S.M.A.R.T. >> >> Regards >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Smartmontools-support mailing list >> Sma...@li... >> https://lists.sourceforge.net/lists/listinfo/smartmontools-support >> |
From: Bruce A. <ba...@gr...> - 2007-08-18 22:15:16
|
Sébastien: Have a look at this old mailing list thread from Andreas Unterkircher. Andreas: can you help out? I think you reported some similar issues at some point, but then figured out a fix. Cheers, Bruce On Sat, 18 Aug 2007, Sébastien CRAMATTE wrote: > Hello > > It's strange because "twa" device appear in /proc/devices but not in > /dev ... > My server is a supermicro with X7DBE+ motherboard. The RAID controller > is a 9650SE-8LP pci express > > I practicaly sure that is an "udev" issue but I don't know how can I > resolve this ... > Surely I must create a rules file ... > > > #cat /proc/devices > Character devices: > 1 mem > 2 pty > 3 ttyp > 4 /dev/vc/0 > 4 tty > 4 ttyS > 5 /dev/tty > 5 /dev/console > 5 /dev/ptmx > 7 vcs > 10 misc > 13 input > 89 i2c > 128 ptm > 136 pts > 180 usb > 189 usb_device > 253 usb_endpoint > 254 twa > > Block devices: > 2 fd > 3 ide0 > 7 loop > 8 sd > 65 sd > 66 sd > 67 sd > 68 sd > 69 sd > 70 sd > 71 sd > 128 sd > 129 sd > 130 sd > 131 sd > 132 sd > 133 sd > 134 sd > 135 sd > 254 device-mapper > > #lsmod > Module Size Used by > i2c_dev 5576 0 > xt_limit 1856 2 > nf_conntrack_ipv4 9040 6 > xt_state 1664 6 > nf_conntrack 36124 2 nf_conntrack_ipv4,xt_state > ipt_LOG 5184 2 > xfs 454664 1 > dm_snapshot 10888 0 > dm_mirror 13824 0 > bonding 68768 0 > dm_mod 38608 2 dm_snapshot,dm_mirror > usb_storage 26692 0 > usbhid 11844 0 > sd_mod 12672 1 > floppy 50088 0 > rtc 8376 0 > i2c_i801 8532 0 > r8169 19472 0 > bitrev 1536 1 r8169 > i2c_core 14592 2 i2c_dev,i2c_i801 > crc32 3648 1 r8169 > ehci_hcd 23820 0 > uhci_hcd 18072 0 > usbcore 93872 5 usb_storage,usbhid,ehci_hcd,uhci_hcd > e1000 160704 0 > 3w_9xxx 29060 1 > scsi_mod 63024 3 usb_storage,sd_mod,3w_9xxx > > #lspci > 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller > Hub (rev b1) > 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 > Port 2-3 (rev b1) > 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 > Port 4-5 (rev b1) > 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 > Port 6-7 (rev b1) > 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset Error > Reporting Registers (rev b1) > 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset Error > Reporting Registers (rev b1) > 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset Error > Reporting Registers (rev b1) > 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved > Registers (rev b1) > 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved > Registers (rev b1) > 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers > (rev b1) > 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers > (rev b1) > 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI > Express Root Port 1 (rev 09) > 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset > UHCI USB Controller #1 (rev 09) > 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset > UHCI USB Controller #2 (rev 09) > 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset > UHCI USB Controller #3 (rev 09) > 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset > EHCI USB2 Controller (rev 09) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) > 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC > Interface Controller (rev 09) > 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller > (rev 09) > 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA Storage > Controller AHCI (rev 09) > 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus > Controller (rev 09) > 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express > Upstream Port (rev 01) > 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to > PCI-X Bridge (rev 01) > 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express > Downstream Port E1 (rev 01) > 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express > Downstream Port E3 (rev 01) > 03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge > A (rev 09) > 03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge > B (rev 09) > 05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 > Gigabit Ethernet (rev 10) > 06:00.0 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN > Controller Copper (rev 01) > 06:00.1 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN > Controller Copper (rev 01) > 09:00.0 RAID bus controller: 3ware Inc Unknown device 1004 (rev 01) > 0b:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) > > Note that I have the same problem whit another server that embed an MSI > P35 platinum motherboard with the same RAID controller, same kernel, > same ditribution ! > > Regards > > Bruce Allen escribió: >> Could you please send some more details about your system to the list? >> The contents of /proc/devices and lsmod output would be helpful, as >> would a summary list of the hardware. >> >> Bruce >> >> >> On Sat, 18 Aug 2007, Sébastien CRAMATTE wrote: >> >>> Hello >>> >>> I'm running an Ubuntu feisty with udev and 2.6.22 kernel. >>> I've got a 3ware 9650 with 8 Seagate harddrives >>> >>> Unfortunately I can't run smartmontools >>> Might be an udev problem because /dev/tweN or /dev/twaN nodes doesn't >>> exists on my server ... >>> >>> On the smartmontools dev tell that is implemented since 5.33 and I'm >>> running 5.36 >>> >>> So I can't do >>> >>> smartctl --all --device=3ware,0 /dev/tweN ... >>> >>> Doesn't work no more with /dev/sda ... >>> >>> Thanks for your help >>> >>> >>> //san1> /c0 show >>> >>> Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache >>> AVrfy >>> ------------------------------------------------------------------------------ >>> >>> u0 RAID-50 OK - - 256K 2793.91 ON >>> OFF >>> >>> Port Status Unit Size Blocks Serial >>> --------------------------------------------------------------- >>> p0 OK u0 465.76 GB 976773168 >>> 9QG1LB6F >>> p1 OK u0 465.76 GB 976773168 >>> 9QG0Y4BH >>> p2 OK u0 465.76 GB 976773168 >>> 9QG0Z9YY >>> p3 OK u0 465.76 GB 976773168 >>> 9QG1KW4W >>> p4 OK u0 465.76 GB 976773168 >>> 9QG1N9PJ >>> p5 OK u0 465.76 GB 976773168 >>> 9QG1NAX0 >>> p6 OK u0 465.76 GB 976773168 >>> 9QG0XSH0 >>> p7 OK u0 465.76 GB 976773168 >>> 9QG1MFP9 >>> >>> Name OnlineState BBUReady Status Volt Temp Hours >>> LastCapTest >>> --------------------------------------------------------------------------- >>> >>> bbu On Yes OK OK OK 0 >>> xx-xxx-xxxx >>> >>> >>> //san1> /c0/p0 show status model serial firmware capacity >>> /c0/p0 Status = OK >>> /c0/p0 Model = ST3500630AS >>> /c0/p0 Serial = 9QG1LB6F >>> /c0/p0 Firmware Version = 3.AAK >>> /c0/p0 Capacity = 465.76 GB (976773168 Blocks) >>> >>> #dpkg -l smartmontools >>> smartmontools >>> 5.36-8 control and monitor storage >>> systems using S.M.A.R.T. >>> >>> Regards >>> >>> >>> ------------------------------------------------------------------------- >>> >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> Smartmontools-support mailing list >>> Sma...@li... >>> https://lists.sourceforge.net/lists/listinfo/smartmontools-support >>> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Andreas U. <un...@ne...> - 2007-08-19 09:07:58
|
Hi, > Andreas: can you help out? I think you reported some similar issues > at some point, but then figured out a fix. I'm not sure if the 3ware module already exports itself into sysfs, so it can be handled by udev. For now I always use 3dmd (3ware management application from 3ware.com) - it created the device nodes /dev/tw[e|a] if they not exist yet. Afterwards I can use smartmontools on this nodes. Or if you do not want to run 3dmd, u can create them manually: mknod /dev/twa0 c 254 0 mknod /dev/twa1 c 254 1 ... Cheers, Andreas |
From: Joshua D. F. <jos...@ya...> - 2007-08-21 16:28:07
|
--- Andreas Unterkircher <un...@ne...> wrote: > I'm not sure if the 3ware module already exports itself into sysfs, > so it can be handled by udev. For what it's worth, I investigated a similar issue where SELinux prevented either 3dmd or smartctl from the creating the /dev/tw* devices. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232218#c10 Summary: some thought registering the 3ware driver with sysfs might be the way to go, but Adam Radford (the 3ware kernel module maintainer) indicated he'd rather not add a possibly changing interface to the module code unless it was absolutely necessary. IMHO it's not. There are only 2 tools that use the device: smartd/smartctl and 3dmd/tw_cli. Meanwhile Dan Walsh already fixed the SELinux reference policy: http://oss.tresys.com/projects/refpolicy/changeset/2246 The change is in Fedora 7 and the upcoming RHEL updates. In an unrelated note, smartd or smartctl creates and stats 16 special 3ware devices /dev/twe[0-15] whether or not they actually exist (/dev/twe0 for the first card, /dev/twe1 the second, etc.). Would it be possible to only create devices for cards that are really there? ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ |
From: Bruce A. <ba...@gr...> - 2007-08-24 12:43:28
|
Hi Joshua, Thanks for your note. It sounds to me as if SELinux is preventing smartd/smartctl from creating the device nodes, as the bugzilla report referenced below: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232218#c10 Is there code that I can add to the smartmontools function setup_3ware_nodes() which will 'set the context' for SELinux? The goal is that a stock user on a stock SELinux system can run smartd/smartctl and have them operate correctly, with no special action needed on their part. (Alternatively, they should at least get a very clear error message telling them what action is needed to make smartctl/smartd work!) I don't know anything about SELinux apart from the most general things, so I would need a code fragment or at least some good code-level documentation to do this. Cheers, Bruce On Tue, 21 Aug 2007, Joshua Daniel Franklin wrote: > --- Andreas Unterkircher <un...@ne...> wrote: >> I'm not sure if the 3ware module already exports itself into sysfs, >> so it can be handled by udev. > > For what it's worth, I investigated a similar issue where > SELinux prevented either 3dmd or smartctl from the creating the > /dev/tw* devices. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232218#c10 > > > Summary: some thought registering the 3ware driver with sysfs > might be the way to go, but Adam Radford (the 3ware kernel > module maintainer) indicated he'd rather not add a possibly > changing interface to the module code unless it was absolutely > necessary. IMHO it's not. There are only 2 tools that use > the device: smartd/smartctl and 3dmd/tw_cli. > > Meanwhile Dan Walsh already fixed the SELinux reference policy: > http://oss.tresys.com/projects/refpolicy/changeset/2246 > The change is in Fedora 7 and the upcoming RHEL updates. > > In an unrelated note, smartd or smartctl creates and > stats 16 special 3ware devices /dev/twe[0-15] whether > or not they actually exist (/dev/twe0 for the first > card, /dev/twe1 the second, etc.). Would it be > possible to only create devices for cards that are > really there? > > > > ____________________________________________________________________________________Ready for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Bruno W. I. <br...@wo...> - 2007-08-26 17:50:03
|
On Fri, Aug 24, 2007 at 07:43:24 -0500, Bruce Allen <ba...@gr...> wrote: > > Is there code that I can add to the smartmontools function > setup_3ware_nodes() which will 'set the context' for SELinux? The goal is > that a stock user on a stock SELinux system can run smartd/smartctl and > have them operate correctly, with no special action needed on their part. This doesn't sound like the right approach. I would expect device nodes to be created by udev using rules definitions not by an application like smartd. On the selinux side, things would be done differently. An application like smartd wouldn't be allowed to change its own context directly. Instead if it needed to be able to create files in /dev it (the context it runs with) would be given that ability. If it wanted to only have the ability early on (with respect to selinux limitaions), then it would start by running a privileged executable and fork a less privileged one to continue. |
From: Bruce A. <ba...@gr...> - 2007-08-26 20:44:06
|
Hi Bruno, >> Is there code that I can add to the smartmontools function >> setup_3ware_nodes() which will 'set the context' for SELinux? The goal >> is that a stock user on a stock SELinux system can run smartd/smartctl >> and have them operate correctly, with no special action needed on their >> part. > > This doesn't sound like the right approach. I would expect device nodes > to be created by udev using rules definitions not by an application like > smartd. If the device nodes do not already exist with the correct major/minor device numbers, then smartd (already!) creates them. Of course if the nodes already exist because something else like udev has created them, then smartd does nothing. > On the selinux side, things would be done differently. An application > like smartd wouldn't be allowed to change its own context directly. > Instead if it needed to be able to create files in /dev it (the context > it runs with) would be given that ability. If it wanted to only have the > ability early on (with respect to selinux limitaions), then it would > start by running a privileged executable and fork a less privileged one > to continue. I don't know enough about SELinux, udev and dev to understand how to proceed based on your comments above. I would be happy to 'do nothing' but am concerned that more users may run into the problem reported to the support list. How do you suggest that I address the problem that has been reported? Should I do nothing? Cheers, Bruce |
From: Bruno W. I. <br...@wo...> - 2007-08-26 21:11:17
|
On Sun, Aug 26, 2007 at 15:44:00 -0500, Bruce Allen <ba...@gr...> wrote: > > If the device nodes do not already exist with the correct major/minor > device numbers, then smartd (already!) creates them. Of course if the > nodes already exist because something else like udev has created them, > then smartd does nothing. I don't think smartd should be creating files in /dev (at least on Fedora). > I don't know enough about SELinux, udev and dev to understand how to > proceed based on your comments above. I would be happy to 'do nothing' > but am concerned that more users may run into the problem reported to the > support list. How do you suggest that I address the problem that has been > reported? Should I do nothing? I don't think the selinux policies should be changed. I think what needs to happen is that rules should be created to create the necessary nodes when the hardware is detected. I think any such rules would then get submitted to be part of the udev package. There are some rules that are specific to other things besides udev, but I think they typically get access to things rather than create them. I don't know enough about writing rules to write one for this purpose. I think a reasonable step is to open a Fedora bugzilla entry describing the issue with nodes not being created for the device, under udev and see what the maintainer suggests. In case it is a matter of there being some new hardware ids that need to get added to an existing list, it might help to have the hardware ids handy. |
From: Joshua D. F. <jos...@ya...> - 2007-08-27 05:56:11
|
--- Bruno Wolff III wrote: > I don't think the selinux policies should be changed. Did you read the bugzilla link I sent earlier? http://bugzilla.redhat.com/show_bug.cgi?id=232218 Dan Walsh, the Red Hat SELinux maintainer, added an entry to the reference policy at modules/kernel/storage.fc for "/dev/tw[a-z][^/]+" on 2007 March 26: http://oss.tresys.com/projects/refpolicy/changeset/2246 It's in Fedora 7 selinux-policy-2.6.4-25.fc7 It's fine if you want to contact the 3ware kernel driver maintainer with a current sysfs/udev patch, but this is not an issue with current Fedora anymore. ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 |
From: Bruce A. <ba...@gr...> - 2007-08-27 08:21:01
|
Hi Joshua, I don't know if Bruno has read the Bugzilla thread, but I certainly have. As the person in charge of the smartmontools project, I'm still trying to understand if I need to do something (meaning: make a change to the smartmontools code and/or documentation). Please help me to sort this out. Is the following correct? (1) For current Redhat/Fedora users with FC6 or earlier, there are SELinux conflicts with smartd that must be resolved by individual users. In particular, both smartd and smartctl are forbidden from creating the /dev/twa? and /dev/twe? character devices that they need. (2) In Redhat/Fedora FC7 and later, the problem has been fixed, because the SELinux policy permits smartd/smartctl the access that they need. If both (1) and (2) are correct, then I have further questions. (A) In the case of (1), can the problem in FC6 and earlier be fixed with a modification of the smartd/smartctl code that creates the /dev/tw[ae]? device nodes? If so, could you point me to a code fragment that would do this? (B) What about other distributions (Debian, for example)? Does this same problem arise? Is there something that needs to be fixed or changed within the smartmontools package? Cheers, Bruce On Sun, 26 Aug 2007, Joshua Daniel Franklin wrote: > --- Bruno Wolff III wrote: >> I don't think the selinux policies should be changed. > > Did you read the bugzilla link I sent earlier? > http://bugzilla.redhat.com/show_bug.cgi?id=232218 > Dan Walsh, the Red Hat SELinux maintainer, added an > entry to the reference policy at modules/kernel/storage.fc > for "/dev/tw[a-z][^/]+" on 2007 March 26: > http://oss.tresys.com/projects/refpolicy/changeset/2246 > It's in Fedora 7 selinux-policy-2.6.4-25.fc7 > > It's fine if you want to contact the 3ware kernel driver > maintainer with a current sysfs/udev patch, but this is > not an issue with current Fedora anymore. > > > > ____________________________________________________________________________________ > Sick sense of humor? Visit Yahoo! TV's > Comedy with an Edge to see what's on, when. > http://tv.yahoo.com/collections/222 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Joshua D. F. <jos...@ya...> - 2007-08-27 21:51:57
|
--- Bruce Allen wrote: > SELinux > conflicts with smartd that must be resolved by individual users. In > particular, both smartd and smartctl are forbidden from creating the > /dev/twa? and /dev/twe? character devices that they need. Unfortunately this seems to be the case with all SELinux users, I was incorrect about a workaround. I'm afraid I'm not familiar with what selinux functions in smartd would fix it, but this shell code does (smartctl creates the devices, chcon allows access): /etc/init.d/smartd stop smartctl -d 3ware,0 /dev/twe0 for i in /dev/tw*; do chcon -t fixed_disk_device_t $i; done /etc/init.d/smartd start smartctl is allowed to create the devices because it's not running as a daemon, but they are not created with the correct selinux context. Once that's corrected smartd runs fine. I think that should work on any distro, but for sure it does on RHEL and Fedora. I just found some selinux code in the joe sources: http://google.com/codesearch?hl=en&q=+match_default_security_context+show:0i4klcg3GiQ:4bg7prtaJh4:z1Oz7vI3kac&sa=N&cd=1&ct=rc&cs_p=http://ftp.osuosl.org/pub/nslu2/sources/joe-3.5.tar.gz&cs_f=joe-3.5/selinux.c#a0 http://ftp.osuosl.org/pub/nslu2/sources/joe-3.5.tar.gz Not sure how simple it is, it didn't compile OOTB for me. ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz |
From: Bruno W. I. <br...@wo...> - 2007-08-27 16:02:06
|
On Sun, Aug 26, 2007 at 22:56:01 -0700, Joshua Daniel Franklin <jos...@ya...> wrote: > --- Bruno Wolff III wrote: > > I don't think the selinux policies should be changed. > > Did you read the bugzilla link I sent earlier? > http://bugzilla.redhat.com/show_bug.cgi?id=232218 No I hadn't. While it does indicate that something was fixed in F7, it isn't clear to me that the files are being created there. It looks as if udev might relabel them if they do already, but I am not sure if it will do that if smartd creates the files without doing a reboot. I did a mknod to create /dev/twa0 on F7 as a character device and it got labelled as device_t rather than fixed_disk_device_t. But I don't have the hardware in question, so that maybe udev would do something different if I did. restorecon correctly relabels the file. > Dan Walsh, the Red Hat SELinux maintainer, added an > entry to the reference policy at modules/kernel/storage.fc > for "/dev/tw[a-z][^/]+" on 2007 March 26: > http://oss.tresys.com/projects/refpolicy/changeset/2246 > It's in Fedora 7 selinux-policy-2.6.4-25.fc7 That will cover relabelling (with restorecon) but it will not make sure that the files are correctly labelled when created by smartd, by default. By default files are created with a context based on the context of the process creating them and the process of the directory they are being created in. The content of file_contexts doesn't govern this. Programs can also explicitly set the context to be used for newly created files. This is what smartd will need to do if it creates the files. > It's fine if you want to contact the 3ware kernel driver > maintainer with a current sysfs/udev patch, but this is > not an issue with current Fedora anymore. Well I disagree (IMO smartd is not the right place to be creating devices), but I don't have much of a stake in this and the bug is still open so that it might get fixed correctly at some point. If smartd is going to create the files then I think smartd is also going to need to call setfscreatecon to change the context of newly created files. Doing this should be tested to make sure that policy (targeted, strict and mls should each be tested) doesn't block either the creation or using the fixed_disk_device_t label on the newly created file. |
From: Joshua D. F. <jos...@ya...> - 2007-08-27 21:25:44
|
Thanks for the comments, Bruno, I had an incorrect understanding of what selinux was doing. --- Bruno Wolff III wrote: > I did a mknod to create /dev/twa0 on F7 as a character device and it > labelled as device_t rather than fixed_disk_device_t. I'm afraid this is the case with my test hardware (RHEL5 with the prerelease selinux-policy-2.4.6-83.el5). I must have already created the device nodes before I installed the updated policy and relabelled. I did not realize that the policy would not be applied at file creation time. Maybe the best option is to push sysfs code into the 3ware driver, but it seems strange to add kernel code and clutter up /dev/ with tw* devices that only smartd needs. ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC |
From: Bruno W. I. <br...@wo...> - 2007-08-27 21:37:11
|
On Mon, Aug 27, 2007 at 14:25:29 -0700, Joshua Daniel Franklin <jos...@ya...> wrote: > Thanks for the comments, Bruno, I had an incorrect understanding > of what selinux was doing. > > --- Bruno Wolff III wrote: > > I did a mknod to create /dev/twa0 on F7 as a character device and it > > labelled as device_t rather than fixed_disk_device_t. > > I'm afraid this is the case with my test hardware (RHEL5 with > the prerelease selinux-policy-2.4.6-83.el5). I must have > already created the device nodes before I installed the > updated policy and relabelled. I did not realize that the > policy would not be applied at file creation time. I think it is better to think of file_contexts data as being outside of policy. It tells you what files are intended to be labelled as, but doesn't enforce that. The policy can enforce labelling; but when there are several possible labels allowed for files in a directory created by the same application (or multiple applications running with the same context), then the application needs to use the correct one. There is a function that applications can call to return the expected label of a path, that can help with this. > Maybe the best option is to push sysfs code into the 3ware driver, > but it seems strange to add kernel code and clutter up /dev/ with > tw* devices that only smartd needs. But potentially other things besides smartd could want to communicate with the device via those devices, so it doesn't seem that odd to me. For me, having an application create devices for hardware seems wrong. |
From: <s.c...@wa...> - 2007-08-19 08:57:01
|
Now it seems thats works ... smartctrl create /dev/twa0 on the fly ... but still doesn't appear in /dev ... I supose that is normal! The most important is that now I can get smart values ! Thanks for the help Regards Andreas Unterkircher escribió: > Hi, > >> Andreas: can you help out? I think you reported some similar issues >> at some point, but then figured out a fix. >> > I'm not sure if the 3ware module already exports itself into sysfs, so > it can > be handled by udev. For now I always use 3dmd (3ware management > application from 3ware.com) - it created the device nodes /dev/tw[e|a] if > they not exist yet. Afterwards I can use smartmontools on this nodes. > > Or if you do not want to run 3dmd, u can create them manually: > > mknod /dev/twa0 c 254 0 > mknod /dev/twa1 c 254 1 > ... > > Cheers, > Andreas > > > > |
From: Bruce A. <ba...@gr...> - 2007-08-20 10:26:15
|
Sébastien, It would help me if you could: (1) Clearly state the problem. (2) Clearly state the solution. I can then try to modify the smartd and/or smartctl code to automatically take care of (2). Cheers, Bruce On Sun, 19 Aug 2007, Sébastien CRAMATTE wrote: > Now it seems thats works ... > smartctrl create /dev/twa0 on the fly ... but still doesn't appear in > /dev ... I supose that is normal! > > The most important is that now I can get smart values ! > Thanks for the help > > Regards > > Andreas Unterkircher escribió: >> Hi, >> >>> Andreas: can you help out? I think you reported some similar issues >>> at some point, but then figured out a fix. >>> >> I'm not sure if the 3ware module already exports itself into sysfs, so >> it can >> be handled by udev. For now I always use 3dmd (3ware management >> application from 3ware.com) - it created the device nodes /dev/tw[e|a] if >> they not exist yet. Afterwards I can use smartmontools on this nodes. >> >> Or if you do not want to run 3dmd, u can create them manually: >> >> mknod /dev/twa0 c 254 0 >> mknod /dev/twa1 c 254 1 >> ... >> >> Cheers, >> Andreas >> >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |