Does anyone reuse /boot or /var partitions ?

[Eric Blake]

On 01/22/2015 04:00 PM, Chris Murphy wrote:
> On Thu, Jan 22, 2015 at 2:36 PM, Adam Williamson
> <adamwill at fedoraproject.org> 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?  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?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20150123/247a0760/attachment.sig>