Re: [arch-dev-public] [mkinitcpio][RFC] a better fallback image?
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@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
On Thu, Jul 26, 2012 at 12:17 AM, Dave Reisner <d@falconindy.com> wrote:
Well that answers the why, but that was the easy question =P.
Ah, my brain skipped over the hard part of the question ;-)
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.
Hm, I didn't realise that this was not currently possible. Good point. If worst comes to worse, I guess we could try using some chroot magic? -t
On Thu, Jul 26, 2012 at 12:45:39AM +0200, Tom Gundersen wrote:
On Thu, Jul 26, 2012 at 12:17 AM, Dave Reisner <d@falconindy.com> wrote:
Well that answers the why, but that was the easy question =P.
Ah, my brain skipped over the hard part of the question ;-)
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.
Hm, I didn't realise that this was not currently possible. Good point. If worst comes to worse, I guess we could try using some chroot magic?
-t
Just to complete the illusion, there _is_ a --basedir flag for modinfo (hell, it used to be part of mkinitcpio), but much like module-init-tools, it isn't documented in the manpage. That's fixed upstream, and I'll add a --moduleroot flag to mkinitcpio for next release. That _should_ make image creation possible from makepkg. The only caveat is that we'll need to ship our own one line mkinitcpio.conf to specify HOOKS="", or hack it into the PKGBUILD and source that (would be effectively benign as far as mkinitcpio is concerned). d
On Thu, Jul 26, 2012 at 12:17 AM, Dave Reisner <d@falconindy.com> wrote:
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.
Pierre: would something like the attached patch make sense for pkgstats? Cheers, Tom
Am 26.07.2012 00:17, schrieb 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@falconindy.com> wrote:
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.
I have added pkgstats 2.3 to testing. It now sends the list of loaded kernel modules and also the cpu architecture. -- Pierre Schmitz, https://pierre-schmitz.com
participants (3)
-
Dave Reisner
-
Pierre Schmitz
-
Tom Gundersen