How can I tell linux kernel to completely ignore a disk as if it was not even connected?

Question

Notice

Please scroll down for the answer (it has few points but it is the correct one). The problem is solved by a patch that will be in kernel 3.12.7 and up; I hope it will back-ported to earlier ones, too.

My laptop is a Samsung Chronos serie s 7. Ubuntu Gnome Remix 13.04, with Intel updated drivers.

I have a problem with the internal SSD drive (8G capacity). It fails with COMRESET and input/output errors. I am quite convinced that the problem is hardware; unfortunately I do not have Windows installed in the laptop to check if it's a matter of SSD configuration or whatever.

The problem is that the disk is recognized by udev:

KERNEL[9.515930] add      /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb (block)
ACTION=add
DEVNAME=sdb
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb
DEVTYPE=disk
MAJOR=8
MINOR=16
SEQNUM=1785
SUBSYSTEM=block
UDEV_LOG=3

and after that it fails in a lot of checks, delaying boot, delaying shutdown, and making (I think) suspend impossible.

Is it possible to tell Linux to completely ignore anything on the ata2 link? I tried adding this line to /etc/udev/rules.d/10-local.rules

SUBSYSTEMS=="pci"  DRIVERS=="ahci" KERNELS=="ata2" OPTIONS=="ignore_device"

but it doesn't work.

On the other hand, if anyone knows how to reset the SSD if it was left in "cache" mode without using Windows... or to boot a "live" windows to do the same...

Thanks!

Data added:

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
Product:              
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 ).

ADDITIONAL THOUGHT:

Could all this being a side effect of the Intel Smart Response Technology not being disabled before installing Linux? If yes, how can I check it short of reinstalling a windows on the machine? Or this is a shot in the dark? (In the bios the SSD drive doesn't show and there is nothing about Intel SRT).

ABOUT MARKING AS DUPLICATE:

I changed the title of the question; I do not think that the linked question answers my problem. I positively know that the SSD is failing. I am asking if it's possible to tell the linux kernel to not probe for it at all.

You may find an answer in this question: http://askubuntu.com/questions/325283/how-do-i-check-the-health-of-a-ssd — s3lph, Oct 02 '13 at 20:02
If the disk you want to hide is "sdb", could you please post the complete output of "udevadm info -a -n /dev/sdb"?. — Roman Raguet, Oct 02 '13 at 20:29
I added the requested data. I opened the laptop to try to physically get rid of it, but it seems to me that it's soldered to the mainboard. And smartctl gives funny results, while fdisk simply gives i/o errors. — Rmano, Oct 03 '13 at 00:24
This is no duplicate of the linked question, at all. Could you please unmark it as a duplicate? I changed the title to better convey the question. Is not about an SSD check, is about a general question on disk management on Linux. Thanks! — Rmano, Oct 04 '13 at 14:35
Similar question on Super User: How to disable kernel probing for drive? — ændrük, Oct 04 '13 at 19:55
æendrük: gotcha. Exactly the same problem. And it seems it's without solutions... disabling sata will disable all my disks. — Rmano, Oct 04 '13 at 20:49

score 22 · Accepted Answer · edited Jun 12 '20 at 14:37

Two solutions here: one is fast to apply, although solves the problem only partially, the other one is the complete one but requires you to compile your own kernel.

The correct answer is a kernel patch.

Robin H. Johnson wrote a patch for the SATA kernel driver (find it in Unix/Linux stack exchange site) which hides completely the drive.

Update 1 The patch is now upstream (at least in 3.12.7 stable kernel), see the git repository. I asked for backport in the Ubuntu launchpad.

Update 2 The patch is in the standard kernel for Ubuntu Trusty Thar 14.04; so now only the following addition to boot parameter is needed.

Once the patch is installed, adding

 libata.force=2.00:disable

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:

(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

To add a kernel parameter (bot temporarily and permanently) you can check this Q&A: How do I add a kernel boot parameter?

Workaround

At least the problem of enabling suspend-resume has been solved by by Unix StackExchange user Emmanuel in https://unix.stackexchange.com/a/103742/52205. As root, issue the command:

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

before suspend.

To make it permanent, add the following file in /etc/pm/sleep.d/ and make it executable:

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

with content:

#!/bin/sh
Delete the failing disk so that it will not block suspend
case "$1" in
    suspend|hibernate)
        if [ -d /sys/block/sdb ]; then
            echo 1 > /sys/block/sdb/device/delete

        fi
        ;;
esac

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

@kikuto --- your proposed edit seemed a bit off-topic, but I added a link to how add a kernel boot parameter. Thank you. — Rmano, Jan 23 '15 at 16:28
@AlanFranzoni if the device is seen as a (s)ata device, probably yes; you can check if it got listed as ataX.YY at boot. Otherwise, probably not ( I have not that kind of device on my computer) — Rmano, Apr 16 '21 at 21:52
The CORRECT correct answer would be to polish this patch and submit it to the kernel maintainers, though. :) // I found it more than weird that this isn’t already a kernel init parameter and/or switch in /sys like everything else. — , Apr 16 '23 at 14:44
@Evi1M4chine could be, but given that the disk must be ignored in the very early boot process, the kernel parameter is nevertheless a must (BTW, the patch has been in the kernel since 2014, and I still use the laptop somebody on Craig List tricked me into buying... if I weren't a Linux user it would be as good as a paperweight ;-)) — Rmano, Apr 16 '23 at 18:48

score 5 · Answer 2 · answered Oct 03 '13 at 14:58

You can try to create the udev rule with the following information (output of udevadm info -a -n /dev/sdb).

INFO:

looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0':
    KERNELS=="1:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{rev}=="SSD "
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="6"
    ATTRS{model}=="SanDisk iSSD P4 "
    ATTRS{state}=="running"
    ATTRS{queue_type}=="none"
    ATTRS{iodone_cnt}=="0x309"
    ATTRS{iorequest_cnt}=="0x30a"
    ATTRS{queue_ramp_up_period}=="120000"
    ATTRS{timeout}=="30"
    ATTRS{evt_media_change}=="0"
    ATTRS{ioerr_cnt}=="0x1d6"
    ATTRS{queue_depth}=="1"
    ATTRS{vendor}=="ATA     "
    ATTRS{device_blocked}=="0"
    ATTRS{iocounterbits}=="32"

1) Create the udev rule.

sudo nano /etc/udev/rules.d/99-hide-ssd.rules

You can try to match the "SUBSYSTEMS" &"DRIVERS" keys, and "ATTRS{rev}" & ATTRS{model} attributes, then assign the "UDISKS" variable to ignore it.

The content of the 99-hide-ssd.rules file would be:

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

To save the changes in nano... Ctrl+O, then Enter and finally Ctrl+X.

2) Finally refresh the udev rules with:

sudo udevadm trigger

NOTE: With the ENV{UDISKS_IGNORE}="1" it will ignore the disk for Ubuntu 12.10 & 13.04.
For Ubuntu 12.04 the variable would be ENV{UDISKS_PRESENTATION_HIDE}="1".

Hope this helps.

Tried it, still sdb is detected at boot (and delays it). I think should be some kernel line parameter option, but I was not able to find anything... sigh. Thanks anyway. — Rmano, Oct 03 '13 at 22:44
@Rmano... If you try to only match the kernel key?. the rule would be KERNEL=="sdb", ENV{UDISKS_IGNORE}="1"... to see if the disk is detected in udev. — Roman Raguet, Oct 04 '13 at 01:26
I know it was a lot of time ago. but this problem is still without answer... none of the suggestions worked. Thank you all anyway. — Rmano, Nov 07 '13 at 17:30

score 3 · Answer 3 · answered Dec 08 '13 at 01:02

3

I went and wrote a kernel patch for you that implements the ability to disable a single disk at boot time, so that you don't need to bother with disabling it in udev, or the waiting during the initial boot.

http://dev.gentoo.org/~robbat2/patches/3.13-libata-disable-disks-by-param.patch

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).

answered Dec 08 '13 at 01:02

robbat2

161
6

Only one upvote for an answer from somebody who wrote a kernel patch to solve a problem for another person? Hats off, and +1. – Binarus Jun 22 '22 at 06:51

score 2 · Answer 4 · edited Apr 13 '17 at 12:14

2

https://serverfault.com/questions/112147/tell-ubuntu-to-ignore-dead-hard-drive-during-booting suggests in part:

As root, open up /etc/udev/rules.d/60-persistent-storage.rules with your favorite text editor.

A few lines down, you'll probably see a line that looks like this:

skip rules for inappropriate block devices

KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end" Add "sdb*" to that second line, so it looks like this:

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

Save, reboot, and maybe it works. If not, well, is this post-warranty?

edited Apr 13 '17 at 12:14

Community

1

answered Oct 08 '13 at 21:20

K7AAY

17,202

Tried it, no luck. Still have the sdb drive, still blocking suspend. Once upon a time existed a sdb=ignore kernel command line option... And unfortunately yes, it's post-warranty. – Rmano Oct 09 '13 at 22:06
BTW, I didn't have that file, so I added it... – Rmano Oct 09 '13 at 22:08

score 2 · Answer 5 · answered Oct 10 '13 at 23:04

2

If your other disks are not using ahci, or aren't SSD, you may remove the kernel driver for them.

to remove for that session (until the next reboot), run:

sudo rmmod ahci

to reload it, run:

sudo modprobe ahci

if you see that everything is going fine, you now can disable it totally (don't load it next boots). open the file /etc/modprobe.d/blacklist.conf, and add the following line:

blacklist ahci

to blacklist ssd drivers, just replace ahci with sd

answered Oct 10 '13 at 23:04

Ohad Cohen

775

2

That will leave me a system without any disk... the main drive is on ata1, the failing ssd on ata2. Disabling ahci mode in bios make the system unbootable... – Rmano Oct 11 '13 at 01:52

score 1 · Answer 6 · answered Oct 02 '13 at 20:33

1

From what I know of, there is no way to remove the message, other than removing you SSD.

answered Oct 02 '13 at 20:33

Anudeep Revuri

11

Unfortunately, the SSD is (for what I know) soldered to the mainboard. It's just a 8G chip. – Rmano Oct 03 '13 at 00:14
Cut one of the leds on the chip, preferable find the +5V line and cut that with an X-Acto? – K7AAY Oct 10 '13 at 22:57
...if I only knew which chip is, and where it is. Then I fear that that could create even more problems (undriven three-state...). – Rmano Oct 11 '13 at 15:24

How can I tell linux kernel to completely ignore a disk as if it was not even connected?

6 Answers6

The correct answer is a kernel patch.

Workaround

Delete the failing disk so that it will not block suspend

skip rules for inappropriate block devices

Linked