On Tue, Jul 03, 2012 at 14:18:07 -0400, Dave Reisner wrote: > Worst case scenario, users of custom kernels can: > > - manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until > they can do a proper rebuild. > - boot a stock -ARCH kernel (you DO have it listed as a fallback, > right?) until they can do a proper rebuild. > > Emphasis on "until they can do a proper rebuild". It's important that > this all gets done before we introduce a new glibc package that wipes > out /lib entirely. If you have custom kernel bits lying around in > /lib/modules, it's going to block the eventual glibc upgrade that brings > this (no, it won't be immediately with 2.16). > > dave What will be the situation for VM users, where /lib/modules is managed externally by the VM hoster, but the kmod package by the VM customer? After moving the current modules manually, will we get away with a symlink /lib/modules -> /usr/lib/modules to support future kernel upgrades? (the kernel upgrade procedure will typically take down the VM, mount the filesystem on the host directly to install new modules, and boot the VM with the new kernel, so no opportunity for the VM customer to manually interact before boot.) Geert -- geert.hendrickx.be :: geert@xxxxxxxxxxxx :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
