Release disk and validation test fixes #218
Conversation
focus-shift based navigation was only added after 2024.7.0
Earlier release disk build had a critical problem: the built disk would have optimized partition sizes based on the current system's image size. This meant that newer releases would potentially not fit in the system partition if they increase in size. To avoid this issue, we create disk images which have system partition sizes equal to (default PlayOS size - 1 GiB). The 1GiB is subtracted as a safety threshold to avoid releasing something that is very near max capacitiy. This gets rid of the extra top-level `extraModules` argument in default.nix along the way.
|
Found a bug in the release workflow due to shallow git checkout, fixed in 75f4a5f. Preview backported 2024.7.0 release: https://github.com/dividat/playos/releases/tag/2024.7.0-DISK |
| system = 1024 * 9; # 9 GiB (install-playos default - 1GiB) | ||
| data = 400; # 400 MiB (same as testing/disk/default.nix) | ||
| }; | ||
| diskSizeMiB = 8 + partSizes."boot" + partSizes."data" + (partSizes."system" * 2) + 1; |
There was a problem hiding this comment.
In testing/disk/default.nix, diskSizeMiB is:
diskSizeMiB = 10 + bootPartSizeMiB + dataPartSizeMiB + systemPartSizeMiB*2;Is there a reason to have 9 additional MiB here, and 10 in the other file?
There was a problem hiding this comment.
Actually, I am not sure why I set it to 10 in testing/disk/default.nix - probably did it without much thought.
Here the +8MiB and +1MiB match the initial disk alignment sector size and extra space requirements as defined in install-playos.py.
There was a problem hiding this comment.
Should we update testing/disk/default.nix and use the same logic, using 8 + … + 1?
There was a problem hiding this comment.
I can do it in a separate PR, it is not related to these changes.
guyonvarch
added
details needed
yfyf
added
reviewable
While backporting release disk to 2024.7.0 I realized the approach had a critical issue: the built disk would have optimized partition sizes based on the current system's image size. This meant that newer releases would potentially not fit in the system partition if they increase in size.
At first I attempted introducing various flag combos to the existing
disktarget to overcome this, but it became very confusing. So I decided it's best to split release-disk into a separate target. See the commit 46aced3 message for details.I managed to also get rid of the top-level
extraModules.See also the PR for the backport of
./build release-diskto 2024.7.0: #217Checklist