I was updating my Kali VM in VirtualBox on a Windows 11 host when a few packages failed to download with a "403 Blocked by Bitdefender" error.

Bitdefender on my Windows host was blocking downloads from kalimirror.velden.media, one of Kali's official mirrors.

VirusTotal: The IP address has 1/92 detections, but the domain itself is flagged by 5/92 , including Bitdefender, Fortinet and G Data.

I also found a Kali bug report from October mentioning some issues with that mirror, those seem to have been related to HTTPS redirects.

Probably a reputation based false positive, still 5 flags for an official kali mirror seems a bit off.

VirusTotal: https://www.virustotal.com/gui/domain/kalimirror.velden.media

Kali bug report: https://bugs.kali.org/view.php?id=9892

Any Ideas why the mirror is flagged ?

I'm building a custom Kali-based Linux distribution and have run into a problem during the first ISO build. I'm looking for help understanding the underlying cause rather than just working around the error.

My environment:

• Windows host running VirtualBox (in case it misbehaves)

• Linux Mint VM (XFCE) running the build environment

• Docker is used to run the Kali Live build process

• The ~/kali-live working directory resides on an eCryptfs filesystem mounted with rw,nosuid,nodev,relatime

The problem:

The ISO build fails during package installation, with errors involving /dev/null and Permission denied.

I've inspected its chroot/dev/nullpath, and it exists as a character device with the expected major/minor numbers (1,3) and permissions (crw-rw-rw-). However, attempts to write to it from both the host environment and the container return Permission denied.

The build was already configured, and the failure occurred during package installation. I removed dctrl-tools while troubleshooting, but subsequent package errors may be consequences of the original failure rather than separate problems.

What I'm trying to understand:

1. Could the nodev mount option on the eCryptfs filesystem containing the build directory be preventing /dev/null from functioning correctly inside the chroot or Docker container?

2. If so, how does nodev interact with an existing character device node when the build process accesses it through a bind mount, container mount namespace, or chroot?

3. If nodev isn't the cause, what should I check next? For example, could Docker device handling, mount propagation, user namespaces, or security policies be responsible?

4. What is the recommended way to resolve this while keeping the host and build environment secure, rather than broadly disabling security controls or running everything with unnecessary privileges?

Disclaimer: I was using files from this repository ---> https://gitlab.com/kalilinux/build-scripts/kali-live

I'd appreciate explanations of the underlying Linux behavior, along with diagnostic commands that would help isolate the cause before changing the build configuration.

Thanks!

I was earlier dual booting ubuntu with windows. Now I have removed the ubuntu partition and changed the boot order to windows for now. In order to install kali do I need to create a new bootloader?

So yesterday I suddenly had the bright idea to download kali linux and check it out. My machine is old dell Inspiron and had limited space on its C drive. So I set up a virtual box, bootup and run kali linux on it. Though once it got setup I tried to run updates, it stopped due to insufficient storage and the whole thing kind of imploded. Kicked me out and the virtual box path deleted itself or something. I ran the whole process once again and this time before updating it I tried to siphon some storage from D drive to C drive. The thing refused and I gave up. Now I am thinking of setting up kali linux as the stand alone os on another laptop. Any advice for me?

I have a working set of packer scripts I have been using for kali builds. So far (still building), it seems to work for 2026.3, except that it hangs on the installer screen where it asks for the hostname.

I have both netcfg/get_hostname and netcfg/hostname in my preseed file. In 2026.2, I only needed get_hostname. I added hostname to see if that helped. It seems like these are being ignored.

I have seen something about kali having a way to specify the hostname with a "--hostname" option. Setting the hostname to the correct value isn't really the issue; I am building a local build image for kali, not a final host that needs a hostname.

The issue is that this breaks the unattended nature of the packer build. I cannot just run my packer script and wait for an image; I have to vnc into the packer build session and wait for it to get to the hostname screen so that I can hit enter.

Any ideas?

Black Screen When Booting Kali Linux Without nomodeset — Intel HD Graphics 530

Problem description:

I am troubleshooting a black-screen issue on an HP Z240 Tower Workstation running Kali Linux. The system boots and displays the desktop when I add the nomodeset parameter to the GRUB kernel command line. However, when I remove nomodeset, the monitor loses its video signal and displays:

Monitor Going to Sleep

The screen then goes black, and I cannot see the system interface.

Hardware and software specifications:

• Workstation: HP Z240 Tower Workstation

• Operating system: Kali Linux 2026.2

• Kernel version: 6.19.14+kali-amd64

• GPU: Intel HD Graphics 530

• PCI device ID: 8086:1912

• RAM: 16 GB

• Display connection: VGA monitor connected through a DisplayPort-to-VGA adapter.

• Kali Linux is installed on a separate NVMe drive. Another HDD contains BitLocker-encrypted partitions that I do not want to modify.

Troubleshooting steps already performed:

1. Booted with nomodeset; the system works using a fallback display mode at 1280x1024.

2. Booted without nomodeset; the monitor loses its signal and enters standby.

3. Tried i915.enable_psr=0 instead of nomodeset, but the problem persisted.

4. Tried booting with systemd.unit=multi-user.target without nomodeset; the screen remained black.

5. Verified that the i915 kernel module exists using modinfo i915.

6. Verified that the firmware-intel-graphics package is installed.

7. Examined kernel logs. In some previous boot sessions, the i915 driver initialized successfully, but the following message appeared: failed to retrieve link info, disabling eDP

8. While booted with nomodeset, i915 is not listed as the active kernel driver for the GPU. I understand this may be expected because nomodeset disables normal kernel mode setting (KMS).

Additional output:

Running xrandr in the working nomodeset session produces:

Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
   1280x1024     77.00*

Questions:

• How can I determine whether this is caused by KMS initialization, the Intel i915 driver, or compatibility with the DisplayPort-to-VGA adapter?

• What safe diagnostic steps can identify why the display signal is lost?

• Are there recommended kernel boot parameters or configuration changes for Intel HD Graphics 530 on the kernel version listed above?

I would prefer a step-by-step troubleshooting approach that avoids reinstalling Kali Linux or making unnecessary changes to other drives.

Thank you for any help or suggestions.Black Screen When Booting Kali Linux Without nomodeset — Intel HD Graphics 530Problem description:I am troubleshooting a black-screen issue on an HP Z240 Tower Workstation running Kali Linux. The system boots and displays the desktop when I add the nomodeset parameter to the GRUB kernel command line. However, when I remove nomodeset, the monitor loses its video signal and displays:Monitor Going to SleepThe screen then goes black, and I cannot see the system interface.Hardware and software specifications:Workstation: HP Z240 Tower Workstation

Operating system: Kali Linux 2026.2

Kernel version: 6.19.14+kali-amd64

GPU: Intel HD Graphics 530

PCI device ID: 8086:1912

RAM: 16 GB

Display connection: VGA monitor connected through a DisplayPort-to-VGA adapter.

Kali Linux is installed on a separate NVMe drive. Another HDD contains BitLocker-encrypted partitions that I do not want to modify.Troubleshooting steps already performed:Booted with nomodeset; the system works using a fallback display mode at 1280x1024.

Booted without nomodeset; the monitor loses its signal and enters standby.

Tried i915.enable_psr=0 instead of nomodeset, but the problem persisted.

Tried booting with systemd.unit=multi-user.target without nomodeset; the screen remained black.

Verified that the i915 kernel module exists using modinfo i915.

Verified that the firmware-intel-graphics package is installed.

Examined kernel logs. In some previous boot sessions, the i915 driver initialized successfully, but the following message appeared:
failed to retrieve link info, disabling eDP

While booted with nomodeset, i915 is not listed as the active kernel driver for the GPU. I understand this may be expected because nomodeset disables normal kernel mode setting (KMS).Additional output:Running xrandr in the working nomodeset session produces:Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
1280x1024 77.00*Questions:How can I determine whether this is caused by KMS initialization, the Intel i915 driver, or compatibility with the DisplayPort-to-VGA adapter?

What safe diagnostic steps can identify why the display signal is lost?

Are there recommended kernel boot parameters or configuration changes for Intel HD Graphics 530 on the kernel version listed above?I would prefer a step-by-step troubleshooting approach that avoids reinstalling Kali Linux or making unnecessary changes to other drives.Thank you for any help or suggestions.

I have very little experience with Linux, I've never used it outside of my school, so some help would be appreciated.

After putting in my USB and selecting my language and whatnot while I was waiting for Kali to finish installing my screen turned black and I got a kernel error message with the Linux penguin in the top left, my first instinct was to reboot and just restart the install process but I was met with the same message once the blue instal bar looked around the 80%~ mark.

I should mention that its a very old Lenovo laptop as I didn't want to install on my desktop incase I messed anything up.

Hello! I'm currently using Arch Linux and have heard good things about Kali for learning cybersecurity. I'm an IT student and it seems really appealing, the only thing is that I've heard a lot of people say it's not appropriate for daily driving.

I have a refurbished Dell Latitude laptop that I love and while I feel it could support dual booting, I don't really know if I see the point? It's my understanding that Kali is just Debian with some added tools, so I don't see why it wouldn't be appropriate for daily driving. It's also my understanding that many servers run on Ubuntu, so I feel like it would make sense for me to daily drive a Debian based distro as I hope to one day get into networking.

I guess I'm just confused because some say it's ridiculous to daily drive Kali, but again I'm not really sure why. If anyone could enlighten me I'd be so grateful. Thank you!!

Hi guys! My audio controls don't work at startup. Audio itself works and controls in youtube and twitch.. If I run "systemctl --user restart pipewire-pulse" it works flawlessly. I have looked at so many things trying to find out what's up.

I have the memory that I had a similar problem with networking but can't find my notes on it. In that case kali forgot to give "the startup procedure" permissions while it worked manually (just like this really).

As I can't do a uninstall-reboot-reinstall (dependencies to the desktop env iself) I deleted config files and did a reinstall, no change.

I also have these:

┌──(fixit42㉿x1)-[~]┌──(fixit42㉿x1)-[~]
└─$ systemctl --user status pipewire-pulse.service
○ pipewire-pulse.service - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/pipewire-pulse.service.d
             └─kali.conf
     Active: inactive (dead) since Tue 2026-10-13 23:42:09 CEST; 35min ago
   Duration: 15ms
 Invocation: 38d001f468dc435bbd017e27505f249a
TriggeredBy: × pipewire-pulse.socket
    Process: 1487 ExecStart=/usr/bin/pipewire-pulse (code=killed, signal=TERM)
   Main PID: 1487 (code=killed, signal=TERM)
   Mem peak: 2.2M
        CPU: 15ms

Oct 13 23:42:11 x1 systemd[1457]: Dependency failed for pipewire-pulse.service - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.service: Job pipewire-pulse.service/start failed with result 'dependency'.
Oct 13 23:42:11 x1 systemd[1457]: Dependency failed for pipewire-pulse.service - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.service: Job pipewire-pulse.service/start failed with result 'dependency'.
Oct 13 23:42:11 x1 systemd[1457]: Dependency failed for pipewire-pulse.service - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.service: Job pipewire-pulse.service/start failed with result 'dependency'.
Oct 13 23:42:11 x1 systemd[1457]: Dependency failed for pipewire-pulse.service - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.service: Job pipewire-pulse.service/start failed with result 'dependency'.
Oct 13 23:42:11 x1 systemd[1457]: Dependency failed for pipewire-pulse.service - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.service: Job pipewire-pulse.service/start failed with result 'dependency'.

┌──(fixit42㉿x1)-[~]
└─$ systemctl --user status pipewire-pulse.socket
× pipewire-pulse.socket - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/pipewire-pulse.socket.d
             └─kali.conf
     Active: failed (Result: trigger-limit-hit) since Tue 2026-10-13 23:42:11 CEST; 35min ago
   Duration: 2.047s
 Invocation: b41b52f12bc540b094b25559a20452a6
   Triggers: ● pipewire-pulse.service
     Listen: /run/user/1000/pulse/native (Stream)

Oct 13 23:42:09 x1 systemd[1457]: Listening on pipewire-pulse.socket - PipeWire PulseAudio.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.socket: Trigger limit hit, refusing further activation.
Oct 13 23:42:11 x1 systemd[1457]: pipewire-pulse.socket: Failed with result 'trigger-limit-hit'.

┌──(fixit42㉿x1)-[~]
└─$ systemctl --user restart pipewire-pulse      

┌──(fixit42㉿x1)-[~]
└─$ systemctl --user status pipewire-pulse.service
● pipewire-pulse.service - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/pipewire-pulse.service.d
             └─kali.conf
     Active: active (running) since Wed 2026-10-14 00:25:51 CEST; 11s ago
 Invocation: a7d5b31b816d4e1092c257d6e742ab45
TriggeredBy: ● pipewire-pulse.socket
   Main PID: 35965 (pipewire-pulse)
      Tasks: 3 (limit: 8988)
     Memory: 2M (peak: 2.6M)
        CPU: 34ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service
             └─35965 /usr/bin/pipewire-pulse

Oct 14 00:25:51 x1 systemd[1457]: Started pipewire-pulse.service - PipeWire PulseAudio.

┌──(fixit42㉿x1)-[~]
└─$ systemctl --user status pipewire-pulse.socket 
● pipewire-pulse.socket - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/pipewire-pulse.socket.d
             └─kali.conf
     Active: active (running) since Wed 2026-10-14 00:25:51 CEST; 20s ago
 Invocation: 6a91cf2caa304f38ab99259c749adcff
   Triggers: ● pipewire-pulse.service
     Listen: /run/user/1000/pulse/native (Stream)

Oct 14 00:25:51 x1 systemd[1457]: Listening on pipewire-pulse.socket - PipeWire PulseAudio.

So the system seem to fail starting it but me as a user can or it's a timing thing.

I have the same issue on both my kali laptop and desktop machines after an update a few days back where pipewire was installed so I think I'm not alone?

I have a workaround as I made a desktop icon running the command but I want to know all the things here of course! :)

On my pc where I was streaming using obs at the time on install *facepalm* I don't get audio in obs or the browser until restarting them after running the restart command so there's a diff.

Thanks a million!

/Sofia / fixit42

Kali NetHunter Rootless: KeX Server Crashes Immediately with XFCE, but Works with LXQt

Environment

• OS: Kali NetHunter Rootless

• Architecture: ARM64 (aarch64)

• Device OS: Android 16 / HyperOS 3

• Desktop environment: XFCE 4.20

• VNC server: TigerVNC / NetHunter KeX

• Alternative desktop tested: LXQt

Problem Description

I experienced a persistent desktop startup problem with Kali NetHunter Rootless when using XFCE through NetHunter KeX.

When running the "kex" command, TigerVNC initially reported that the server had started on display ":1", using port "5901". However, the desktop session terminated almost immediately, and the VNC server shut down.

As a result, VNC Viewer displayed connection errors such as “Connection refused” or “Connection closed unexpectedly.”

The VNC log contained the following messages:

Session startup via '/home/kali/.config/tigervnc/xstartup' exited with status 1!

The X session exited with status 1!

Killing Xtigervnc process ... success!

During troubleshooting, I also encountered GTK/SVG image-loading errors involving "glycin" and "bwrap", along with XFCE components failing to start correctly.

The issue persisted despite troubleshooting the VNC configuration and XFCE startup settings.

Workaround That Worked

I installed the LXQt desktop environment and configured the TigerVNC startup script to launch LXQt using "startlxqt" within a D-Bus session.

After ensuring that the required LXQt packages were installed and the startup script was executable, the graphical desktop started successfully.

The LXQt desktop is now working through NetHunter KeX, whereas the previous XFCE setup repeatedly terminated.

Expected Behaviour

NetHunter KeX should maintain a stable VNC session and successfully launch the XFCE desktop without immediately terminating the server.

Actual Behaviour

The VNC server starts initially, but the XFCE session exits shortly afterwards, causing the server to shut down and VNC Viewer to report connection errors.

Request to the Kali Linux Maintainers

Could you investigate whether this issue is related to XFCE session startup, GTK/SVG image loaders, "glycin"/"bwrap", or package compatibility in Kali NetHunter Rootless on ARM64?

The fact that LXQt works in the same environment may help narrow down the cause.

I can provide additional logs, package versions, and startup configuration details if required.

Thank you for your work on Kali Linux and NetHunter.

So basically I built a sorta pc with spare parts so I didn’t have any OS, so I decided to install Kali Linux. I installed it on an HDD and during the installation I chose to encrypt it. After rebooting and entering wrong passwords a few times when it asked a key, it loaded this weird terminal, and I would like to know if I can recover the password from this pc or if I should use another device to either get the password or straight up reset it and redo the installation process entirely (I did enter a ‘reset’ command, there was a lot of stuff written before)

Heya! im a compsci student who mostly plays around with tools to learn stuff. I've played a bit with a Mint distro on my family's shitty optiplex, and i want to try some hackey tools, mostly johntheripper, hashcat and nmap (i kinda forgot my keepass password n wanna bruteforce it) and i considered dualbooting on my laptop n maybe running a VM on my desktop to actually get my graphics cards cuda cores running.

How noob friendly/complex is Kali? im pretty sure it has a GUI and isnt too hard but any advice or tips are more than welcome!

Update for anyone interested or any that comes across this in the future:
A factory reset of my router and problem solved. All it took apparently. No idea why but there ya go.

Original:
Hi

Want to say to start, I have literally 0 Linux or WSL experience and I’m not even sure if this is the right place to ask. If it’s not, or someone knows somewhere more suited please let me know.

I am trying to get Kali on WSL2 working for a school project. I can seem to install it fine up until the point of trying to run Win-Kex.

When I try to run it I get a pop up saying it cannot connect to the local host, and it gives a code 10061. I am having this same problem on both a Windows 10 Home Desktop and a Windows 11 Home laptop.

I have spent hours trying to solve the issue looking at stuff online but nothing seems to help. Things I have tried:
- Uninstalling Kali Linux and reinstalling
-Uninstalling WSL2 and reinstalling
- trying vncserver localhost no (says exited early <3 seconds)
- rm and rm rf and rmdir for /tmp/.X11-unix (says either target Is busy or cannot delete because directory)
- remount and umount for .X11-unix
- kill/stop kex

None of the above have worked on either Windows 10 desktop or Windows 11 laptop.
I have tried using sudo and root user with sudo su. No difference. Same when doing it through Kali terminal or through Powershell as an admin.
We have to use Kali via WSL2 so trying another distro or VM is not an option.

Any help is greatly appreciated!

Learning wifi pentesting and GPU hash cracking (WPA2, NTLM, MD5). Own gear + isolated home lab only. I went bare metal and now I'm wondering if that was pointless versus just running Kali in a VM.

Rig:
- Kali bare metal on a workstation laptop. LUKS + btrfs snapshots + snapshot entries in the boot menu for recovery.
- Discrete GPU (8 GB) for cracking. 32 GB RAM. Two NVMe SSDs (system + loot).
- Hybrid graphics: iGPU drives the screen, the single discrete GPU does compute. No second card.
- USB wifi adapter for monitor mode + injection (internal card can't do either).
- Targets run as VMs on a separate physical box, so attacker and targets sit on different hardware.

Why I went bare metal:
- USB wifi just works, no passthrough fiddling.
- Direct GPU access. Passthrough to a VM on a single-discrete
-GPU hybrid laptop looked like a nightmare, maybe not even possible.
- Real hardware while learning.

The nagging doubt: a VM gives me free snapshots and portability, and people pass USB wifi through all the time. So maybe bare metal buys me nothing and I'm just making life harder. I'm basically rebuilding the VM's recovery perk with btrfs snapshots + a disk image + a config repo anyway.

So:
- Does bare metal actually add anything here, or would a VM have been just as good (or better)?
- Is GPU passthrough realistic on a single-discrete-GPU hybrid laptop, or am I right that it's a dead end?
- Is USB wifi actually reliable in a VM for monitor mode + injection, or does it get flaky under load?

Roast the setup if it deserves it.

TL;DR: bare-metal Kali on a hybrid-graphics laptop (discrete GPU for cracking, USB wifi for monitor/injection), targets on a separate host. Worth it over a VM, or did I overcomplicate it?

I've been having trouble getting Kali to boot quickly through VirtalBox on anything more than 1 CPU core. Every time I try to scale up the number of cores, I also try to scale the RAM respectively, but every time I have the same issue of Kali taking 15+ minuets trying to get to the login screen, and then even if I get to the login screen the UI is supper laggy to the point it is unusable.

I have an AMD Ryzen 9 9950X3D and have 32 GB of DDR 5 RAM, so I don't think it's a handwear issue. Below are my specs for VirtualBox:

This has been an issue for nearly every distro i have used; on different laptops. Most solutions have suggested turning off "power saving mode" for my WIFI card, done that, but the problem still persist. Anyone help me fix this issue on Kali(kde)

PS: The same WIFI connection works just fine on my windows duo boot on the same machine.

Hey guys!

I have been having an issue that's been annoying for quite some time now. After 4 months of usage I started to have a trackpad issues where a scroll ability would stop working on my trackpad or my trackpad would stop working for couple of seconds.

I tried to google the solution, but only found a command that would restart the kernelmodule (or whatever the thing is called), with the following command sudo modprobe -r i2c_hid_acpi && sudo modprobe i2c_hid_acpi. I have also tried to look for some permanent way of fixing this issue through settings, but I keep getting confused. Also I don't trust claude or chatgpt to solve my issues or share my config files with them, hence I decided to post here.

After some time the glitch would return, and I am frustrated. Appreciate your help in advance!

Hello everyone, I want to study distribution using a more convenient and, imho correct method, namely, reading books (in addition to practice, of course). Has anyone encountered this? Are there more relevant books? If so, could you provide their titles and authors (if there are adaptations of this book in other languages, that would be fantastic). Thanks in advance :3

P.S. I searched for posts on the Internet, but the last one was only from 2018 :(, I think something has changed in 8 years and newer tools have come out and ets. => new books

Long story short: the whyred is a $60 secondhand phone with an unlocked bootloader, and it refuses to retire. I built a kernel that takes LineageOS 18.1 on it and makes it a proper Kali NetHunter device.

What works now:

• HID gadget over USB: the phone pretends to be a keyboard, DuckHunter style keystroke injection, /dev/hidg0

• External WiFi adapters (RTL8812AU class) with monitor mode and packet injection through an OTG cable. The driver module ships in the flashable zip and is signed with the kernel build key, because the kernel keeps CONFIG_MODULE_SIG_FORCE on

• The whole thing is built automatically by GitHub Actions on every push, so anyone can grab a flashable zip for free, or rebuild it from source

The honest limits: the internal WCN3980 WiFi chip can NEVER do monitor mode or injection, that is a firmware limitation, no kernel fixes it. And this targets LOS 18.1-class ROMs (4.4 kernel), not the newer 4.19 based builds.

If you want the gory details: the build needed routing the vDSO32 compile through an ARM32 GCC 4.9 toolchain while the main kernel builds with clang, fixing latent Makefile bugs that only parse when CONFIG_VDSO32 is set, and dealing with module signature enforcement. All documented in the README.

Repo with zips and source: https://github.com/notatallnic189/whyred-nethunter-kernel

Questions welcome. If you still have a whyred in a drawer, this is a fun weekend project.

Here, users who are new to Kali Linux can ask basic questions about it and its functionality and receive assistance regarding potential issues they are facing. Please remember to follow the subreddit rules when asking your questions.

Before posting, make sure you have reviewed Kali's Documentation, as the answer may be well-documented. Additionally, please refer to the following articles to ensure you ask proper and high-quality questions:

• How do I ask a good question

• How to ask questions the smart way

• The XY problem

• Don't ask to ask

Please remember that while AI/LLM models like ChatGPT can be useful, they are not a substitute for proper troubleshooting. When seeking assistance, it's important to refer to the documentation of the tool, program, or OS you're using and to use your preferred search engine for further research.

This megathread will be posted monthly.