Many changes today.
zsh autocompletion does not work yet after the rename. [1]
Maybe zsh autocompletion cache needs to be rebuild.
Is there some command that should be run during Debian maintainer postinst script?
[1] Kicksecure ™ Linux Installer - Design Documentation chapter Naming in Kicksecure wiki
I don’t think it is because the name has changed, but because the shell did not load the new completion with the new script.
When installer bash-completion, the shell also has to be reloaded.
I dont know but rehash from the provided answer might be the best solution, but still, it doesn’t load new completions.
hash -r makes the command name completable, but its parameter completions are still missing, despite being added together with the (brew/deb/apk/…) package. The only way I can make it happen is to exit the shell and start a new session.– conny
exec zsh (or exec bash as applicable) to completely reload the shell configuration, but keep the terminal and environment. Exactly what this does to your history (keep recent entries in the same order, or merge in the history from other terminals) depends on the shell configuration.I don’t think exec bash or zsh should be done by the script because if the user $SHELL is Zsh but he is currently using Bash, this causes problem for the script to detect the current shell in use.
I run these commands manually after such changes.
Pushed small fixes to both completions and a typo in the script.
All of this is possible. About uninstallation support…
This is easy for KVM and VirtualBox
Isn’t it better to simply recommend manual steps for this case?
It is possible to be done on the script, we already remove VMs when reimporting them, but uninstallation is not something I see much around this forum. It will add some number of lines but I feel it won’t be used at all, as it is far easier for the user to open virtualbox, right click, remove, confirm than reading the help message or man page and having to run this:
dist-installer-cli --uninstall-vm --guest --interface cli \
--delete-only gateway
While if I allow this kind of option:
dist-installer-cli --uninstall-vm whonix-gateway-xfce
Then it would need to be repeated:
dist-installer-cli --uninstall-vm whonix-gateway-xfce
dist-installer-cli --uninstall-vm whonix-workstation-xfce
dist-installer-cli --uninstall-vm whonix-gateway-cli
dist-installer-cli --uninstall-vm whonix-workstation-cli
dist-installer-cli --uninstall-vm kicksecure-xfce
dist-installer-cli --uninstall-vm kicksecure-cli
And this would break the logic of using
--interface cli|xfce
--guest whonix|kicksecure
--(delete|import)-only gateway|workstation
header package name auto detection: try linux-headers-generic first, then fall back to linux-headers-amd64, then fall back to linux-headers-$(uname -r)
% apt-cache search --names-only --quiet "^linux-headers-generic$"
linux-headers-amd64 - Header files for Linux amd64 configuration (meta-package)
Should not be run by installer-dist-cli. That’s for sure. Does not belong there. Package desktop-config-dist or dist-base-files might be suitable. It could even be argued that it is a missing feature/bug in zsh upstream or in the zsh Debian package. To run such commands but that is more of a general issue and belongs to:
Merged, thanks!
Sure. It’s documented here:
(And can be elaborated if needed.)
Uninstallation isn’t a crucial feature as there’s no demand for it now. Can be revisited later if ever needed.
The added code complexity might indeed make this unjustified.
This is an old idea. Nowadays the way you implemented it such differences such as in package names you defined by operating system specific names (such as Ubuntu vs Debian). Now the correct header package names are already hardcoded. Therefore the header package name auto detection feature doesn’t seem important anymore. Can be moved to rejected features.
Package name looks correct.
Good enough for a generic virtualizer instruction.
Awesome job you guys. I wanted to share someone’s implementation of a KVM import script I found that may be helpful to you when working out support for that hypervisor:
KVM virtual machine image download support is already supported by the installer.
Other KVM support for KVM import etc. is not planned to be implemented by me. KVM support would need to be added by the maintainer of Whonix KVM, which is only you.
This is because if KVM support isn’t added by the maintainer, the KVM specific commands (import, re-import, network setup) done by the installer versus manual import will always be clouded in mystery what the installer actually does versus what not. That is, if there is an issue with KVM, the installer would always be the first suspect as the source of issues.
It might be the installer’s fault or it might not be. But that investigation should be done by the KVM maintainer. And any changes required for the installer, should also be be done by the KVM maintainer.
Especially with multiple operating system support KVM maintenance seems difficult by looking at the KVM sub forums. For example: Unsupported qcow2 feature extended L2 entries
If I added KVM support, it would be almost the same as taking over KVM maintenance, which is too much.
In other words, by adding KVM support to Whonix Linux Installer, you would be effectively “out of the game” for KVM maintenance.
Major Changes in git:
--oracle-repo on Debian testing (trixie) / unstable (sid) because Oracle does not provide such a repository.--dev and if enabling Kicksecure repository, use Kicksecure developers repository instead of Kicksecure stable repository if Kicksecure repository is neededNew installer uploaded and updated wiki to reflect the name change.
now has a logo:
bug:
user.log is empty.