[arch-dev-public] [mkinitcpio][RFC] a better fallback image?

[Dave Reisner]

On Thu, Jul 26, 2012 at 12:01:22AM +0200, Tom Gundersen wrote:
> 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.
> 

Fun!

> > 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).
> 

Well that answers the why, but that was the easy question =P. I suppose
I could re-add a flag that would point mkinitcpio at a different module
root (making no attempt to fully reimplement --basedir), which could be
simply passed onto modinfo/modprobe ...but that would require patching
modinfo first.

> > 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.

Sure. I'd love to see the running kernel version and the first column of
/proc/modules submitted with pkgstats. If we were to reset the global
stats (or just reset the epoch) and make a concerted effort to have
people submit (news post, social media, allan's blog, etc) I'll bet we
could gather some good usage stats from -ARCH kernel consumers in a
fairly short timeframe.

> Cheers,
> 
> Tom