Refactor tik #62
Open
Refactor tik #62
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Common functionality from post modules got their own module reducing code duplication. The code is now also reorganized as we differentiate between functions called exclusively by tik itself and functions called by its modules.
The mount/unmount functions now use the fstab of the final installed system to determine mount options and what to mount. Special cases like bind mounts or overlay mounts are handled as well. The root filesystem is mounted temporarily to get its mount correct options. The sicu module doesn't rewrite fstab anymore.
When /etc/fstab.repart exists, it is now used as fstab file. After the system is installed, a special /etc/fstab.tik file can be used to inject or override fstab entries systemd-repart couldn't generate. It is expected that this file exists in the installed system right after deployment and before any post module runs.
This allows assembling the fstab even if /etc of the installed is read only. When the fstab is completely assembled, its mounts are applied and the fstab copied over to the installed system, if possible. If not, it is kept so e.g. post modules can handle it.
In selfinstall mode, systemd-repart writes /etc/fstab.repart to the host's filesystem, so it needs to be removed if it exists before installation or systemd-repart will fail..
The fstab shouldn't contain any secrets, so it's safe to make it world-readable. Since the fstab.repart file is only readable by root, it needs to be handled with root permissions.
For example, ro=vfs or ro are not wanted during installation as they break chroot operations. This also further fixes permission issues
Also stick to aeon_root for now
The name of the to be installed system is now automatically discovered, unless explicitely provided thrugh the config. For self deploy mode, /etc/os-release of the current system is read and ID and PRETTY_NAME are used. For raw images, Tik will try to read /etc/os-release to get these information or derive them from the image name after a 1s timeout/failure. The name from the images is only used if it is the same for all images available for tik. This minimized aeon-specific code in tik-core and tik-functions
I accidentally removed the mount_etc_for_root function earlier, but it's still required by the mig modules. So here it is. Also, XDG_SESSION is never used, so I assume XDG_SESSION_TYPE was meant instead.
This allows further reusability, so the mount/unmount functions can be used to mount/unmount the old system in the pre/20-mig module.
The migration module assumes BTRFS quotas are enabled, which might not be always the case. This also let's the mig modules use the global progress pipe instead of opening a pulsateing progress window.
Now that all functionality is implemented, it needed to be refactored to make it more maintainable, easier to understand and easier to read. In optional mode, not unlocking an encrypted partition no longer stops the complete operation and all (encrypted) partition on a disk are now checked for a root partition. probe_partitions also stops now after finding the first match.
Otherwise it won't check regular partitions when there is 1 encrypted partition.
We can use the symbolic icon symlink instead of hardoding Aeon's icon
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enhances TIK by making it able to automatically mount a detected system on a disk by evaluating its fstab file. It also now has a shared progress bar for modules and allows modules to mount additional directories etc. using TIK functions. TIK is also able to assemble the fstab for an installed system now using the existing fstab or fstab.repart and a special fstab.tik to add or override entries. TIK is also not using hardcoded "Aeon" strings anymore and auto-detecting the identity of the to-be-installed system if not set explicitely.
The code is also reorganized now by differentiating between functions TIK calls itself (core) and their helpers and functions modules call (and their helpers).
These changes overall make module development way easier and let them focus on their actual task instead of having to handle e.g. mounting/unmounting on their own.