On Fri, 2015-01-23 at 10:07 -0700, Eric Blake wrote: > On 01/22/2015 04:00 PM, Chris Murphy wrote: > > On Thu, Jan 22, 2015 at 2:36 PM, Adam Williamson < > > adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > There's a proposed anaconda patch ATM which would disallow > > > mounting an existing partition as /boot or /var (or any > > > subdirectory of those except /var/www ) without reformatting it. > > > i.e., you can't reuse an existing partition with those > > > mountpoints. > > > > > > I'm curious to know if anyone / many people do this, and if so, > > > if there's a particularly good use case for it; if so, we might > > > want to provide that feedback to the anaconda folks. > > > > The upstream Bootloaderspec calls for a shared /boot on BIOS. And > > mjg59's derivative bootloaderspec calls for a shared /boot on both > > BIOS and UEFI. > > > > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ > > http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ > > > > > > > The main driving force for this is > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1074358 , > > > as it keeps turning out to be annoyingly tricky to make sure > > > that only newly- installed kernels have their initramfs > > > regenerated when installing to a shared /boot partition. > > > > Each distro is to have its own directory on /boot per the > > bootloaderspecs (both of them) which would resolve this problem. > > Couldn't anaconda just be taught to install its new kernel under a > just-created /boot/$subdir and leave the rest of /boot untouched? Sure it *could*, but that's a major change in behaviour that isn't really sensible just to throw in as a bug fix and hope it doesn't break anything else. Also, it's not really anaconda's job, it's the kernel package that decides where its files live. > That sounds to me like both what bootloaderspec variants are > proposing - it would get rid of the issue of what do to with any pre- > existing kernels, because there are no pre-existing kernels if we > always install new kernels under a subdirectory specific to the > installation rather than in the top level directory of the > partition's filesystem. What good is a proposed shared > bootloaderspec document if we aren't willing to implement its ideas, > including sharing /boot across multiple distros? Well, a) so far I don't think anyone else has committed to adopting it so doing it for Fedora wouldn't really achieve a whole lot (except maybe improving multi-Fedora-boot and happening to solve this problem), b) it's a pretty major change and it's all in stuff pjones maintains and he has a lot else to do. mjg59 sent an incomplete implementation to desktop@ (for some reason?) back last July, but that's all I can find: https://lists.fedoraproject.org/pipermail/desktop/2014-July/009995.html There's also some discussion from 2013 on systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011192.html so basically I think a few people are interested and pushing it along, but it's not top priority for anyone? That's what it looks like. CCing pjones and mjg59 for comment, if they like. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
