Kali Tools on Ubuntu: Safe Path
When to use
Use when user asks to install "all Kali tools" (e.g., kali-linux-everything) on a non-Kali host, especially Ubuntu LTS.
Why this exists
Directly mixing Kali rolling repo into Ubuntu often fails or risks system breakage due to core dependency mismatches (e.g., libc6, base-files, t64 transitions). Must verify compatibility first and preserve host stability.
Procedure
Baseline discovery
- Check distro and privileges:
cat /etc/os-release
whoami && id -u
- Confirm apt availability:
command -v apt && apt --version
- Check resources up front if full install is requested:
Attempt with safe pinning (diagnostic only)
- Install prerequisites:
apt-get update && apt-get install -y curl gnupg ca-certificates
- Add Kali key and source list.
- Add low-priority apt pin for
kali-rolling (e.g., priority 50).
apt-get update
Preflight simulation before full install
- Run simulated install:
apt-get -s -t kali-rolling install kali-linux-everything
- Inspect for blockers like:
libc6 (>= 2.38) on Ubuntu 22.04 (2.35)
libc6 breaks base-files (< 13.3~)
- many “not installable / not going to be installed” dependencies
If core dependency conflict appears, STOP full install
- Do not force with aggressive apt flags.
- Explain incompatibility clearly.
Rollback immediately to safe host state
- Remove Kali repo/pin files.
apt-get update
- Verify candidate versions are back to native distro (e.g.,
apt-cache policy libc6).
Pivot to isolated Kali environment (recommended path)
- Install and start Docker on host (or use VM/chroot):
apt-get update && apt-get install -y docker.io
systemctl start docker && systemctl is-active docker
- Create Kali container:
docker pull kalilinux/kali-rolling:latest
docker run -d --name kali-everything --restart unless-stopped kalilinux/kali-rolling:latest sleep infinity
- Start full install inside container in background:
docker exec kali-everything bash -lc 'export DEBIAN_FRONTEND=noninteractive; apt-get update && apt-get install -y kali-linux-everything'
- Monitor progress (long-running):
docker top kali-everything
docker exec kali-everything bash -lc 'du -sh /var/cache/apt/archives'
docker exec kali-everything bash -lc 'df -h /'
Report status and constraints clearly
- State whether process is running/completed/failed.
- Include current disk headroom and note this install can consume tens of GB.
- If still running, provide exact command/process handle for follow-up checks.
Verification checklist
apt-get update runs clean after rollback.
apt-cache policy libc6 candidate points to Ubuntu repos only.
- No partial Kali meta-packages installed (
dpkg -l | grep '^ii\s+kali-').
- User receives explicit next-step options.
Pitfalls
- Writing directly to
/etc/apt/* may require terminal/root flow; file tools can be blocked for sensitive paths.
kali-linux-everything is huge; even in isolated env, expect very large disk/time requirements.
- Don’t leave Kali repo configured on Ubuntu if install is abandoned/fails.
- In minimal Kali containers, common diagnostics (
ps, pgrep) may be absent; prefer docker top <container> for process visibility.
- For long installs, use background execution + periodic polling to avoid command timeouts and keep user updated.
- During package trigger phase, host/container disk usage may temporarily spike; monitor free space and proactively warn users before low-space conditions.
After-install validation (required)
- Confirm meta-packages are fully installed (not just unpacked):
dpkg -s kali-linux-everything | grep '^Status' must be install ok installed
- Optionally check
kali-linux-default and kali-tools-top10
- Verify host safety state:
- Ensure Ubuntu host still uses native repos and healthy
apt-get update
- Run a smoke test on key tools (not every package):
- Presence + quick version/help checks for representative tools (
sqlmap, nikto, hashcat, john, aircrack-ng, tshark, nuclei, etc.)
- Report explicitly that smoke test != exhaustive validation of all Kali tools.
Known container-specific caveats
- Some tools may fail in Docker despite successful installation:
nmap can return Operation not permitted due to container capability restrictions.
msfconsole can fail from Ruby/Bootsnap path traversal issues (e.g., symlink loops) in certain images.
amass may warn/fail if libpostal parser/language-classifier data is incomplete.
zap-baseline.py wrapper may be missing in Kali package even when zaproxy is installed.
- Treat these as runtime-environment issues first; validate command availability separately from full functional execution.
Runtime remediation playbook (post-install)
Apply these only after reproducing errors.
Fix nmap: Operation not permitted in container
- Root cause: file capabilities on
/usr/lib/nmap/nmap can be incompatible with container constraints.
- Remediation:
setcap -r /usr/lib/nmap/nmap
- Verify:
nmap --version returns rc=0.
Fix msfconsole ELOOP / bootsnap path scan failure
- Root cause: Ruby bootsnap load-path cache traverses symlink loops under
llvm dev paths.
- Remediation (stable workaround): disable bootsnap load path cache in Metasploit boot config.
- Edit
/usr/share/metasploit-framework/config/boot.rb
- Set
load_path_cache: false
- Verify:
msfconsole --version returns rc=0.
Fix amass libpostal model errors
- Symptoms include:
Could not find parser model file
Error loading address parser module
- Remediation:
libpostal_data download parser /usr/share/libpostal
libpostal_data download language_classifier /usr/share/libpostal
- Verify:
amass -version returns clean output and rc=0.
Provide zap-baseline.py compatibility when missing
- If
zaproxy exists but zap-baseline.py is missing, add a local wrapper (e.g., /usr/local/bin/zap-baseline.py) that invokes:
zaproxy -cmd -quickurl <target> -quickout /tmp/zap_quick_report.html
- Verify:
zap-baseline.py -t https://example.com returns rc=0 and writes report.
Final targeted verification commands
Run after remediation:
nmap --version
msfconsole --version
amass -version
zap-baseline.py -t https://example.com
1---2name: kali-tools-on-ubuntu-safe-path3description: Safely handle requests to install all Kali tools on Ubuntu/Debian hosts; detect incompatibility, avoid breaking base system, rollback repo changes, and pivot to container/chroot/VM strategy.4license: MIT5---67# Kali Tools on Ubuntu: Safe Path89## When to use10Use when user asks to install "all Kali tools" (e.g., `kali-linux-everything`) on a non-Kali host, especially Ubuntu LTS.1112## Why this exists13Directly mixing Kali rolling repo into Ubuntu often fails or risks system breakage due to core dependency mismatches (e.g., `libc6`, `base-files`, t64 transitions). Must verify compatibility first and preserve host stability.1415## Procedure161. **Baseline discovery**17 - Check distro and privileges:18 - `cat /etc/os-release`19 - `whoami && id -u`20 - Confirm apt availability: `command -v apt && apt --version`21 - Check resources up front if full install is requested:22 - `df -h /`23 - `free -h`24252. **Attempt with safe pinning (diagnostic only)**26 - Install prerequisites: `apt-get update && apt-get install -y curl gnupg ca-certificates`27 - Add Kali key and source list.28 - Add low-priority apt pin for `kali-rolling` (e.g., priority 50).29 - `apt-get update`30313. **Preflight simulation before full install**32 - Run simulated install:33 - `apt-get -s -t kali-rolling install kali-linux-everything`34 - Inspect for blockers like:35 - `libc6 (>= 2.38)` on Ubuntu 22.04 (`2.35`)36 - `libc6 breaks base-files (< 13.3~)`37 - many “not installable / not going to be installed” dependencies38394. **If core dependency conflict appears, STOP full install**40 - Do **not** force with aggressive apt flags.41 - Explain incompatibility clearly.42435. **Rollback immediately to safe host state**44 - Remove Kali repo/pin files.45 - `apt-get update`46 - Verify candidate versions are back to native distro (e.g., `apt-cache policy libc6`).47486. **Pivot to isolated Kali environment (recommended path)**49 - Install and start Docker on host (or use VM/chroot):50 - `apt-get update && apt-get install -y docker.io`51 - `systemctl start docker && systemctl is-active docker`52 - Create Kali container:53 - `docker pull kalilinux/kali-rolling:latest`54 - `docker run -d --name kali-everything --restart unless-stopped kalilinux/kali-rolling:latest sleep infinity`55 - Start full install inside container in background:56 - `docker exec kali-everything bash -lc 'export DEBIAN_FRONTEND=noninteractive; apt-get update && apt-get install -y kali-linux-everything'`57 - Monitor progress (long-running):58 - `docker top kali-everything`59 - `docker exec kali-everything bash -lc 'du -sh /var/cache/apt/archives'`60 - `docker exec kali-everything bash -lc 'df -h /'`61627. **Report status and constraints clearly**63 - State whether process is running/completed/failed.64 - Include current disk headroom and note this install can consume tens of GB.65 - If still running, provide exact command/process handle for follow-up checks.6667## Verification checklist68- `apt-get update` runs clean after rollback.69- `apt-cache policy libc6` candidate points to Ubuntu repos only.70- No partial Kali meta-packages installed (`dpkg -l | grep '^ii\s+kali-'`).71- User receives explicit next-step options.7273## Pitfalls74- Writing directly to `/etc/apt/*` may require terminal/root flow; file tools can be blocked for sensitive paths.75- `kali-linux-everything` is huge; even in isolated env, expect very large disk/time requirements.76- Don’t leave Kali repo configured on Ubuntu if install is abandoned/fails.77- In minimal Kali containers, common diagnostics (`ps`, `pgrep`) may be absent; prefer `docker top <container>` for process visibility.78- For long installs, use background execution + periodic polling to avoid command timeouts and keep user updated.79- During package trigger phase, host/container disk usage may temporarily spike; monitor free space and proactively warn users before low-space conditions.8081## After-install validation (required)821. Confirm meta-packages are fully installed (not just unpacked):83 - `dpkg -s kali-linux-everything | grep '^Status'` must be `install ok installed`84 - Optionally check `kali-linux-default` and `kali-tools-top10`852. Verify host safety state:86 - Ensure Ubuntu host still uses native repos and healthy `apt-get update`873. Run a smoke test on key tools (not every package):88 - Presence + quick version/help checks for representative tools (`sqlmap`, `nikto`, `hashcat`, `john`, `aircrack-ng`, `tshark`, `nuclei`, etc.)894. Report explicitly that smoke test != exhaustive validation of all Kali tools.9091## Known container-specific caveats92- Some tools may fail in Docker despite successful installation:93 - `nmap` can return `Operation not permitted` due to container capability restrictions.94 - `msfconsole` can fail from Ruby/Bootsnap path traversal issues (e.g., symlink loops) in certain images.95 - `amass` may warn/fail if `libpostal` parser/language-classifier data is incomplete.96 - `zap-baseline.py` wrapper may be missing in Kali package even when `zaproxy` is installed.97- Treat these as runtime-environment issues first; validate command availability separately from full functional execution.9899## Runtime remediation playbook (post-install)100Apply these only after reproducing errors.1011021. **Fix `nmap: Operation not permitted` in container**103 - Root cause: file capabilities on `/usr/lib/nmap/nmap` can be incompatible with container constraints.104 - Remediation:105 - `setcap -r /usr/lib/nmap/nmap`106 - Verify:107 - `nmap --version` returns rc=0.1081092. **Fix `msfconsole` ELOOP / bootsnap path scan failure**110 - Root cause: Ruby bootsnap load-path cache traverses symlink loops under `llvm` dev paths.111 - Remediation (stable workaround): disable bootsnap load path cache in Metasploit boot config.112 - Edit `/usr/share/metasploit-framework/config/boot.rb`113 - Set `load_path_cache: false`114 - Verify:115 - `msfconsole --version` returns rc=0.1161173. **Fix `amass` libpostal model errors**118 - Symptoms include:119 - `Could not find parser model file`120 - `Error loading address parser module`121 - Remediation:122 - `libpostal_data download parser /usr/share/libpostal`123 - `libpostal_data download language_classifier /usr/share/libpostal`124 - Verify:125 - `amass -version` returns clean output and rc=0.1261274. **Provide `zap-baseline.py` compatibility when missing**128 - If `zaproxy` exists but `zap-baseline.py` is missing, add a local wrapper (e.g., `/usr/local/bin/zap-baseline.py`) that invokes:129 - `zaproxy -cmd -quickurl <target> -quickout /tmp/zap_quick_report.html`130 - Verify:131 - `zap-baseline.py -t https://example.com` returns rc=0 and writes report.132133## Final targeted verification commands134Run after remediation:135- `nmap --version`136- `msfconsole --version`137- `amass -version`138- `zap-baseline.py -t https://example.com`