On Wed, Jul 25, 2012 at 11:21 PM, Tom Gundersen <teg@jklm.no> wrote:
Dave, Tobias, Thomas,
I just managed to hose one of my machines. It was mainly due to an unfortunate series of events, but I have a suggestion which would have avoided this situation and might beneficial in general.
The way things are now, I think the fallback image mkinitcpio generates by default is not very useful. In my experience the fallback image is broken exactly when the regular image is broken. I expect the reason for this is that the autodetection of modules is very good these days, so _that_ is never the problem.
Right. AFAIK the only remaining use is booting after hardware changes.
When there is a problem, which happens every once in a while, it is either due to user error (i.e. configuration errors), or mkinitcpio not being ran at all (and hence having the modules of the previous kernel (which is what happened to me today).
It seems to me that a more useful fallback image, would be one that is generated at compile-time, rather than at install-time, and shipped as a part of the kernel package. This would avoid user errors, and mkinitcpio run-time problems.
This fallback image should contain the widest sets of hooks and modules so that it should work on any hardware and any setup (at least to the extent possible with our current hooks).
Any thoughts?
Cheers,
Tom
I think there are a few corner cases it wouldn't boot, but it sounds generally useful. Wouldn't this add quite a lot of weight to our kernel packages? Making the modules built-in instead of shipping them twice would probably help with this. I'm still thinking about that "rescue" initcpio with a bigger toolset (pacman, rsync, et cetera), but that's another issue.