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/sdbfailing.
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:
Adding to one of the following
/etc/udev/rules.d/a file (in early execution like00-ignoredisk.rulesor in late as99-ignoredisk.rulesor in both places)SUBSYSTEMS=="scsi", DRIVERS=="sd", ATTRS{rev}=="SSD ", ATTRS{model}=="SanDisk iSSD P4 ", ENV{UDISKS_IGNORE}="1"nor
KERNEL=="sdb", 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.
Editing the system files
/lib/udev/rules.d/60-persistent-storage.rules(andudisks,udisks2) changingKERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-|md", GOTO="persistent_storage_end"to
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.
Booting with all the possible combinations (well, a lot of them) of the
libata:forceparameters (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/sdbpasted to http://paste.ubuntu.com/6186145/smartctl -i /dev/sdb -T permissivegives: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 pagewhich 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 ).
/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 readingfstab. – Teresa e Junior Nov 26 '13 at 18:10