[opensuse-support] Leap 15.1: root full on boot, plenty of space a few minutes later
Hi *, after the latest update for one of my openSUSE Leap 15.1 machines I ran into a peculiar problem: On the first boot after updating the machine lots of services didn't start and the logs told me the root partition was full. While trying to find out, why that might be, all of a sudden there were 30 gigs avalaible - without having done anything on my side. So I decided to reboot the machine again. This time all services started, but only 7 gigs were available. I waited a few minutes and after that short period 44 gigs werde available. I monitored the system for a while, but this value didn't change anymore. So what the heck is going on here? Why does the system need 30 to 40 gigs on boot? And for what purpose? I never observed anything like this. Any idea? TIA. Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Hi I do not know about 30 gigabytes, however, I do know that when a new kernel is installed, especially if you are installing the development and the source and other related kernel packages, it takes up a fair amount of disk space. And what happens is that after the reboot, a job runs to clean up the old kernels and remove them, so that might be what is happening here. The extra space could have been from a new kernel installation, which is then subsequently cleaned up after the next reboot. Just a thought... Glen On Sun, Jan 26, 2020, 11:48 Michael Hirmke <mh@mike.franken.de> wrote:
Hi *,
after the latest update for one of my openSUSE Leap 15.1 machines I ran into a peculiar problem: On the first boot after updating the machine lots of services didn't start and the logs told me the root partition was full. While trying to find out, why that might be, all of a sudden there were 30 gigs avalaible - without having done anything on my side. So I decided to reboot the machine again. This time all services started, but only 7 gigs were available. I waited a few minutes and after that short period 44 gigs werde available. I monitored the system for a while, but this value didn't change anymore.
So what the heck is going on here? Why does the system need 30 to 40 gigs on boot? And for what purpose? I never observed anything like this.
Any idea?
TIA.
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Hi Michael, et al, Interesting! FWIW I have had the same with a Tumbelweed installation after a *zypper dup*, zypper stops installing the new kernel with a message asking for about 16MB in the boot volume. Opening a tab reveals over 90MB free. Manually deleting the old kernel files and then telling zypper to retry does the trick. I have not had this issue in any 15.1 machines. I have to wonder where the space calculation is coming form and if it's a bug in mkinitrd or dracut. Not an answer but an easy work around and perhaps an avenue for investigation. Cheers, Ariez On 27/01/2020 03:48, Michael Hirmke wrote:
Hi *,
after the latest update for one of my openSUSE Leap 15.1 machines I ran into a peculiar problem: On the first boot after updating the machine lots of services didn't start and the logs told me the root partition was full. While trying to find out, why that might be, all of a sudden there were 30 gigs avalaible - without having done anything on my side. So I decided to reboot the machine again. This time all services started, but only 7 gigs were available. I waited a few minutes and after that short period 44 gigs werde available. I monitored the system for a while, but this value didn't change anymore.
So what the heck is going on here? Why does the system need 30 to 40 gigs on boot? And for what purpose? I never observed anything like this.
Any idea?
TIA.
Bye. Michael.
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Mon, Jan 27, 2020 at 8:25 AM Ariez J Vachha <ariez@ajvco.com.hk> wrote:
Hi Michael, et al,
Interesting! FWIW
I have had the same with a Tumbelweed installation after a *zypper dup*, zypper stops installing the new kernel with a message asking for about 16MB in the boot volume. Opening a tab reveals over 90MB free. Manually deleting the old kernel files and then telling zypper to retry does the trick. I have not had this issue in any 15.1 machines.
TW includes 5.4 kernel which has known bug in free space calculation returned by statfs. It does not apply to Leap unless you are using custom kernel.
I have to wonder where the space calculation is coming form and if it's a bug in mkinitrd or dracut.
Neither.
Not an answer but an easy work around and perhaps an avenue for investigation.
It is already investigated and cause is known. Check btrfs mailing list archives.
Cheers, Ariez
On 27/01/2020 03:48, Michael Hirmke wrote:
Hi *,
after the latest update for one of my openSUSE Leap 15.1 machines I ran into a peculiar problem: On the first boot after updating the machine lots of services didn't start and the logs told me the root partition was full. While trying to find out, why that might be, all of a sudden there were 30 gigs avalaible - without having done anything on my side. So I decided to reboot the machine again. This time all services started, but only 7 gigs were available. I waited a few minutes and after that short period 44 gigs werde available. I monitored the system for a while, but this value didn't change anymore.
So what the heck is going on here? Why does the system need 30 to 40 gigs on boot? And for what purpose? I never observed anything like this.
Any idea?
TIA.
Bye. Michael.
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Ariez J Vachha -
Glen -
mh＠mike.franken.de