> "CM" == Chris Murphy writes:
CM> As I think about it, new-kernel-pkg is part of grubby.
Yes, I assume it will go away and we'll be left with only the
install-kernel infrastructure. Which would strip at least three layers
from this onion. It also conveniently forces the issue, since it's
On Fri, Sep 7, 2018 at 5:09 PM, Jason L Tibbitts III wrote:
>> "CM" == Chris Murphy writes:
>
> CM> But also the first new-kernel-pkg with --install calls grubby with
> CM> makedefault, which is what I think is setting grubenv with the new
> CM> kernel variable before the initramfs and final
> "CM" == Chris Murphy writes:
CM> But also the first new-kernel-pkg with --install calls grubby with
CM> makedefault, which is what I think is setting grubenv with the new
CM> kernel variable before the initramfs and final grub.cfg modification
CM> are done.
Right, which is why I wonder if
On Fri, Sep 7, 2018 at 3:58 PM, Jason L Tibbitts III wrote:
>> "CM" == Chris Murphy writes:
>
> CM> Well, I can't really parse this very well, but the default kernel
> CM> looks like it is changed by grubby, but I can't figure out the
> CM> ordering. It's seems plausible, perhaps likely, that
> "CM" == Chris Murphy writes:
CM> Well, I can't really parse this very well, but the default kernel
CM> looks like it is changed by grubby, but I can't figure out the
CM> ordering. It's seems plausible, perhaps likely, that it starts off
CM> dracut and the grub2-editenv at the same time, and
On Fri, Sep 7, 2018 at 2:32 PM, Jason L Tibbitts III wrote:
>
> I guess if the end goal is to remove grubby from the process entirely
> then it's not worth digging too deeply why it's doing this. But maybe a
> quick fix would be obvious to someone who knows how that works.
>
Well, I can't reall
> "CM" == Chris Murphy writes:
CM> Why is /var/tmp running out of space?
Is that really important? In this case it was due to things simply
being too small (they are minimal VMs, after all) and dnf caching
packages there. The fact that dnf downloads a significant but quite
variable amount
On Fri, Sep 7, 2018 at 10:27 AM, Jason L Tibbitts III wrote:
>> "CM" == Chris Murphy writes:
>
> CM> A few releases ago, Anaconda now defaults to a 1GiB boot partition
> CM> which should prevent the problem you're describing for anyone using
> CM> the default 3 retained kernels, as well as th
> "CM" == Chris Murphy writes:
CM> A few releases ago, Anaconda now defaults to a 1GiB boot partition
CM> which should prevent the problem you're describing for anyone using
CM> the default 3 retained kernels, as well as the extra kdump initramfs
CM> if you're using kdump (not enabled by defa
On 6.9.2018 16:44, Jason L Tibbitts III wrote:
> * The kernel could "pre-allocate" space in /var/tmp (by %ghosting a
> dummy nonzero-length file there) so that the package simply won't
> install if there isn't space sufficient to generate the initramfs.
> Would that be something we could reas
On Thu, Sep 6, 2018 at 8:44 AM, Jason L Tibbitts III wrote:
> I'd like to brainstorm a bit about how to make kernel updates more
> resilient to running out of disk space. I've talked to a few people on
> IRC about this but I'm not at the point where I know enough to file good
> bugs and figured t
FWIW, rpm-ostree fixes all of this today - the entire update is really
transactional,
and fully handles hitting ENOSPC at any point.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.o
I'd like to brainstorm a bit about how to make kernel updates more
resilient to running out of disk space. I've talked to a few people on
IRC about this but I'm not at the point where I know enough to file good
bugs and figured that a larger discussion might help.
Summary of my questions:
Why i
13 matches
Mail list logo
