> On Tue, Aug 20, 2013 at 6:57 PM, Tanstaafl <tansta...@libertytrek.org> wrote: >> On 2013-08-20 2:54 AM, Canek Peláez Valdés <can...@gmail.com> wrote: >>> >>> Unless you want to learn the ins and outs of using an initramfs (and >>> having a lot of fun and failed boots in the process), I highly >>> recommend using Dracut. It does everything for you. >> >> >> What about a previous posters comment that they don;t update the kernel as >> often as userland stuff, and there is userland stuff in the initramfs, so >> things can still get out of sync - and, apparently (I'm inferring from the >> comments about nightmare scenarios of unbootable systems because the >> initramfs got 'out of sync')... >> >> So, how do/can you *guarantee* that nothing ever gets out of sync? >> > > I'm confused here. initramfs, is, for all intents and purposes, an > isolated filesystem. It shouldn't be calling stuff in your real root > except to mount the real > root. Heck it should be able to mount pivot root on filesystems that > have absolutely > nothing to do with its construction, as for example, LTSP does.
Correct, and here lies the cause for the "out of sync" scenario. > So the only "out of sync" scenario that should matter is with the > kernel or kernel modules. Even if it were out of sync with your > current toolset it should still be able > to perform the pivot. Shouldn't any "userland stuff" that > breaks initramfs BE in initramfs? Incorrect, there are userland tools, like LVM and MDADM (layout 1.2 does NOT support auto-assembly by kernel), that are needed to access of the filesystems. It is possible that an older version of one of these tools, after an update, can no longer access the disks succesfully. When portage updates this package, the initramfs is not automatically updated with the new version. I agree that it doesn't happen often. But on this list there has already been a report of a recent occurence where LVM was updated, but the initramfs was not, where the boot-sequence ended up being broken. -- Joost
