[opensuse-factory] Upgrade tests from Leap 42.3 to Tumbleweed were using an old disk image without latest updates
Hi all,
I am working on https://progress.opensuse.org/issues/39305
I have succesfuly create the qcow2 images with Leap 42.3 + latest
updates to be use for upgrade scenarios to Tumbleweed:
- GNOME: https://openqa.opensuse.org/tests/1056940
- HDD_1: opensuse-42.3-x86_64-GM-latest-updates-gnome@64bit.qcow2
- KDE: https://openqa.opensuse.org/tests/1056103
- HDD_1: opensuse-42.3-x86_64-GM-latest-updates-kde@64bit.qcow2
- KDE+system_performance: https://openqa.opensuse.org/tests/1055618
- HDD_1: opensuse-42.3-x86_64-GM-latest-updates-kde@64bit.qcow2
I am having the problem of the /var directory being yet included in the
BTRFS root module and therefore taking a lot space on the upgrade
snapshots.
For kryptlvm scenarios those symptoms cause the test to fail on
matching needles, since notification of "Low Disk Space.." are shown
sporadically during the test.
The disk images are using 40GB.
I have two ideas to avoid this problem. One is increasing the disk
image up to 50GB for those two specific scenarios "Leap 42.3 + cryptlvm
upgrade to Tumbleweed, 64bit (BIOS/legacy) or UEFI":
- https://openqa.opensuse.org/tests/1055631#step/first_boot/2
- https://openqa.opensuse.org/tests/1055632#step/first_boot/2
That would mean that the recommended hard disk size to upgrade from
Leap 42.3 to Tumbleweed would be 50GB.
Anyway, I would recommend to anyone having the old BTRFS partition
schema (pre-Leap15) to perform a new installation with the new
partitioning schema, since the old one will still give a lot of space
problems.
Here is a verification run using a 50GB virtual disk:
- https://openqa.opensuse.org/tests/1058471
The other solution would be to delete the upgrade snapshot with snapper
on the test module first_boot, and perform the "cleanup BTRFS tasks" to
free the space.
Any opinion on that? Are you ok with using 50GB for those and only
those two specific scenarios?
Kind Regards
--
Sergio Lindo Mansilla
On Thursday, 17 October 2019 09.28.06 CEST Sergio Lindo Mansilla wrote:
Hi all,
I am working on https://progress.opensuse.org/issues/39305 […] I am having the problem of the /var directory being yet included in the BTRFS root module and therefore taking a lot space on the upgrade snapshots. For kryptlvm scenarios those symptoms cause the test to fail on matching needles, since notification of "Low Disk Space.." are shown sporadically during the test. The disk images are using 40GB.
I have two ideas to avoid this problem. One is increasing the disk image up to 50GB for those two specific scenarios "Leap 42.3 + cryptlvm upgrade to Tumbleweed, 64bit (BIOS/legacy) or UEFI":
- https://openqa.opensuse.org/tests/1055631#step/first_boot/2 - https://openqa.opensuse.org/tests/1055632#step/first_boot/2
[…] The other solution would be to delete the upgrade snapshot with snapper on the test module first_boot, and perform the "cleanup BTRFS tasks" to free the space.
Any opinion on that? Are you ok with using 50GB for those and only those two specific scenarios?
The bigger HDD size is better than nothing but I like the approach to manually delete a snapshot. After all, when "successfully booted" into the upgraded system that might just be enough to delete the snapshot in a valid, realistic user scenario. But also, have you considered https://en.opensuse.org/SDB:System_upgrade#3._Move_.2Fvar.2Fcache_to_a_separ... ? Would be great to see this covered in the upgrade scenarios as well and should be straight-forward to automate. Have fun, Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Sergio, Am 17.10.19 um 23:31 Uhr schrieb Oliver Kurz:
On Thursday, 17 October 2019 09.28.06 CEST Sergio Lindo Mansilla wrote:
Hi all,
I am working on https://progress.opensuse.org/issues/39305 […] I am having the problem of the /var directory being yet included in the BTRFS root module and therefore taking a lot space on the upgrade snapshots.
I'm wondering what's taking all the space there, as the usual suspects like /var/cache and /var/log should have their own subvolume an 42.3 already...
For kryptlvm scenarios those symptoms cause the test to fail on matching needles, since notification of "Low Disk Space.." are shown sporadically during the test. The disk images are using 40GB.
I have two ideas to avoid this problem. One is increasing the disk image up to 50GB for those two specific scenarios "Leap 42.3 + cryptlvm upgrade to Tumbleweed, 64bit (BIOS/legacy) or UEFI":
- https://openqa.opensuse.org/tests/1055631#step/first_boot/2 - https://openqa.opensuse.org/tests/1055632#step/first_boot/2
[…] The other solution would be to delete the upgrade snapshot with snapper on the test module first_boot, and perform the "cleanup BTRFS tasks" to free the space.
Any opinion on that? Are you ok with using 50GB for those and only those two specific scenarios?
The bigger HDD size is better than nothing but I like the approach to manually delete a snapshot. After all, when "successfully booted" into the upgraded system that might just be enough to delete the snapshot in a valid, realistic user scenario. But also, have you considered https://en.opensuse.org/SDB:System_upgrade#3._Move_.2Fvar.2Fcache_to_a_separ... ? Would be great to see this covered in the upgrade scenarios as well and should be straight-forward to automate.
All three options sound perfectly fine to me. But as we still support the old subvolume layout we may want to explicitly test that, so I'd personally go with the "delete the snapshot manually" approach. Cheers, Ignaz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Thanks for your feedback. I will then implement both solution into the main job group. El jue, 17-10-2019 a las 23:31 +0200, Oliver Kurz escribió:
But also, have you considered https://en.opensuse.org/SDB:System_upgrade#3._Move_.2Fvar.2Fcache_to_ a_separate_subvolume ? Would be great to see this covered in the upgrade scenarios as well and should be straight-forward to automate.
I haven't, but I will check if Leap 42.3 is affected. El vie, 18-10-2019 a las 13:28 +0200, Ignaz Forster escribió:
I'm wondering what's taking all the space there, as the usual suspects like /var/cache and /var/log should have their own subvolume an 42.3 already...
I will check.
Kind Regards and nice weekend
--
Sergio Lindo Mansilla
participants (3)
-
Ignaz Forster -
Oliver Kurz -
Sergio Lindo Mansilla