On Thu, Jul 26, 2012 at 12:01:22AM +0200, Tom Gundersen wrote: > On Wed, Jul 25, 2012 at 11:43 PM, Dave Reisner <[email protected]> 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
