[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 <slindomansilla@suse.com> QA Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany https://www.suse.com/ (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
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 <slindomansilla@suse.com> QA Engineer SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany https://www.suse.com/ (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
participants (3)
-
Ignaz Forster -
Oliver Kurz -
Sergio Lindo Mansilla