How to Fix Linux Broken Pipe Errors
While it’s quite rare, it’s possible that you’ll find yourself unable to install any packages at all in an otherwise seemingly stable installation of Linux. Debian, Ubuntu and those distributions derived from them rely on the apt-get package manager. Generally, if you have administrator superuser access, then typing apt-get install -f should install additional packages if needed. However, as rare as it is, you might get a message that reads dpk-deb: error and then proceeds to instruct that you have a broken pipe.
Usually the term broken pipe refers to a misuse of the character | at the command line, which is often called a pipe, especially to those with a background in MS-DOS. In this case, though, you might not have typed a command incorrectly. Rather, if you didn’t use the | character when typing the apt-get command, then you might have a problem involving your file system that forced a read-only mount. While it might seem embarrassing, the first step is to check and ensure you’ve typed the installation command correctly before proceeding. If there’s no problem, then the next step is to inspect the file system.
Method 1: Inspecting the Typed Command
While more than likely this isn’t the case, it’s important to make sure that you typed the installation command correctly before you assume the worst. Even the most elite programmers sometimes end up mistyping something, and it’s easy to type the | character by mistake. Don’t push up on the keyboard to recall the last command. Type it again individually. Try running apt-get install -f or apt-get update, since these commands aren’t destructive. If you still get the error after repeatedly reissuing it, then try rebooting the machine. If you still receive it, then you might be suffering from a file system problem. The broken pipe error message might be nothing more than a symptom of a bigger problem.
Method 2: Recovering from Broken Pipe Errors Caused by File System Dysfunctions
Should you be unable to fix it merely by typing the command over again, then pay special attention to whether or not you see some sort of an error that reads “Read-only file system” in the terminal output. This indicates that, for whatever reason, your boot partition is mounted as a read-only volume. Generally, this means it’s suffered some sort of file system problem and the GNU/Linux operating system doesn’t feel it’s safe to write to it. This safety mechanism means that while some data might be corrupt, Linux has done it’s best to salvage your install.
You might possibly receive some kind of strange message when you try to use the sudo command that is also caused by this same type of error. Such a message would begin with “sudo: unable to open” followed by the name of some resource. Since all resources in Unix are stored as files, a read-only partition mount might keep sudo from working.
If either of these cases is true, then you need to shutdown your system. If you have a pre-made USB drive with an ISO of a clean Linux install, then insert it and hold down whichever key your BIOS or UEFI system requires to boot from a removable device. Should you instead have a separate Linux partition on your boot drive, then you should access this through GRUB when you restart. In either case, you need to have a stable environment to work from that can access the damaged partition without booting from it.
Assuming you have some type of data that you haven’t backed up yet, then take this opportunity to back that data up to another partition or a removable device if Linux allows you to attach mounted devices in this state. Usually you can’t mount devices to a read-only file system, so you will have needed to reboot your system into a live USB or potentially DVD environment to perform backups. You’ll want to run the appropriate fsck command for the file system installed on your boot drive to restore it to a stable state. For instance, let’s assume you have a damaged /dev/sda1 partition that you formatted with an ext4 file structure. If that’s the case, then from a root terminal inside of the live USB or DVD environment you could issue fsck.ext4 -fv /dev/sda1 to check the file system. You can also use fsck.ext2 or fsck.ext3 if you booted from either of these two types of ext file system. In theory, all three of these call the e2fsck program anyway, and may just be soft links.
This will provide verbose output and force it to scan even if it appears clean. You may be interested in using -c or -ck to run a surface scan with the badblocks program in case you suspect that there was some sort of geometry problem with the disk. Once you’ve run the program, reboot from the partition if it’s stable and then issue the sudo mount -o rw,remount / command from a terminal inside this boot to restore read-write access. You’ll need root access to look in the /lost+found directory, but it’s important you do since fsck.ext# might have put some lost clusters there. If you’re missing files once you’re back inside of your GNU/Linux install, then they might be here, though they’ll be renamed. Use the file command in the terminal to tell which type each is if at all possible.
If you don’t have a live USB or DVD to boot from, then you’ll need to make one from a clean machine from an ISO downloaded for a distribution of Linux. Since you’re only using terminal commands, you might not even need a boot device for your distribution. Some, like KNOPPIX, are designed explicitly for fixing problems like this. If you’re working with a netbook or laptop that features an SD or microSD card slot, then you could also boot from an ISO burned to an SDHC or microSDHC card. The same goes for, say, Ubuntu tablets that have such a slot.
