Troubleshooting

From Kicksecure

Troubleshooting-114197640.jpg

Connectivity Troubleshooting | General Troubleshooting

Connectivity Troubleshooting[edit]

ICMP Fix[edit]

info Note: Kicksecure firewall does not exist yet at time of writing.

Therefore no such fix required yet.

Qubes-specific Connectivity Issue[edit]

Complete the following steps:

  1. Shut down kicksecure.
  2. Change the kicksecure NetVM setting from sys-firewall to sys-net.
  3. Restart kicksecure.

This procedure might help, but should not be considered a final solution. [1]

Why can't I Ping the Kicksecure ™?[edit]

info Note: Kicksecure firewall does not exist yet at time of writing.

The Kicksecure ™ does not respond to ping or similar commands because it is firewalled for security reasons; see /usr/bin/kicksecure_firewall or refer to the Kicksecure ™ source code. In most cases it is unnecessary to ping the Kicksecure ™ anyhow.

If you insist on pinging the Kicksecure ™ or have a unique setup that requires it, then this can be tested by clearing all firewall rules with the dev_clearnet script. Alternatively, a script can be run to try and unload / remove every iptables rule, or the Kicksecure ™ firewall can be hacked to not load at all. The latter method is only for experts and it is necessary to comment out exit 0 at the beginning.


General Troubleshooting[edit]

Introduction[edit]

Troubleshooting issues can be time intensive and success cannot be guaranteed. Some users expect Kicksecure ™ to provide an easy experience. While the Kicksecure ™ developers make every effort to meet user expectations, limited funding and human resources makes meeting these expectations impossible.

Even though problems emerge when using Kicksecure ™, the cause is most often unrelated to Kicksecure ™ code. For example, users often report the same Kicksecure ™ release worked on different hardware and/or with a different host operating system. Most software such as the host operating system or the virtualizer is developed by independent entities; this is the norm in Linux distributions. See Linux User Experience versus Commercial Operating Systems to learn more about these relationships, as well as organizational and funding issues in the Open Source ecosystem.

Essential General Troubleshooting Steps[edit]

info The following recommended steps will fix many startup, freezing or other unusual issues in Kicksecure ™. Skips steps that are no longer possible if a virtual machine is not bootable.

1. "Forget" about Kicksecure ™ for a moment and imagine you had never heard of the platform. Test your host computer first.

2. Exclude basic hardware issues.

3. Ensure the virtual machine (VM) images have been imported into a supported virtualizer listed on the Download page.

4. Debian (based) Linux host operating system users only: The following command should not show any errors. [2]

sudo dpkg-reconfigure -a

5. Debian (based) Linux host operating system users only: The following command should be silent and not show any errors or output at all. [2]

sudo dpkg --configure -a

6. Debian (based) Linux host operating system users only: Next attempt to retrieve all available updates.

sudo apt update

sudo apt full-upgrade

7. Check for possible Low RAM Issues.

8. Virtualizer-specific troubleshooting.

9. Check if other VMs are functional, such as newly created ones or those from a different vendor.

  1. "Forget" about Kicksecure ™ for a moment and imagine you had never heard of the platform. Test the virtualizer host software first.
  2. Try a VM other than Kicksecure ™ such as Debian bullseye.
  3. If the issue persists, this means the root issue is not caused by Kicksecure ™, see: unspecific to Kicksecure ™. In this case, attempt to resolve the issue as per Free Support Principle.

10. Check System Logs.

11. If a graphical environment (where one can use a computer mouse) is unavailable after booting, utilize a virtual console to acquire system logs.

  1. Recovery, Virtual Consoles.
  2. Check system logs of the previous boot (step 10).

12. Use recovery mode to acquire system logs.

  1. Boot in recovery mode.
  2. Check system logs of previous boot (step 10).

13. Use a chroot to acquire system logs.

If a virtual console is inaccessible and recovery mode is also broken, try using a chroot for recovery.

Low RAM Issues[edit]

If insufficient RAM is available for Kicksecure ™ VM they might become unusable. Low RAM issues in Kicksecure ™ are commonly caused by:

  • Unnecessary processes running and/or multi-tasking on the host OS.
  • Multiple, open browser tabs.
  • Unnecessary processes running in the Kicksecure ™ VM.
  • Allocating more RAM to the Kicksecure ™ VM than is available; this prevents the VM from booting.
  • Insufficient RAM allocated to the Kicksecure ™ VM.
  • Other non-Kicksecure ™ VM running in parallel.

Insufficient RAM can cause multiple issues, but the most common effects include:

  • Slow or unresponsive applications.
  • The VM, mouse and/or keyboard freeze.
  • Scrolling causes window staggers or jumps.
  • Issues become worse when additional browser tabs or processes are spawned.
  • Overall performance is poor.

See also: Advice for Systems with Low RAM.

Free up Additional Memory Resources[edit]

If a VM needs additional memory, then free up resources and/or add more RAM to the VM:

  • Terminate any non-essential processes on the host.
  • Shut down any non-essential VM.
  • Shut down and/or close non-essential processes and browser tabs in Kicksecure ™ VM.

To add additional RAM to the Kicksecure ™ VM, follow the platform-specific advice below.

KVM[edit]

1. Shutdown the virtual machine(s).

virsh -c qemu:///system shutdown <vm_name>

2. Increase the maximum memory.

virsh setmaxmem <vm_name> <memsize> --config

3. Set the actual memory.

virsh setmem <vm_name> <memsize> --config

4. Restart the virtual machine(s).

virsh -c qemu:///system start <vm_name>

Kicksecure ™ for Qubes[edit]

Utilize Qube Manager:

  • Qube ManagerVM_nameQubes settingsAdvancedMax memory: mem_size

VirtualBox[edit]

  1. To add RAM in VirtualBox the VM must first be powered down.
  2. Virtual machineMenuSettingsAdjust Memory sliderHit: OK

See also: VirtualBox/Troubleshooting.

System Logs[edit]

[3]

Check Systemd Journal Log of Current Boot[edit]

To inspect the systemd journal log of the current boot, run.

sudo journalctl -b

This command requires pressing arrow keys like ↑, ↓, ←, →, as well as PgUp and PgDn for scrolling.

For convenient reading of the log (until the command is issued), the log can be dumped to file. For example, the following command would write the log to file ~/systemd-log.

sudo journalctl -b > ~/systemd-log

Use any available editor to read the log file, such as mousepad.

mousepad ~/systemd-log

Watch Systemd Journal Log of Current Boot[edit]

It is possible to to watch the systemd journal log as it is written.

sudo journalctl -b -f

Enable Persistent Systemd Journal Log[edit]

By default, a persistent systemd journal log is not enabled in Debian. [4] To enable it, apply the following steps.

Platform specific notes:

  • Kicksecure ™ non-Qubes: No special steps are required; follow the steps below.
  • Qubes users: The following changes must be applied in a VM with a persistent root image like a Template or Standalone. It could be confusing if applied in App Qubes since the systemd journal log might be mixed up with boots by the Template, while the App Qube systemd journal logs would not be persistent. bind-dirs might be helpful, but further research is required.

1. Create folder /etc/systemd/journald.conf.d.

sudo mkdir -p /etc/systemd/journald.conf.d

2. Open file /etc/systemd/journald.conf.d/60_persistent_journal.conf in an editor with root rights.

(Kicksecure ™ inside Qubes: In Template)

This box uses sudoedit for better security. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Kicksecure ™, please refer to this link.

sudoedit /etc/systemd/journald.conf.d/60_persistent_journal.conf

3. Add the following setting.

[Journal] Storage=persistent

Save.

4. Restart systemd-journald.

sudo systemctl restart systemd-journald

A persistent systemd journal log has now been enabled.

Check Systemd Journal Log of Previous Boot[edit]

After following the Enable Persistent Systemd Journal Log steps, it is possible to inspect the systemd journal log of the previous boot.

sudo journalctl -b -1

This command requires pressing arrow keys like ↑, ↓, ←, →, as well as PgUp and PgDn for scrolling.

For convenient reading of the log (until the command is issued), the log can be dumped to file. For example, the following command would write the log to file ~/systemd-log-previous.

sudo journalctl -b -1 > ~/systemd-log-previous

Use any available editor to read the log file, such as mousepad.

mousepad ~/systemd-log-previous

View List of Systemd Journal Logs[edit]

sudo journalctl --list-boots

Daemon Log View[edit]

To view the log of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo journalctl -b --no-pager -u unit-name

Example:

sudo journalctl -b --no-pager -u sdwdate

Daemon Log Follow[edit]

To follow the log of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo journalctl -f -b --no-pager -u unit-name

Example:

sudo journalctl -f -b --no-pager -u sdwdate

Daemon Status[edit]

To view the status of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo systemctl status --no-pager unit-name

Example:

sudo systemctl status --no-pager sdwdate

Check Systemd Journal Log of Failed Boot[edit]

An alternative to recovery mode might be virtual consoles, since they are an easier and more lightweight solution. A virtual console login might still be possible when the graphical user interface no longer starts.

Prerequisite knowledge: Virtual Consoles. Try to log in to a virtual console in a functional VM as an exercise. If that works, try a virtual console login in the broken VM.

If a virtual console is unavailable:

  1. Boot into Recovery Mode.
  2. Enable Persistent Systemd Journal Log (if not previously enabled).
  3. Reboot into normal mode so a log for the failed boot will be written (if not previously enabled).
  4. Boot into recovery mode again.
  5. Check Systemd Journal Log of Previous Boot.

Permission Fix[edit]

info If something does not work, do not arbitrarily try to use sudo / root without any indication this is appropriate. Otherwise, this can negatively affect the correct user home folder permissions. See also: Safely Use Root Commands.

Open a terminal.

If you are using Kicksecure ™ inside Qubes, complete the following steps.

Qubes App Launcher (blue/grey "Q")Kicksecure ™ App Qube (commonly named kicksecure)Xfce Terminal

If you are using a graphical Kicksecure ™ with XFCE, run.

Start MenuXfce Terminal

sudo chown --recursive user:user /home/user

Hardware Issues[edit]

General Recommendations[edit]

Rhetorical questions:

  • When was the last time a qualified person disassembled your computer/notebook and removed dust from the fan and checked the cooling system of the CPU?
  • How often should maintenance be performed?
  • What is your CPU temperature under heavy system load?
  • What is the room temperature where the computer is operating?

Recommendations:

  • Ensure your computer or notebook has regular, proper maintenance.
  • Monitor CPU temperature by utilizing relevant host operating system tools.
  • Consider cooling the room where computers/notebooks operate.
  • Better placement (more air space) around computers or notebooks can help.
  • Consider a passive or active (notebook) cooling pad. [5]
  • Run memtest86+ to rule out RAM problems.

None of these issues are related to Kicksecure ™. Therefore, please do not ask these questions in Kicksecure ™ support channels (until there is a Kicksecure ™ Host DVD available) as per Free Support Principle.

memtest86+[edit]

1. Install the memtest86+ tool.

On Debian (based) hosts such as Kicksecure.

Install memtest86+. To accomplish that, the following steps A. to D. need to be done.

A. Update the package lists.

sudo apt update

B. Upgrade the system.

sudo apt full-upgrade

C. Install the memtest86+ package.

Using apt command line parameter --no-install-recommends is in most cases optional.

sudo apt install --no-install-recommends memtest86+

D. Done.

The procedure of installing memtest86+ is complete.

For other host operating systems, refer to memtest86+ upstream documentation.

2. Reboot.

3. Start memtest86+ from (grub) boot menu.

4. Keep memtest86+ running for a significant period.

This should be run for as long as practically possible; for example, ideally overnight or for 8+ hours.

5. Check the memtest86+ output.

If there are any issues, red error messages appear in the middle of the screen.

6. Done.

The memory test is complete.

If memtest86+ identified any issues, these can manifest in various ways such as system crashes at random times. In such cases, the only likely solution is replacing the faulty hardware (RAM banks). [6]

See Also[edit]

Footnotes[edit]

  1. This procedure was useful for Kicksecure ™ for Qubes R3.2 users, although the Qubes bug report is now resolved: https://github.com/QubesOS/qubes-issues/issues/2141
  2. 2.0 2.1 This process can be lengthy.
  3. "user support template": https://forums.whonix.org/t/workstation-keeps-freezing/7693/6
  4. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801906
  5. Perform thorough research beforehand.
  6. RAM bank warranties may apply.


Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.