On Wednesday, May 06, 2015 03:00:08 PM Josh Boyer wrote:
> On Wed, May 6, 2015 at 2:53 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote:
> > On Wed, May 06, 2015 at 11:48:00AM -0400, Don Zickus wrote:
> >> On Wed, May 06, 2015 at 10:41:28AM -0400, Josh Boyer wrote:
> >> > > Not that my opinion matters much, but I think this is an interesting
> >> > > mind shift. The end result is the same as today, just extra files in
> >> > > /lib/modules/`uname -r`, right?
> >> >
> >> > Actually, I was hoping some other kernel maintainers would chip in so
> >> > your opinion does matter. I really don't want to change this in Fedora
> >> > to only have it reverted in a future RHEL. Maybe Jarod or Rafael would
> >> > be kind enough to review as well...
> >>
> >> Off the top of my head, if it works out for Fedora, I currently can't see
> >> a
> >> reason RHEL would revert it. But that depends on what quirks falls out.
> >> :-)>
> > First pass through, I see a few oddities, some of which aren't the fault
> > of this patch, but if manipulating these areas, might as well fix them
> > up...
> >
> > 1) %image_install_path is never defined to anything but boot, for all
> > supported arches. I think this is ia64 legacy, when it was /boot/efi, but
> > we should just have a single define for it now.
> >
> > 2) we do this, both before and after the patch:
> > mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot
> > mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
> >
> > ...which per #1, is obviously redundantly redundant.
> >
> > 3) after the patch, there are multiple install calls to put stuff into
> > $RPM_BUILD_ROOT/boot/, but then they're %ghost'ed out. This seems a little
> > bit of a waste, just do a touch for the /boot variants of those files and
> > %ghost the same. Similarly, with the .hmac file, don't copy it around, put
> > it where you want the real one, touch the %ghost.
>
> Actually, I don't think we want to do that. We want to account for
> the space that will be eaten by the real files that get copied to
> /boot so that RPM can do it's disk space requirements estimates. We
> don't want people to get 2/3 of the way installing a new kernel to
> have it fail because they don't have sufficient space in /boot.
>
> (We do something similar for the initramfs file already in a different
> place, but that is literally generated from content outside the kernel
> RPM so we can't just install a real file).
>
> > 4) it appears there's already logic inside kernel-install to copy the
> > necessary files over to /boot at install time, and with the %ghost,
> > they'll properly report as being part of the kernel package, but how long
> > has that support actually been in kernel-install? Do you possibly want to
> > add an explicit Requires: systemd >= x-y, as noted in the patch header? (I
> > would).
>
> Harald noted that all current Fedora releases are covered in the
> initial posting. We could add an explicit systemd Requires, but it'll
> just default to the oldest version in F20.
>
> > Those issues aside, this doesn't really look all that scary at all.
> >
> > One other thought: what happens when /boot is on the same file system as
> > /usr and/or /lib? Does the file get unnecessarily copied, or is it
> > hardlinked or _____?
>
> Copied as far as I know. Yes it's slightly inefficient, but worrying
> about that case (which isn't default at all) seems kind of pointless.
It actually makes a lot of sense to hardlink, the default filesystem setup for
cloud images is just / and in the cloud they worry a lot about wasted space.
Dennis
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
