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

Tom Gundersen teg at jklm.no
Wed Jul 25 18:01:22 EDT 2012


On Wed, Jul 25, 2012 at 11:43 PM, Dave Reisner <d at falconindy.com> wrote:
> On Wed, Jul 25, 2012 at 11:21:10PM +0200, Tom Gundersen 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.
>
> Oops. ;P
>
> What did you break?

Had a hard crash during a pacman. Trying to fix things from a rescue
shell I installed the kernel and as I didn't have udev running,
mkinitcpio claimed /dev was not mounted (at least I think that's why
that happened) and refused to run. I then started udevd manually, and
the machine hung again.

Result: on next restart I had a 3.5 kernel, but the modules in both my
initramfs' were 3.2 (or something like that). So without an ext4 I was
sad.

> You've mentioned this idea before, and more recently, so has Jan. I've
> slowly and quietly been adding support to mkinitcpio to make this less
> painful to do. An xz-compressed image with the usb and fw hooks still
> weighs in at under 10MiB, so I have no real concerns about this being
> problematic for users with separate /boot partitions.

Nice!

> That said, I'm wondering how it would be possible to generate this at
> compile time. I'm not really sure how this would be possible. Is there
> any objection to just adding another preset (maybe related to how you
> fubar'd your install this time?).

The underlying problem is that in principle you might (as I did)
upgrade your kernel without running mkinitcpio. We have seen pacman
issues causing this, simple crashes as what I had might cause it, or a
broken mkinitcpio.conf might do it (I guess the last one could be
worked around by adding a special preset that does not care about user
config).

> As an alternative/addition, which has also been brought up before, why
> don't we build in the most basic of modules? I'll bet we can cover at
> least 50% of the use cases by picking some choice pata/sata modules
> (e.g. ahci, ata_piix, pata_jmicron, sd_mod, ext4) and compiling them in
> staticly. It, of course, doesn't cover folks with non-trivial setups,
> but it provides a bulletproof bootstrap for a lot of people.

I really think this would be a good idea. I wanted to make some
additions to pierres pkgstats stuff so we could have an idea of how
large percentage of our users would be covered by the modules you
propose. I expect the vast majority would.

Cheers,

Tom


More information about the arch-projects mailing list