>>>>> "CM" == Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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 of data do that directory immediately before the install starts (which can be removed immediately after the install completes) doesn't make it any easier. In this case things worked out just "perfectly". The package download brought the available space down to the point that there was sufficient space for RPM's space checks to pass, but not enough space for dracut's temporaries. CM> Gotcha. So why is there a lack of free space there? Sounds like the CM> volume is too small from the outset, or something is running away CM> and filling up that volume. Why does that matter? Sure, you could tell me "you really should make sure there's plenty of free space there" and I wouldn't disagree, but the punishment should be the inability to install an updated kernel, some logged errors or maybe even a kernel package installed with no bootloader entry. It certainly should not be a bootloader entry which is both broken _and set as default_. CM> Seems to me the install script should check for /var/tmp free space CM> before starting. Between kernel and the non-compressed initramfs CM> creation, it's gonna need maybe upwards of 100M or maybe 150M if CM> these are nohostonly initramfs's? So test for a minimum of 200M free CM> space, and if not true, fail? Yes, or the kernel package just %ghosts a dummy file in /var/tmp to reserve some space there. Then RPM itself won't even begin to install the package. If a more messy failure is OK, it could also check for space in %pre (or %pretrans, but that's especially problematic). Anything done later will result in the kernel package remaining installed and then the best you can do is make sure that either a bootloader entry isn't created or at least it isn't made the default. One problem with ghosting a file like that is that it's a terrible layering violation. The kernel package shouldn't really need to know how dracut does its job internally, how much space it needs for temporaries, etc. The best it could do is guess, which I guess is what it's already doing with the 20MB it reserves in boot. CM> For sure grubby is called twice. And for sure the first time it's CM> called, the grub.cfg is modified such that a new entry is created CM> without an initramfs. And to me it's a suboptimal design but appears CM> to be happening by design. I don't know if it's a grubby limitation CM> that it works like this, or other. 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. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
