fstrim-all weekly cron generate noise when hdparm isn't installed or on a VM; noisy in VMs

Status changed to 'Confirmed' because the bug affects multiple users.

My complaint is similar to the original reporter, but not the same. I'm happy to split this into a separate ticket if needs be, but I thought that keeping them together was appropriate.

I have a VM running on Amazon, and every week I get this mail from fstrim's cron:

/etc/cron.weekly/fstrim:
HDIO_DRIVE_CMD(identify) failed: Invalid argument
device /dev/disk/by-label/cloudimg-rootfs is not an Intel or Samsung drive
HDIO_DRIVE_CMD(identify) failed: Invalid argument
device /dev/xvdb is not an Intel or Samsung drive

hdparm: 9.43-1ubuntu3
util-linux: 2.20.1-5.1ubuntu14

For comment above:

# lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04

In a VM with virtio disks, I get this:
# fstrim-all
 HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
device /dev/disk/by-uuid/476e58d4-383c-4885-a988-fc96a79add14 is not a drive that is known-safe for trimming
 HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
device /dev/vdc1 is not a drive that is known-safe for trimming

For those finding this bug via Google, editing /etc/cron.weekly/fstrim was enough to suppress the errors I saw:
exec fstrim-all 2> /dev/null | grep -v 'is not a drive that is known-safe'

Alternatively, just commenting out that line to disable the whole thing would work too.

This bug was fixed in the package util-linux - 2.20.1-5.1ubuntu17

---------------
util-linux (2.20.1-5.1ubuntu17) trusty; urgency=medium

  * debian/fstrim-all: Disable echo statements, they are leftovers from
    debugging. (Part of LP #1293152)
  * debian/fstrim-all: Quiesce error message if hdparm fails (such as in VMs).
    (LP: #1293152)
 -- Martin Pitt <email address hidden> Tue, 18 Mar 2014 17:05:01 +0100

Unless I'm missing something, I don't think the fix here was fully successful. In the case of a VMware VM running 14.04, hdparm spits out a sense data error on stderr:

# hdparm -I /dev/sda1 1>/dev/null
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, fstrim-all also spits this out on stderr which then gets sent to root's mail by cron.weekly:

# /sbin/fstrim-all 1>/dev/null
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

It looks like the intent was to have the stderr of hdparm piped to /dev/null, but this isn't inside the backticks in the fstrim-all script. To fix this, I think we just need the attached trivial patch.

This is mostly just an annoyance, but it would be nice to get fixed. If it makes more sense to open this as a new bug, let me know.

Eek, indeed. Thanks Matthew for spotting this! I suppose we should also fix this for 14.04, would you be able to test a proposed update? (I can't self-verify)

Fix uploaded to utopic and trusty SRU review queue.

The attachment "fstrim-all.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug was fixed in the package util-linux - 2.20.1-5.1ubuntu21

---------------
util-linux (2.20.1-5.1ubuntu21) utopic; urgency=medium

  * fstrim-all: Fix typo that made unwanted stderr output from hdparm appear.
    Thanks to Matthew L. Dailey! (LP: #1293152)
 -- Martin Pitt <email address hidden> Mon, 02 Jun 2014 13:36:20 +0200

I'm happy to do testing - we have several trusty installs on VMs that I can use. Should I wait until this is in trusty-proposed, or just test the package from utopic?

Matthew L. Dailey [2014-06-02 13:02 -0000]:
> I'm happy to do testing - we have several trusty installs on VMs that I
> can use. Should I wait until this is in trusty-proposed, or just test
> the package from utopic?

They are the same source package really, but for formal reasons (and
to be double-sure), testing the trusty-proposed package (once it gets
accepted) would be appreciated. Thanks!

Hello Simon, or anyone else affected,

Accepted util-linux into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/util-linux/2.20.1-5.1ubuntu20.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have tested util-linux 2.20.1-5.1ubuntu20.1 on two systems that were exhibiting symptoms of this bug and can verify that it is fixed in this version. I'll add the verification-done tag to this bug.

Details are below - let me know if anything else is needed.

On Dell M610 (mirrored drives on a CERC6i):

# lsb_release -rd
Description: Ubuntu 14.04 LTS
Release: 14.04

Prior to upgrade:
# /sbin/fstrim-all
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0b 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

# apt-cache policy util-linux
util-linux:
  Installed: 2.20.1-5.1ubuntu20
  Candidate: 2.20.1-5.1ubuntu20
  Version table:
 *** 2.20.1-5.1ubuntu20 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

After upgrading:
# /sbin/fstrim-all
(no output)

# apt-cache policy util-linux
util-linux:
  Installed: 2.20.1-5.1ubuntu20.1
  Candidate: 2.20.1-5.1ubuntu20.1
  Version table:
 *** 2.20.1-5.1ubuntu20.1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.20.1-5.1ubuntu20 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

On VMware ESXi 5.5:

# lsb_release -rd
Description: Ubuntu 14.04 LTS
Release: 14.04

Prior to upgrade:
# /sbin/fstrim-all
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

# apt-cache policy util-linux
util-linux:
  Installed: 2.20.1-5.1ubuntu20
  Candidate: 2.20.1-5.1ubuntu20
  Version table:
 *** 2.20.1-5.1ubuntu20 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

After upgrading:
# /sbin/fstrim-all
(no output)

# apt-cache policy util-linux
util-linux:
  Installed: 2.20.1-5.1ubuntu20.1
  Candidate: 2.20.1-5.1ubuntu20.1
  Version table:
 *** 2.20.1-5.1ubuntu20.1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.20.1-5.1ubuntu20 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

Thanks Matthew!

This bug was fixed in the package util-linux - 2.20.1-5.1ubuntu20.1

---------------
util-linux (2.20.1-5.1ubuntu20.1) trusty-proposed; urgency=medium

  * fstrim-all: Fix typo that made unwanted stderr output from hdparm appear.
    Thanks to Matthew L. Dailey! (LP: #1293152)
 -- Martin Pitt <email address hidden> Mon, 02 Jun 2014 13:36:20 +0200

The verification of the Stable Release Update for util-linux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.