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.