Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am asking this question here in the hope that some Linux-kernel guru can have an answer. This question has been asked on AskUbuntu and on SuperUser without answers: thinking better, it is really Linux-kernel specific, so I think its natural place is on this forum.

I have a Samsung laptop (Chronos s7) with one SATA hard disk on bus ata:1, which is detected as /dev/sda, an 8G SSD on ata:2, /dev/sdb, and various other devices on the rest of SATA interface.

The problem is that the SSD disk is

  • soldered to the main board (unmovable)
  • busted (it just gives I/O errors for any operation)
  • it does not appear in the bios (probably because it is broken)

Now this disk:

  • delays the boot three to five minutes trying to probe the failing disk, which is annoying;
  • but the most annoying thing is that the system fails to suspend due to /dev/sdb failing.

Notice that I can live with the delay at boot --- what worries me is the resume/suspend thing.

So the question is: can I tell the kernel to avoid even probing the device on ata:2?

In older kernel (<3.0), when I was still able to dig a bit into the source, there was a command-line parameter of the style hdb=ignore that would have done the trick.

I have tried all the tricks proposed below with udev and libata:force kernel parameters, to no avail. Specifically, the following does not work:

  1. Adding to one of the following /etc/udev/rules.d/ a file (in early execution like 00-ignoredisk.rules or in late as 99-ignoredisk.rules or in both places)

    SUBSYSTEMS=="scsi", DRIVERS=="sd", ATTRS{rev}=="SSD ", ATTRS{model}=="SanDisk iSSD P4 ", ENV{UDISKS_IGNORE}="1" 



    nor a lot of intermediate solutions --- this makes the disk not accessible after boot, but it is probed at boot, and still checked when suspending --- causing the suspend to fail.

  2. Editing the system files /lib/udev/rules.d/60-persistent-storage.rules (and udisks, udisks2) changing

    KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end"


    KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md|sdb*", GOTO="persistent_storage_end"

    again, this has some effect, masking the disk from userspace, but the disk is still visible to the kernel.

  3. Booting with all the possible combinations (well, a lot of them) of the libata:force parameters (found for example here) in order to disable DMA, lower speed or whatever about the failing disk --- does not work. The parameter is used, but the disk is still probed and fails.

    Full udevadm info -a -n /dev/sdb pasted to http://paste.ubuntu.com/6186145/

    smartctl -i /dev/sdb -T permissive gives:

    root@samsung-romano:/home/romano# smartctl -i /dev/sdb -T permissive
    smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.8.0-31-generic] (local build)
    Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net
    Vendor:               /1:0:0:0
    User Capacity:        600,332,565,813,390,450 bytes [600 PB]
    Logical block size:   774843950 bytes
    >> Terminate command early due to bad response to IEC mode page

    which is clearly wrong. Nevertheless:

    root@samsung-romano:/home/romano# fdisk -b 512 -C 970 -H 256 -S 63 /dev/sdb
    fdisk: unable to read /dev/sdb: Input/output error

(SSD data from http://ubuntuforums.org/showthread.php?t=1935699&p=11739579#post11739579 ).

share|improve this question
Sorry if this is too obvious, but since you have not included in your question: have you made sure the device name or UUID is not listed in /etc/fstab? Because the delay on boot could be caused earlier by the kernel or udev, which seems to be the case, but also later by fsck, when reading fstab. – Teresa e Junior Nov 26 '13 at 18:10
Yes, there is no mention of /dev/sdb (or its partitions) in system files. The delay is even before init starts... it is in a kthread (because the boot continues in parallel), but it's at a more fundamental level. But really the boot delay is the lesser of the problem --- if only I could ignore the disk during suspend/resume so that suspend works I will be happy. (thanks anyway). – Rmano Nov 26 '13 at 18:21
Are you using in initrd? if so whose? – hildred Nov 26 '13 at 19:04
@hildred: I am using stock kernel and initramfs from Ubuntu 13.04. I can disable AHCI or all SATA there, but then my system is dead --- no disks at all. – Rmano Nov 26 '13 at 19:06
Debian (and Umbutu) compile the ata subsystem as module. Have you tried setting parameters to the module when it is loaded by the initrd? – hildred Nov 26 '13 at 19:10
up vote 16 down vote accepted

libata does not have a noprobe option at all; that was a legacy IDE option...

But I went and wrote a kernel patch for you that implements it. It Should apply to many kernels very easily (the line above it was added 2013-05-21/v3.10-rc1*, but can be safely applied manually without that line).

Update The patch is now upstream (at least in 3.12.7 stable kernel). It is in the standard kernel distributed with Ubuntu 14.04 (which is based on 3.13-stable).

Once the patch is installed, adding


to the kernel boot parameters will hide the disk from the Linux kernel. Double check that the number is correct; searching for the device name can help (obviously, you have to check the kernel messages before adding the boot parameters):

(0)samsung-romano:~% dmesg | grep iSSD
[    1.493279] ata2.00: ATA-8: SanDisk iSSD P4 8GB, SSD 9.14, max UDMA/133
[    1.494236] scsi 1:0:0:0: Direct-Access     ATA      SanDisk iSSD P4  SSD  PQ: 0 ANSI: 5

The important number is the ata2.00 in the first line above.

share|improve this answer
Thanks a lot. I will try to check it as soon as I can remember how to compile and install a kernel on my Ubuntu. Unfortunately, I'll have a very complex week forward... – Rmano Dec 9 '13 at 2:52
+1 It's clearly better than the trick I posted. I hope it will becomes official. – Emmanuel Dec 9 '13 at 7:41
Ok, tested the patch. It works. If you need to push it upstream I can add my Tested-by: to the patch --- you have my true email in my profile. I installed it following (with quirks) the instructions in wiki.ubuntu.com/Kernel/BuildYourOwnKernel. – Rmano Dec 14 '13 at 21:18
@illuminÉ --- just edited the answer in that sense --- wait for it to be approved. – Rmano Jun 16 '14 at 15:40
Another Reason to LOVE GENTOO!! – eyoung100 Jun 16 '14 at 18:11

Hardware problems have physical hardware solution. Did you consider to unsolder or cut the power supply of the drive ?

EDIT: Ok if thats not an option people are using this before to hot-plug a hard drive. You could use that to disable your drive.

echo 1 > /sys/block/sdb/device/delete

Note that any other process can force a scan of the SATA bus, and then makes it to be back. Try to do that just before hibernating the laptop.

Edited by OP: it worked. I added the following file :

-rwxr-xr-x 1 root root 204 Dec  6 16:03 99_delete_sdb

with content:


# Tell grub that resume was successful

case "$1" in
        if [ -d /sys/block/sdb ]; then
            echo Deleting device sdb 
            echo 1 > /sys/block/sdb/device/delete       

...and now the system suspends (and resume) correctly.

share|improve this answer
If only it were true. I can't even say which chip (or chips) are the SSD drive --- most are unmarked. And unpowering a chip is not safe --- what about undriven three-state pins? I opened the laptop hoping that the SSD drive was connected on some sort of daughterboard. No luck. (And besides, most of the difficulty in writing kernel drivers is to work around bad designed hw). – Rmano Dec 5 '13 at 0:34
@Rmano How does perform the "delete" trick ? – Emmanuel Dec 6 '13 at 10:29
IT WORKS --- I can suspend after the "delete" trick. Thanks a lot. (It still delays the boot, but well --- not a problem). – Rmano Dec 6 '13 at 22:05
Thanks a lot for reminding about delete. – Michael Shigorin Nov 14 '14 at 15:05


Does this device not show up in any type of way via your BIOS?

Often times HDDs are configured in an "auto" mode, I would go through and make sure that these devices are in a disabled state and even go to the extent of explicitly enabling only the one HDD and disabling everything else.

Kernel Boot Options

Often times you can disable various subsystems from being auto-detected by the booting Linux Kernel through the use of different boot options that can be passed to it as switches.

Most if not all of the options are listed here:

Linux in a Nutshell book

You might want to skim through the O'Reilly book, Linux Kernel in a Nutshell, specifically, Chapter 7: Customizing a Kernel.

This book is made available for free by its author, Greg Kroah-Hartman, on his personal website. The entire book can be downloaded as well.

share|improve this answer
No, the BIOS does not have any trace of this disk; I can see the HDD and the DVD and no more. Before failing, in Windows (now there is no windows anymore in the system) it was used as a speed-up cache for the main disk. I tried to set the AHCI mode to legacy, off, yes or auto (for all disks) but that did not change anything or (for off) simply made the system not boot. – Rmano Nov 26 '13 at 19:17
The other method I've used in the past is when the Kernel is booting to tell it via Grub (kernel boot options) to noide=..... There are host of other options you can provide to the booting kernel to disable auto-detection of hardware. – slm Nov 26 '13 at 19:20
the disk is SATA (scsi), no IDE. And the hdb=noprobe options has not passed muster to scsi (I think it was eliminated around 2.6.x), so it does not exists (as soon as I know) a sdb=noprobe or ata:2=noprobe option. I have read (almost) all the kernel-parameters.txt file in the kernel source and I can't find the correct parameter. If you know anyone, please tell it in an answer --- I will be really grateful. – Rmano Nov 26 '13 at 19:24
@Rmano - I'll have to dig more to find it, I do remember several options related to HDD and bus detection, but not off the top of my head. – slm Nov 26 '13 at 19:59
@Rmano - what about the option: libata.dma= – slm Nov 26 '13 at 20:18

Linux way to check for lock: sudo hdparm -I /dev/sdX (with X = a..z ; you must know what device your drive is, of course). At the end of the (big) output, you MUST be able to read at in the last 10 lines: *not* locked.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.