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. -- [feisty] very nasty bug with libata https://launchpad.net/bugs/82486 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
