On Tue, Sep 4, 2012 at 9:28 AM, Mark Hatle <[email protected]> wrote: > > I'm sorry, not all devices being generated have initramfs configuration (nor > do people want that behavior.) Also we've shown you can build a system w/ > a split filesystem and it works properly.
yes if every package followed this sadly thats a more and more diverging case now a days. so do we diverge and it there a compelling case to do so. I would do it if 80% of our usecase was this one but this seems like a one off thing so either we find a better solution or we abandon it. In my opinion such a thing should be a configure option disabled by default and whoever has the usecase for it can enable it but not default there is a use case where now people are asking can I use this fedora prebuilt rpm with yocto/OE and so on and if we diverge too much on root file system layout by default we can get sidelined. The systemd/udev developers seem > 'lazy' to me... they were unwilling to work through early and late boot so > they just gave up. Linux was never supposed to have / and /usr different to begin with > > The comments in the FAQ about /etc and /var being local to a given machine, > while /usr being shareable is a reasonable set. This is the situations > where I've seen this used the most especially in blade systems w/ a local > rootfs on each, with a shared /usr among them all. > > I agree it can make some update processes more difficult, but the reality is > there are already mechanisms in place -- for many products -- that address > this. > > Perhaps one way around the whole argument is simply to redefine the problem. > (As Fedora and others seem to have done.) Work on an OE solution to > construct a minimal boot/configuration system that can load the appropriate > (combined) /usr partition, and then pivot-root, or similar and re-exec init > to switch to that configuration? This is similar in concept to the > initramfs, but is not tied to a specific technique or technology. > > This would still allow for the quick boot configuration (RO mount even), > udev setup, module loading and such -- and the larger /usr partition and > upgrade path. > > This is not something we have in OE today, and would certainly require some > custom work..... _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
