I had issues with this for several releases now, although I never got a
broken upgrade like you're reporting: every time so far I got a message
'you need additional 4GB on /' before the actual upgrade started. It
would be sad if the free space estimation code didn't work and allowed
broken, half-upgraded systems!!
Unfortunately, I believe that the current upgrade workflow requires a
root disk three times the total installed package size: each package is
there as the original version, the RPM of the upgrade in the cache
directory, and as a new image before the old one is purged.
There's an install-time option --destdir to store the new release RPM
collection on a separate volume, but it used to not work.
https://bugzilla.redhat.com/show_bug.cgi?id=1513823
I see that it is marked as resolved, but I vaguely remember having
problems with it still.
I just got used to deleting few largest packages (wine-core kicad
FlightGear :) and reinstalling them after the upgrade. I actually
benefited from this discipline: I used to have a ton of debuginfo/source
packages that are no longer necessary, and this forced me to look into
and delete them.
On 5/13/22 14:54, Jason L Tibbitts III wrote:
So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
as part of my usual testing. In the middle of the process, it appears
that /var filled up and that left the system in an unfortunate state.
Surprisingly (to me) it did boot with a random mix of F35 and F36
packages and even though it's a throwaway test box, I wanted to play
around with fixing it a bit and trying to understand why it ran out of
space instead of just reinstalling.
Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates"
was able to effectively everything in the system, and while running this
/var filled up again. When that happened, dnf couldn't even be aborted;
I had to kill -9. The culprit is the write-ahead log,
/var/lib/rpm/rpmdb.sqlite-wal. I resized /var and reran, and by the end
of the process had grown to over 9GB:
-rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal
Of course it immediately went to 0 once the transaction completed,
though rpmdb.sqlite went from:
-rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite
to
-rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite
which seems... odd for what's effectively just reinstalling the existing
package set.
Anyway, obviously the solution is to make sure that /var is "big enough"
before you do a system upgrade. And we do have warnings about
filesystems being too small, but nothing about needing an extra 10GB for
this. Certainly my case might be somewhat pathological and it was good
that in the end I was able to get the system back into a useful state
without wiping it. But in the end I wonder:
1) Is it really expected that the wal file will grow to that size?
2) Is there anything to be done to reduce the size of the log?
3) Is there any better way to handle a lack of space in /var during an
RPM transaction?
4) Can we estimate how large the file will grow, and refuse to start a
system upgrade if there is not enough space? Certainly we already do
this to some degree, but it seems that the estimate of the required
space is a bit too small.
- J<
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bQ6JeyOsZ3DL%2B0qW077BKfkYciUicGcoTBJKt0kYNtg%3D&reserved=0
List Guidelines: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oYtihVLX1JB5uOAS4k57fiW9a2b3LJnNvMRdtgd7ziE%3D&reserved=0
List Archives: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fdevel%40lists.fedoraproject.org&data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KfK7qrPSeyT2D%2FjI40DWG%2B%2FoU6z7AO1cSnG60oKNCCw%3D&reserved=0
Do not reply to spam on the list, report it: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructure&data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Cd6fef0708ded409a2c0008da3512152b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637880649029987411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aBIB8HiRHVvdVjGaiQBbFgkZb2gUEPcrpH%2Buji2chsw%3D&reserved=0
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
