[arch-projects] [mkinitcpio][RFC] a better fallback image?

Jan Steffens jan.steffens at gmail.com
Wed Jul 25 17:46:02 EDT 2012


On Wed, Jul 25, 2012 at 11:21 PM, Tom Gundersen <teg at 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.


More information about the arch-projects mailing list