Bug 179408 - Smartd fails on startup (default config fails)
Summary: Smartd fails on startup (default config fails)
Alias: None
Product: Fedora
Classification: Fedora
Component: smartmontools
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-31 00:56 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-03-22 17:42:44 UTC

Attachments (Terms of Use)

Description Ivan Gyurdiev 2006-01-31 00:56:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060126 Fedora/1.5-5 Firefox/1.5

Description of problem:
Smartd's default config appears to assume disks hda and hdb are installed.
This is incorrect on my machine - I have disks hda and sda. There seems to be an option to scan devices, but it's not enabled in my config file. 

I think the default config file for an init service should work out of the box. 
The current config fails, which is a bug. It also doesn't report why it failed, which is another bug. I have to force the daemon to run in the foreground to find out why it failed.

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

How reproducible:

Steps to Reproduce:
1. Install one PATA and one SATA disk.
2. Run smartd on startup

Additional info:

Comment 1 Tomas Mraz 2006-01-31 07:35:03 UTC
Is it possible that you had hda and hdb disks on your machine when your system
was first booted after installation?

In the first start of the smartd there is no smartd.conf file and it's generated
by smartd-conf.py script. You can try to remove smartd.conf and restart smartd a
correct smartd.conf should be generated.

Comment 2 Ivan Gyurdiev 2006-01-31 07:42:03 UTC
Yes, it is possible - I did have hda/hdb, and that's no longer true... 
I think Linux should be able to handle changes in the underlying hardware.

Comment 3 Tomas Mraz 2006-03-22 17:42:44 UTC
The current smartd configuration in rawhide should make smartd not fail if some
drive is no longer connected. So it's now partially fixed. To make smartd handle
all changes in underlying hardware would require non-trivial improvements of its
code. That should be requested upstream.

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