Ubuntu
linux-source-2.6.20 package

[feisty] very nasty bug with libata

Bug #82486 reported by José M. López-Cepero
2
Affects Status Importance Assigned to Milestone
linux-source-2.6.20 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: linux

I had a laptop with Ubuntu 6.06 LTS. I updated it to Edgy and then to Feisty and everything seemed to go okay. However, the system would not boot after that. It would stay almost dead with only a little bit of the boot process bar active, then drop to a shell after a few minutes.

After _lots_ of pulling my hair, I found that the cause was a file called "libata.modprobe" in /etc/modprobe.d. The file contained the line "options libata printk=255", and, upon booting, libata would complain of the "printk" option being unknown... and refuse to load. Since all my hard drives are SATA, that meant the initrd system didn't see the root drive and thus hanged. Commenting out the option line and regenerating the initrd solved the problem.

Two thoughts.

First: What package is responsible for the libata.modprobe file? I'd guess this is modutils. Maybe I was caught in a bad update, or something like that. In that case, it would be nice for subsequent updates to correct the problem. I did chroot to my Feisty installation and apt-get update/dist-upgrade, to no avail.

Second: Why does a critical module, such as libata, not load because of an "unknown option"? It does not seem right to me. Wouldn't it be _much_ more sensible to just ignore the erroneous option and go on? That would have avoided the problem...

Hope this helps someone.

Revision history for this message
José M. López-Cepero (cepe) wrote :

Sorry, forgot to report. Using kernel 2.6.20-5-generic.

Revision history for this message
Cristian Aravena Romero (caravena) wrote :

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information.

Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available here: <http://wiki.ubuntu.com/DebuggingKernelProblems> Thanks!

Revision history for this message
José M. López-Cepero (cepe) wrote :

Hi Cristian,

Right now, I don't have access to the computer where I originally had the problem in. I will do as you suggest when I can, although I'm afraid that the kernel version has been updated since, so I'm not sure that it will be of much use.

However, I could reproduce the problem this way:

 - Create a file called /etc/modprobe.d/libata
 - Write "options libata printk=255" in the file
 - Recreate the initrd (either manually or by updating the kernel) - that will get the /etc/modprobe.d/libata file on the initrd
 - Reboot. When loading the initrd, libata will refuse to load because it will not recognize the 'printk' parameter. Then, the root partition will not be accessible, and booting will fail at the early stages.

I don't know where the /etc/modprobe.d/libata file first came from. I have another computer which I usually upgrade more or less at the same time and it did not show the problem. So maybe it was some strange bug in modutils or something like that. I searched extensively and, although there were a few reports of similar problems, they are very rare, so whatever happened is probably not an issue now. If you consider that to be enough, feel free to close the bug.

However, I'd personally vote for making the libata module handle erroneous parameters more gracefully (printing a warning and ignoring them instead of failing to load), since I think that making a critical module not load because of a misspelled argument is not exactly the best way to handle the error.

Best regards.

Revision history for this message
Ben Collins (ben-collins) wrote :

This file doesn't appear to exist with Ubuntu. Maybe you added it some time ago?

Changed in linux-source-2.6.20:
status: Unconfirmed → Rejected
Revision history for this message
José M. López-Cepero (cepe) wrote :

I don't really remember doing that, but it could be. Sorry for being annoying :)

However, I still think it would be a good idea to not make libata choke on unknown parameters.

Thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.