Blacklist.conf "Ignoring Bad Line Boot Prompt"

Question

Alright Ubuntu wizards, I jacked up my system a bit unnecessarily, which is now giving me the chance to learn more about how to fix it...a vicious cycle. Anyway, I have it mostly up and running again to my liking, though I am receiving this (photo attached) prompt when my system boots:

libkmod: ERROR ../libkmod/libkmod-config.c:686 kmod_config_parse: /etc/modprobe.d/blacklist.conf line 56: ignoring bad line starting with 'rt2800usb'

Other users had success with just deleting the bad line from their blacklist.conf file, which I have done. Line 56 no longer exists, but I'm still receiving the same error. So am I missing something? Is there some follow-up command I need to give Ubuntu after saving the conf file?

Answer 1

Looks like it fixed itself...or it's because I deleted that bad line. It's probably because I deleted the bad line.

Here is how I accessed the blacklist file:

1. Open the terminal

2. Type the command sudo gedit /etc/modprobe.d/blacklist.conf to open the blacklist.conf file

3. Locate the bad line, delete it, and save the file

In my case, I stopped receiving the error after a few restarts. Don't know why it delayed.

Answer 2

The copy of blacklist.conf consulted during boot, to produce that ignoring bad line error, is the one in the initial RAM filesystem.

(That copy's fully qualified path is /etc/modprobe.d/blacklist.conf, like the one you edited. But at the point during boot when it is consulted, / is the initial RAM filesystem rather than your regular root filesystem stored on disk.)

This explains why the problem was not fixed immediately when you edited the blacklist.conf stored in your regular root filesystem.

The initial RAM filesystem is (re)built under some circumstances, such as when a new kernel is installed and as a result of some driver installations and some configuration changes. I think such an event probably triggered your delayed fix.

For the benefit of others, and in case you have this problem again, you can run

update-initramfs -k all -c

to rebuild (-c) the initial RAM filesystem for all installed kernels (-k all). Each installed kernel has its own associated initramfs.

Credit for this solution goes to Christian, who presented it as part of an answer to Ubuntu update caused system to freeze on boot at purple screen. Recovery mode fails and brings up BusyBox, which is a more complicated version of this problem. In that question, the bad blacklist.conf (or other factors) actually prevented the system from booting successfully, and it was necessary for the fix to be applied in a chroot. That was fortunately not necessary in this case.

Since your problem went away by itself (here and there, too), I tested that solution to make sure it works. On an Ubuntu Server 14.10 Beta 2 system (as that's what I had handy for testing), I deliberately produced the problem by creating a bad line in my blacklist.conf file and running update-initramfs -k all -c. (As expected, just editing the file didn't produce the error on reboot--I had to rebuild the initial RAM filesystem to apply the changes.) Reverting to the original, correct blacklist.conf file did not immediately correct the problem, but did once I ran update-initramfs -k all -c again, as expected.

_{As a secondary matter, when editing /etc/modprobe.d/blacklist.conf or other files that have to be edited as root, if you wish to use Gedit, I recommend running it as gksudo gedit /etc/modprobe.d/blacklist.conf, as running graphical programs as root with straight sudo sometimes creates root-owned configuration files in your home directory, interfering with the application's functioning when you run it normally later. If the gksu package (which provides gksudo) isn't installed, you can use sudo -H or sudo -i instead.}