Fix buffer I/O error on device during Linux boot

Seen this error during boot? It's not a panic—just a disk or controller issue. Let's trace the device and decide if it's fixable or a sign of hardware death.

When does this error hit?

You're staring at a boot screen that freezes for 90 seconds, then drops a line like buffer I/O error on device sda, logical block 1024. Or it's buried in dmesg after a slow boot. This usually happens when the kernel tries to read or write to a disk and gets no response—a timeout, a bad cable, a dying drive, or a missing partition.

Common triggers: plugging in an external USB drive during boot, a SATA cable that's half-loose, a disk that's been dropped, or a faulty RAID controller. I've also seen it with LVM where a physical volume went offline silently.

Root cause in plain English

The kernel sends a request to the storage device driver (like ahci for SATA or nvme for NVMe). The driver queues the I/O to the hardware. If the device doesn't respond—hardware failure, cable fault, or the device was unplugged—the driver returns a buffer I/O error to the filesystem layer.

This isn't a kernel panic. The system will keep booting if it can skip the bad device, but it'll hang waiting for the timeout. The real question: is this a dead drive, or just a temporary glitch?

Step-by-step fix

Identify the device from the error message. Look at the boot output or run dmesg | grep 'buffer I/O error'. You'll see something like sd 0:0:0:0 [sdb] buffer I/O error on device sdb. That [sdb] is your culprit. Write it down.
Check if the device is still visible. Run lsblk and fdisk -l to see if the drive shows up. If it's missing entirely, you're dealing with a dead controller or disconnected cable. If it shows up with no partition table, the drive might be toast.
Test the drive with smartctl. If the device is still listed, do smartctl -a /dev/sdb. Look for Reallocated_Sector_Ct—anything above 0 means mechanical damage. Also check Current_Pending_Sector and Uncorrectable_Sector_Ct. If any of these are non-zero, the drive is failing. Replace it.
Check cables and connections. I've fixed this more times than I can count by reseating a SATA cable or trying a different power cable. Shut down, unplug the drive's data and power cables, then firmly reconnect them. Boot again. If the error vanishes, that was it.
Scan for bad blocks (if the drive passes smartctl). Use badblocks -v /dev/sdb to locate unreadable blocks. This will take hours for a large drive. If it finds bad blocks, the drive needs replacement—soon.
If it's a USB drive, try a different port. USB controllers can flake out. A USB 3.0 port sometimes works where a 2.0 port won't, or vice versa.
Check for multipath or LVM issues. Run multipath -ll if you use multipathing. Look for failed paths. For LVM, do pvscan and vgscan—a missing PV will cause buffer errors. Remove the dead PV with vgreduce --removemissing.

What if it still fails?

If the drive is healthy but the error persists, try these next:

Update your kernel. I've seen buggy drivers cause spurious errors. Boot into an older kernel from GRUB, or upgrade to the latest stable kernel.
Check the SATA controller. Run lspci | grep SATA and see if it's a known flaky chipset (like some Marvell or JMB controllers). Add libata.force=noncq to your kernel boot parameters to disable NCQ, which sometimes causes these errors.
Replace the SATA cable. Cables die. I keep a spare pack of SATA cables just for this reason. Swap it out.
Test the drive in another machine. If it passes smartctl and badblocks there with no errors, the problem is your motherboard or controller card.
Last resort: add noprobe to kernel boot parameters for that device. This tells the kernel to ignore it entirely. Not a fix, but it'll let you boot if the drive is empty or you've already backed up the data.

I've seen this error on everything from Debian 10 to Ubuntu 22.04 to CentOS 7. The fix is almost always a dying drive or a loose cable. Don't panic—just follow the breadcrumbs in dmesg. And if the drive is failing, swap it out before you lose everything.