Custom Query (993 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 993)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#38 fixed SMART errors upon resuming from suspend Christian Franke Giuseppe Iuculano
Description

Hi,

I'm forwarding a bug reported by a Debian user. Version: smartctl 5.39 2009-12-09 r2995 [i686-pc-linux-gnu] (local build)

upon resuming from suspend to ram (iirc, it does not affect suspend to disk, but i would not bet now), smartd logs+mails various messages:

info smartd[1625]: Device: /dev/hda, not capable of SMART self-check crit smartd[1625]: Device: /dev/hda, failed to read SMART Attribute Data info smartd[1625]: Device: /dev/hda, Read SMART Self Test Log Failed info smartd[1625]: Device: /dev/hda, Read SMART Error Log Failed

after /etc/init.d/smartmontools restart, everything seems just fine.

#39 fixed Silent "failure" without -parameters Christian Franke Giuseppe Iuculano
Description

Hi,

I'm forwarding a bug reported by a Debian user. Version: smartctl 5.39 2009-12-09 r2995 [i686-pc-linux-gnu] (local build)

This was my first time running smartctl. Without parameters it reported helpfully that I need a device name. When running "smartctl /dev/sda" it printed copyright notice and a home directory URL and no errors or anything useful. I thought for a while it might be broken.

I suggest using -H or -a as the default output when no parameters are given. Or at least an error message that some parameter is needed.

#40 fixed smartctl --test when a test is already running causes it to abort Christian Franke Giuseppe Iuculano
Description

Hi,

I'm forwarding a bug reported by a Debian user.

smartctl can be used to execute a test on a drive already running another test. In my case, I ran a short test on a drive already running a long test. I was not aware that SMART could only handle 1 test at a time. Apparently, SMART can't resume aborted tests.

smartctl's behavior in this case seems to be to execute the newly requested test without caring about the already one. The worst problem with this is loss of time, as in my scenario. I see two options: running the newly requested test after the currently running one is finished, or prompt for what to do.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.