DEV Community: Anay Pandya

Dual Boot broken after Windows Updates - Fixing LUKS, NVIDIA and Time Sync

Anay Pandya — Tue, 11 Aug 2026 13:42:52 +0000

When my windows updated itself without asking me last night, I rebooted my PC, and GRUB menu didn’t show. It had happened, windows update messed up with my dual-boot setup again.

Here’s all the things I had to do again after the update to get my Fedora back to normal. The main purpose of writing this blog is to have a list of things that needs to be done everytime this happens (this wasn’t the first, probably won’t be last), and maybe help someone with the same.

Now, like all good engineers, I thought about automating this, cause who wants to spend 5 minutes, maybe in a couple of months doing this manually, when they can automate.

Here’s the link to my bash script. Please don’t mind the name. Everything below goes through what the script does.

LUKS2 + TPM2 Auto-Unlock

Being a good security student, I have my disk encryption enabled in Fedora. But I didn’t want to enter the decryption password everytime I boot up, I have my login password for protection. So I had a Auto-Unlock setup with LUKS2 + TPM2, which no longer worked after the update.

I already have a blog going through how to setup it up for yourself here.

So, we first wipe existing TPM2 slot if any are present. This makes sure we don’t clutter the LUKS header keyslots on your NVMe drive.

sudo systemd-cryptenroll --wipe-slot=tpm2 "$LUKS_DEVICE" || true

Next, we have to enroll a new fresh TPM2 key.

sudo systemd-cryptenroll \
    --tpm2-device=auto \
    --tpm2-pcrs=7 "$LUKS_DEVICE"

Now, we have the keys setup for our disc encryption. For this to work, we have rebuild the INITRAMFS, but that is also needed for the following steps, so we’ll just do that at the end.

NVIDIA

I have a RTX4060 in my laptop. Updates from windows, not just system updates but also when you update only the NVIDIA driver from windows, tends to break the GPU setup for linux in a dual boot setup. Here’s how we fix that.

First, we check is nvidia-smi can connect to the NVIDIA drivers. we do that by simply running nvidia-smi and seeing if we get our card in the output.

Next, we check is akmods service is running properly. This is the handles the compilation of proprietary NVIDIA driver on your machine based on your specific linux kernel version. akmods is how fedora handles the proprietary drivers, in different systems it can also be dkms. Apart from that, most systems use a reverse-engineered open source driver called nouveau for graphics cards. Make sure that if you are using NVIDIA proprietary drivers you don’t have a conflict between the two, you have to properly disable nouveau.

once we have made sure akmods (or the driver your system has) is properly running, we need to make sure that our module is available and loaded. The script I wrote handles this by

trying to fetch the info of graphics module : modinfo "nvidia"
checking if the module is running : lsmod | grep "nvidia"

If either of the checks fails

if nvidia-smi cannot connect to the driver
if akmods is not available / running
if the module is not available / not loaded

then we rebuild the NVIDIA module, by first removing any cached mods

sudo rm -rf /var/cache/akmods/nvidia/*

and then force rebuilding the modules :

sudo akmods --force --rebuild

Note that the script and the code here is specific to my machine, if yours uses a different driver or a different graphics card, the exact details needs to be tweaked accordingly.

Time Sync

I frequently had to switch between windows and fedora, so I had synced the clocks on my hardware for both of them. When windows updated, it changed that clock to my local time zone, which is IST. But, fedora and most other linux environments expects time to be in UTC.

We can check what the current datetime configurations are by doing timedatectl status. It’ll show what our timezone is and also if the time synchronization (i.e. NTP synchronization) is turned on. When you set it up, you also might have to change some configs in windows.

To go back to having the hardware clock use UTC and not having to sync the clock everytime you switch between the two, you have to set the hardware clock (RTC) to UTC :

sudo timedatectl set-local-rtc 0 --adjust-system-clock

and then enable the NTP synchonization :

sudo timedatectl set-ntp true

NOTE : don’t worry, your system time will still be the time you set, this just sets the time on the hardware in your machine that holds the time, cause linux systems expect that to be in UTC, and may cause troubles in some cases.

Conclusion

Lastly, once everything is done, we rebuild our INITRAMFS :

sudo dracut --force --regenerate-all

Dracut is the module handling INITRAMFS for fedora and other similar distros. For debian, ubuntu and it’s derivatives you need to use update-initramfs and for Arch and other systems similar to that, you might have to use mkinitcpio.

The last thing to do is to reboot your system, and everything hopefully will be back to normal.

Secure Boot and MOK Enrollment

If you have Secure Boot enabled in your BIOS, rebuilding the module isn’t enough. You have to tell the motherboard to trust the newly built driver.

Generate a new key and sign the kernel modules:

sudo kmodgenca

Import that key into the UEFI’s trust database

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

This’ll prompt you to create a temporary password. Remember that password. When you reboot, you’ll be intercepted by a blue MOK Management screen before GRUB. Select Enroll MOK, hit continue, and type that temporary password.

If you are using akmods then it handles the signing of the drivers by itself and you don’t have to do that manually. It too when you run the command rebuild will prompt you for the password discussed above, and at reboot will show the blue screen. Follow the same instructions as discussed before.

Hardware

Most of the commands are specific to my system, which is a Acer Predator, dual booted with windows and Fedora, and it has a dedicated NVIDIA RTX graphics card. But you can still refer to this from a checklist point of view and tweak the commands specific to your system and configuration.

How does an LLM "know" the sky is blue?

Anay Pandya — Tue, 11 Aug 2026 13:41:08 +0000

For most people, LLMs are a magic box that spews out language. Somehow, that language is very similar to "what a human would say". "LLMs work on neural networks", "LLMs predict the next words in a sentence", "They're trained on a large set of data", are some of the common things people say about these mysterious models.

But HOW?? How can a machine, which was mostly working on logic, 1s and 0s, following instructions, how can that lead to such varied, random, and complex outputs in the form of language that is also mostly correct, not just structurally but also factually. What kind of logical steps can lead to "human-like intelligence"?

Hint: The answer says more about us than the machine.

But to understand that, for those who are unfamiliar with the working of a model, here's a brief introduction of how a LLM works at a bird's-eye view. For those familiar with it, can skip to The Big Question.

How LLMs work.

The most common conception of working of an LLM is that it predicts the next word. It is true, LLMs predicts what is called a Token, it is either a word or a part of a word. Some even go so far as to call LLMs a state-of-the-art auto complete.

But we ask a question and it answers the question, how is that predicting the next word?? That is more like a conversation.

Yes, but behind the interface, there are two parts to programs like ChatGPT. There is the program, the plain old computer logic, and then there's the model. Model is what makes the predictions that we talked about above. The computer program interacts with the model. How it handles our prompts is that it makes a long string, like a dialogue between us and the model, and feed that to the model, so all the model sees is a dialogue a user has with a system, and apart from that a lot of other information, think of it as a PS. Thus, the model is just trying to "auto-complete" the dialogue writing.

The models are a result of fairly complex mathematics, but in use, a language model's role is to predict the next word.

Raw next-token prediction is only the first stage of training. After that, models go through a process called fine-tuning — what it is is, humans rate thousands of model outputs for helpfulness and accuracy, and the model is adjusted to produce more of what gets rated highly. This is why the same underlying math that could generate Reddit comments can also answer your coding questions coherently. The base architecture learns language; the fine-tuning teaches it a job.

The Big Question

What almost no-one questions is how these models are so intelligent. Intelligent in the sense that "The sky is red" is just as grammatically correct as "The sky is blue". So if we feed the model "The sky is ", what is preventing it from predicting the word "red".

The mathematics we mentioned above that makes these models, what it does at a very bird's-eye view is it takes in a bunch of sentences, and the algorithm is trained to predict, given a fragment like "The sky is ", the word that should come next, "based on the examples I trained on". So, it takes in the sentences and "according to those sentences", it predicts the word. Thus the predictions depend on what sentences the maths was applied to to train the model.

In order to train the text models that we all know, we needed many such sentences. So, these sentences were scraped from books, blogs, websites, etc. The internet and the written literature was indeed a good source of human written sentences. So the models were trained on these.

Now, the models know what a human would say given a set of words. And, a human is an intelligent being. Given the words "The sky is ", most humans in most situations would truthfully say "blue". Thus, the model doesn't actually know that the sky is blue. What the model knows is that a human would say the word "blue" after "The sky is " in most cases.

This is of-course a very high level view of how these models become smart. Whether this counts as 'knowing' is itself debated. But to me this idea that our language acts as a proxy to our intelligence is intriguing. How we communicate our thoughts inherently carries some essence of our intelligence, and through mimicking how we communicate, a machine can in-turn mimic the intelligence, the thoughts behind the language.

Virtualization — QEMU/KVM

Anay Pandya — Tue, 11 Aug 2026 13:39:37 +0000

I recently had to set up a network of VMs for my Information and Network Security class. I decided to go with a QEMU/KVM setup instead of the usual VirtualBox/VMware route. Reason? I enjoy the feeling I get when I am tinkering with something. A VirtualBox/VMware setup would have been reliable and straightforward, but I was chasing the “I did something” emotion. That is also the same reason I started using Neovim for coding; it has a dexterous feel to it.

Before we start, this paragraph is a quick introduction to QEMU and KVM.

KVM stands for Kernel-based Virtual Machine. It is a Linux kernel subsystem that allows Linux to use hardware virtualization extensions provided by the CPU. On an Intel machine, this is generally VT-x; on AMD it is AMD-V. As all things in linux KVM too is exposed through a file. It is similar to a device node, and is exposed via /dev/kvm.

QEMU is the machine emulator/virtualizer. It provides the virtual hardware: disks, network cards, display devices, firmware, PCI devices, USB controllers, and so on.

KVM provides the kernel-level acceleration that lets QEMU execute guest CPU instructions using the host CPU’s virtualization capabilities rather than emulating every instruction in software.

So, very roughly:

QEMU/KVM is what enables virtualization on linux. Then, there is libvirt. It is like a management layer and API for virtualization technologies such as QEMU/KVM. It manages things such as:

VM definitions
CPU and memory configuration
virtual disks
networking
storage pools
firmware
snapshots
VM lifecycle
devices

virsh is the command-line interface to libvirt. virt-manager is the graphical management interface. It talks to libvirt.

There is also GNOME Boxes, which is another graphical frontend for QEMU/KVM/libvirt. Boxes is meant to make virtualization simpler and hide a lot of the underlying configuration. virt-manager exposes much more of the actual virtual hardware and libvirt configuration.

Since my goal wasn’t just to get a VM running but to understand what was happening, I went with virt-manager and virsh.

This is the stack:

                 virt-manager
                      │
                    virsh
                      │
                      ▼
                   libvirt
                      │
                      ▼
                  QEMU / KVM
                      │
             ┌────────┴────────┐
             │                 │
         virtual CPU      virtual devices
             │                 │
             └────────┬────────┘
                      ▼
                   Guest OS

Before anything else: does KVM actually work?

Before building anything, I ran a sanity check:

virt-host-validate

This walks through the host’s virtualization capabilities and flags anything that is missing.

This is useful because it can catch problems such as hardware virtualization not being available or required virtualization components not being configured properly.

It is much better to discover that here than to discover it three VMs deep when virt-install throws some cryptic KVM error.

I could also check that the KVM device actually exists:

ls -l /dev/kvm

This is the point where the /dev/kvm explanation from earlier becomes useful. KVM is part of the kernel, but userspace virtualization software interacts with it through this device interface.

The first quirk: `qemu:///session` vs `qemu:///system`

I had to do sudo to make VMs since some of the operations like networking needed elevated privileges. So I started looking into ways to avoid having to use sudo again and again.

Turns out libvirt has something called the connection scopes. There was the session scope which was associated to my user session (qemu:///session). Then there was the system-wide libvirt daemon, connecting to the system scope (qemu:///system).

This is the usual choice when creating infrastructure-like VMs, because resources such as:

system networks
system storage pools
shared VM definitions

are managed centrally.

This also explained the situation where:

virsh net-list --all

showed nothing, while:

sudo virsh net-list --all

showed the default network:

Name      State   Autostart   Persistent
--------------------------------------------
default   active  yes         yes

To put it simply I was looking at two different libvirt worlds.

The important thing here is that qemu:///session and qemu:///system aren’t two different versions of QEMU. They are two different libvirt connection scopes.

So, in order to work with the system-wide VMs and networks, I decided to use:

qemu:///system

This can be done with the flag:

--connect qemu:///system

For persistence, you can set the following environment variable by updating your .zshrc or .bashrc files:

export LIBVIRT_DEFAULT_URI="qemu:///system"

Then, after refreshing the terminal session, the scope can be checked with:

virsh uri

which should return:

qemu:///system

There is another part to this though: the user still needs permission to access the system libvirt service. On my Fedora setup, I was already a member of the relevant groups:

groups

which included:

kvm
libvirt

This is why I could eventually work with qemu:///system without having to put sudo in front of every command.

Building the lab network

The whole point of this exercise was networking.

But before actually creating the VMs, I needed somewhere to put them.

The important thing here is that I ended up with two completely separate networks, because they serve two completely different purposes.

The first is labnet. This is the network for my Information and Network Security class.

The second is libvirt’s default network. This is what I use for my standalone ParrotOS HTB machine.

These are intentionally separate.

The INS lab looks roughly like:

                         Fedora Host
                              │
                           labnet
                     192.168.100.0/24
                              │
              ┌───────────────┼───────────────┐
              │               │               │
           Windows       Metasploitable      Kali
            target          target         Distrobox

While Parrot is completely separate:

                  Fedora Host
                       │
                    default
                       │
                    Internet
                       │
                    ParrotOS
                       │
                    HTB VPN

Parrot is not part of labnet.

labnet is for my INS class. Parrot is a standalone machine for HTB.

Why `labnet` exists

This wasn’t just tidiness.

Metasploitable is deliberately full of vulnerable and unpatched services. I did not want to put a deliberately exploitable machine directly onto the physical network at NFSU.

If I had bridged Metasploitable directly onto my physical NIC, I could potentially have exposed its vulnerable services to other machines on the university network.

Instead, I created a private libvirt network.

The lab machines can communicate with each other, and the Fedora host can communicate with the lab, without putting the vulnerable machines directly onto the university LAN.

The network is:

labnet
192.168.100.0/24

with the libvirt host-side gateway at:

192.168.100.1

The network is described using a libvirt XML definition.

I used something along these lines:

<network>
  <name>labnet</name>

  <forward mode="nat"/>

  <bridge name="labnet_lab" stp="on" delay="0"/>

  <ip address="192.168.100.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.100.10" end="192.168.100.100"/>
    </dhcp>
  </ip>
</network>

I saved this as:

labnet.xml

There are a few important things happening here.

<name>labnet</name>

gives the libvirt network its name.

<bridge name="labnet_lab"/>

tells libvirt to create a virtual bridge with that name.

<ip address="192.168.100.1" ...>

sets the address of the host-side interface on this virtual network.

And:

<dhcp>
    <range start="192.168.100.10" end="192.168.100.100"/>
</dhcp>

provides DHCP addresses to the VMs.

The:

<forward mode="nat"/>

means that traffic leaving the virtual network can be NATed through the Fedora host.

So the topology is approximately:

                Physical Network
                       │
                   Fedora Host
                       │
                 ┌─────┴─────┐
                 │           │
              Internet    labnet
                           │
                    192.168.100.1
                           │
              ┌────────────┼────────────┐
              │            │            │
           Windows    Metasploitable   Kali

The important security property here is that labnet is not simply a bridge to my physical Ethernet/Wi-Fi network.

Creating the network

Once I had the XML file, I defined the network:

virsh net-define labnet.xml

Then started it:

virsh net-start labnet

And made it start automatically:

virsh net-autostart labnet

I could check it with:

virsh net-list --all

which should show something along the lines of:

Name      State   Autostart   Persistent
--------------------------------------------
default   active  yes         yes
labnet    active  yes         yes

I can inspect the network with:

virsh net-info labnet

and see the actual XML libvirt is using with:

virsh net-dumpxml labnet

I can also see the bridge from Fedora:

ip link show labnet_lab

or:

ip addr show labnet_lab

This was particularly useful because I could finally see that the “network” wasn’t some abstract thing inside libvirt. There was an actual bridge interface on my Fedora host.

One thing I ran into here was:

error: Failed to start network labnet
error: error creating bridge interface labnet_lab:
Operation not permitted

This was another consequence of me mixing the session and system libvirt scopes. I was trying to start a system-level network from the wrong libvirt connection.

Once I consistently used:

qemu:///system

the network was being managed by the same libvirt instance as my VMs.

If I ever want to shut the network down:

virsh net-destroy labnet

and if I want to remove the persistent network definition entirely:

virsh net-undefine labnet

Connecting the machines to `labnet`

Once the network exists, attaching a VM to it is surprisingly simple.

For example, my Windows VM has:

--network network=labnet,model=virtio

and Metasploitable has the same:

--network network=labnet,model=virtio

This tells libvirt:

Give this VM a virtual network interface and connect it to the existing labnet network.

The Fedora host itself also has an interface on that bridge, which means I can communicate with the lab from the host.

I also use Kali through Distrobox on Fedora. It is not another VM in this setup. Since it is running as a containerized userspace environment on the Fedora host, it can use the host’s networking and therefore participate in the lab from the host side.

This gives me the INS lab topology I actually wanted:

                     Fedora Host
                           │
                     labnet_lab
                           │
          ┌────────────────┼────────────────┐
          │                │                │
       Windows        Metasploitable       Kali
        target           target          Distrobox

This is my INS class network.

Creating the Metasploitable VM

For my first target, I had a Metasploitable QCOW2 image.

Initially I kept the image in:

~/VMs/libvirt/metasploitable.qcow2

and tried virt-install.

I got:

Cannot access storage file
'/home/adper/VMs/libvert/metasploitable.qcow2'
(as uid:107, gid:107): Permission denied

The fact that I could read the file did not mean the QEMU process could.

The system libvirt QEMU process runs under a restricted account, in this case the qemu user. It also needs permission to traverse the directories leading to the file.

So, ideally, we are supposed to put the VM storage at:

/var/lib/libvirt/images/

I copied the disk there:

sudo cp ~/VMs/libvirt/metasploitable.qcow2 \
    /var/lib/libvirt/images/metasploitable.qcow2

On Fedora, SELinux can also matter when moving files into locations used by virtualization, so it is useful to make sure the file has the expected SELinux context:

sudo restorecon -v /var/lib/libvirt/images/metasploitable.qcow2

I then created the VM with:

virt-install \
  --connect qemu:///system \
  --name metasploitable \
  --memory 512 \
  --vcpus 1 \
  --disk path=/var/lib/libvirt/images/metasploitable.qcow2,bus=virtio \
  --network network=labnet,model=virtio \
  --import \
  --os-variant ubuntu16.04 \
  --graphics spice \
  --noautoconsole

The important thing here is:

--import

because I already had an operating system disk. I wasn’t asking virt-install to install an OS from an ISO. I was asking it to build a libvirt VM around an existing disk image.

The VM can then be started with:

virsh start metasploitable

and its graphical display can be opened with:

virt-viewer --connect qemu:///system metasploitable

Although in a security lab, I don’t necessarily need to “enter” Metasploitable at all.

The interesting architecture is:

                  labnet
                     │
          ┌──────────┴──────────┐
          │                     │
       Kali                 Metasploitable
     Distrobox                  target
          │                     │
          └─────── attacks ─────┘

This is Kali attacking Metasploitable, not Parrot.

Kali is running through Distrobox on my Fedora host and is participating in the INS labnet.

I can interact with Metasploitable from Kali over the lab network using things such as:

nmap
ssh
ftp
http
smb
...

depending on what services are exposed.

This is the point of having a vulnerable target inside a private lab.

Creating the Windows VM

Similarly, I also setup a Windows VM with this virt-install command:

virt-install \
  --connect qemu:///system \
  --name windows-lab \
  --memory 4096 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/windows-lab.qcow2,size=60,bus=virtio,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/windows11.iso \
  --disk /usr/share/virtio-win/virtio-win.iso,device=cdrom \
  --network network=labnet,model=virtio \
  --graphics spice \
  --video qxl \
  --os-variant win11 \
  --boot uefi \
  --tpm backend.type=emulator,backend.version=2.0

virt-install is basically telling libvirt:

Create a VM with these characteristics.

The important pieces are:

--memory 4096

4 GB RAM.

--vcpus 4

4 virtual CPUs.

--disk ... size=60

A 60 GB virtual disk.

--network network=labnet

Connect the VM to my INS lab network.

--graphics spice

Use SPICE for the graphical console.

--boot uefi

Use UEFI firmware.

--tpm backend.type=emulator,backend.version=2.0

Provide a virtual TPM 2.0 device.

And:

--cdrom /var/lib/libvirt/boot/windows11.iso

makes the Windows ISO the installation media.

I downloaded the Windows ISO directly from Microsoft’s website and used the unactivated installation for the lab. Since this wasn’t going to be my daily Windows machine, I didn’t particularly care about activation or the watermark.

The Third quirk: VirtIO

Windows setup booted successfully.

Then I reached the disk selection screen, there was no disk.

The VM had a 60GB virtual disk. QEMU had created it. The disk existed but Windows couldn’t see it.

Why?

Because I had explicitly said:

bus=virtio

in the virt-install command.

VirtIO is a paravirtualized device interface designed to provide efficient virtual I/O. Instead of pretending to be some old physical disk controller, QEMU exposes a VirtIO device and the guest uses a VirtIO driver to communicate with it.

Linux generally has excellent VirtIO support.

Windows, however, didn’t have the storage driver available during installation.

Luckily I had also attached:

/usr/share/virtio-win/virtio-win.iso

as a second virtual CD-ROM.

From the Windows installer I selected Load Driver, browsed to the VirtIO CD, and loaded the storage driver.

After that, the 60 GB virtual disk appeared.

The important part here is that the disk wasn’t missing.

It was simply being presented through a virtual controller for which Windows didn’t yet have a driver.

So:

                     Fedora
                        │
                /var/lib/libvirt/
                   images/
                        │
                        ▼
              windows-lab.qcow2
                        │
                        ▼
                      QEMU
                        │
                   VirtIO disk
                        │
                        ▼
                     Windows
                        │
                VirtIO driver
                        │
                        ▼
                  Windows disk

The same thing happened with networking.

The VM had a VirtIO network interface:

--network network=labnet,model=virtio

but Windows needed the VirtIO network driver before it could use that interface.

This was a good reminder that virtual hardware is still hardware from the guest’s perspective.

The device doesn’t physically exist, but the operating system still needs to know how to communicate with it.

UEFI is also virtualized

When booting the VM as well we get the screen from UEFI with Please select boot device.

This is the guest’s virtual firmware.

The VM is essentially being presented with an entire virtual computer as:

Host OS
  │
  └── QEMU
       │
       ├── virtual CPU
       ├── virtual RAM
       ├── virtual disk
       ├── virtual NIC
       └── virtual UEFI
             │
             └── virtual hardware

This is one of those things that is easy to forget when using a GUI VM application.

The VM isn’t just “a program running Windows”.

QEMU is presenting Windows with a computer.

Secure Boot and OVMF

I also wanted to setup a Parrot VM to perform practical tasks from HackTheBox. It was a procedure similar to what was described above.

This VM is separate from my INS lab.

I did not put Parrot on labnet.

Instead, Parrot uses libvirt’s default network so that it can have normal outbound Internet connectivity and be used as my standalone HTB machine.

The Parrot HTB edition was available to me as an ISO, so unlike downloading a ready-made QCOW2 image, I had to create the QCOW2 disk myself and install Parrot into it.

I used:

4 GB RAM
4 vCPUs
60 GB QCOW2
VirtIO disk
VirtIO network
UEFI

The VM was created with:

virt-install \
  --connect qemu:///system \
  --name parrot-htb \
  --memory 4096 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/parrot-htb.qcow2,size=60,bus=virtio,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/parrot-htb.iso \
  --network network=default,model=virtio \
  --graphics spice \
  --os-variant debian13 \
  --boot firmware=efi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no

I initially had a Secure Boot problem.

When the VM booted, there was a blue UEFI error:

Verification failed: (0x1A) Security Violation

This wasn’t KVM rejecting Parrot.

It wasn’t QEMU rejecting Parrot.

The virtual UEFI firmware was rejecting the bootloader because Secure Boot was enabled.

The firmware being used by QEMU in this setup is OVMF, which provides UEFI firmware for virtual machines.

I inspected the host’s capabilities with:

virsh domcapabilities

and found:

<loader supported='yes'>
    ...
    <enum name='secure'>
        <value>no</value>
    </enum>
</loader>

My host supported UEFI with Secure Boot disabled.

I checked the supported boot sub-options with:

virt-install '--boot=?'

which showed:

firmware
firmware.feature[0-9]*.enabled
firmware.feature[0-9]*.name
loader.secure
...

So instead of blindly specifying a firmware binary, I could explicitly configure the firmware feature.

I wanted:

UEFI:        ON
Secure Boot: OFF

and the relevant part of the command was:

--boot firmware=efi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no

This was another useful lesson: UEFI and Secure Boot are not the same thing.

I wanted UEFI, just without Secure Boot enforcement.

Installing Parrot

Once the firmware configuration was correct, Parrot booted into its installer.

The installer detected:

vda - 60.00 GiB (/dev/vda)

This was my virtual disk.

The /dev/vda name is again related to VirtIO.

The actual chain is:

Fedora
  │
  └── parrot-htb.qcow2
         │
         ▼
       QEMU
         │
         ▼
      VirtIO disk
         │
         ▼
      /dev/vda
         │
         ▼
       Parrot

I chose Erase disk because this was a brand-new virtual 60GB disk.

This does not erase my Fedora disk.

It formats the virtual disk that QEMU presented to Parrot.

So the actual storage relationship is:

Physical SSD
└── Fedora filesystem
    └── /var/lib/libvirt/images/
        └── parrot-htb.qcow2
              │
              ▼
             QEMU
              │
              ▼
           /dev/vda
              │
              ├── EFI partition
              └── Parrot filesystem

This is probably one of the most important mental models to have when working with VMs.

Parrot and the `default` network

Unlike the INS machines, Parrot is attached to libvirt’s default network:

--network network=default,model=virtio

This is intentional.

Parrot is not part of my university lab.

It is a standalone machine that I use for Hack The Box, so I want it to have normal outbound connectivity.

The topology is:

                  Fedora Host
                       │
                    default
                       │
                    Internet
                       │
                    ParrotOS
                       │
                    HTB VPN
                       │
                   Hack The Box

The default network is separate from:

labnet

which is my INS class network.

This separation also means that accidentally attacking something from my HTB Parrot VM does not mean I am accidentally attacking the machines in my university lab network.

Creating Snapshots

This was one of the main reasons I wanted a VM in the first place.

HTB encourages having a disposable machine because you’re going to install things, modify configurations, break packages, change network settings, and generally do things that aren’t necessarily good for a normal workstation.

Once I had Parrot installed and configured, I shut it down:

virsh shutdown parrot-htb

I checked that it had actually shut down:

virsh domstate parrot-htb

Once it reported:

shut off

I created the snapshot:

virsh snapshot-create-as \
    parrot-htb \
    clean-parrot-htb \
    "Clean Parrot HTB baseline"

where parrot-htb was my VM and clean-parrot-htb is my snapshot.

I could inspect it with:

virsh snapshot-list parrot-htb

and:

virsh snapshot-list parrot-htb --tree

Now I have a clean baseline that I can return to after destroying the machine with some experiment.

The workflow becomes:

                 clean-parrot-htb
                        │
                        ▼
                   Boot Parrot
                        │
                  Do HTB stuff
                        │
              ┌─────────┼─────────┐
              │         │         │
          install     modify    break
           tools      configs   packages
              │         │         │
              └─────────┼─────────┘
                        │
                       💥
                        │
                        ▼
                snapshot-revert
                        │
                        ▼
                 clean-parrot-htb

To revert:

virsh shutdown parrot-htb
virsh snapshot-revert parrot-htb clean-parrot-htb
virsh start parrot-htb

Snapshots are not backups though.

If the physical SSD dies, the VM and its snapshot data can disappear together.

Snapshots are rollback points, not a replacement for backups.

I also don’t want to create a snapshot every five minutes. I would rather have a clean baseline and a few meaningful checkpoints such as:

clean-parrot-htb
tools-configured
before-experiment

Managing the VMs after creation

Once the VMs are created, I don’t need to run virt-install every time I want to use them.

virt-install is primarily for creating and installing the VM.

After that, the normal lifecycle is handled through virsh.

List VMs:

virsh list --all

Start a VM:

virsh start parrot-htb

Open its graphical console:

virt-viewer --connect qemu:///system parrot-htb

Gracefully shut it down:

virsh shutdown parrot-htb

Check its state:

virsh domstate parrot-htb

Forcefully power it off:

virsh destroy parrot-htb

Again, destroy sounds much more dramatic than it actually is.

It does not delete the VM.

It is basically the equivalent of pulling the power cable.

If I actually want to remove the libvirt domain definition:

virsh undefine parrot-htb

If it uses UEFI NVRAM, I may have to do:

virsh undefine parrot-htb --nvram

The UEFI NVRAM surprise

When I first tried to remove my Parrot VM, I ran:

virsh undefine parrot-htb

and got:

Requested operation is not valid:
cannot undefine domain with nvram

This is because the UEFI VM had its own NVRAM / firmware variable store.

So the VM was more than:

domain definition
+
disk

It was also:

domain definition
+
QCOW2 disk
+
UEFI NVRAM

So the proper removal command was:

virsh undefine parrot-htb --nvram

Another reminder that a VM is more than a disk image.

Storage pools

Libvirt also has the concept of storage pools.

I ran:

virsh pool-list --all

and saw pools such as:

images
libvert
libvert-1

A storage pool is basically a libvirt-managed source of storage from which volumes can be created and managed.

A virtual disk can therefore be thought of as:

storage pool
     │
     └── volume
            │
            └── QCOW2

This is another abstraction layer.

One confusing moment was trying:

virsh pool-info default

and getting:

Storage pool not found

That’s because default in my case was the network, not a storage pool.

Libvirt uses names such as default in multiple contexts, so this is something to keep in mind.

Why QCOW2?

QCOW2 is QEMU’s Copy-On-Write disk image format.

Instead of immediately allocating the entire advertised capacity, the image can grow as data is written.

So a:

60GB QCOW2

doesn’t necessarily mean 60GB is consumed immediately.

It can start much smaller and grow towards its virtual capacity.

This also becomes interesting when snapshots are involved because copy-on-write allows the VM to maintain changed storage state relative to an earlier state.

Conceptually:

Base disk
   │
   ├── original blocks
   │
   └── changed blocks
          │
          ▼
       snapshot

For disposable security labs, this is very convenient.

Vagrant: the next abstraction

Vagrant is essentially an environment automation layer for virtual machines.

Instead of manually running commands such as:

virt-install ...
virsh ...
virsh ...
virsh ...

you can describe an environment in a Vagrantfile and let Vagrant construct it.

The stack becomes:

                 Vagrant
                    │
                Vagrantfile
                    │
              Vagrant provider
                    │
                 libvirt
                    │
                QEMU / KVM
                    │
                    ▼
                   VM

Vagrant itself is not the hypervisor.

It doesn’t replace QEMU, KVM or libvirt.

It sits above them and automates the creation and configuration of machines.

This becomes particularly interesting for my lab because instead of manually creating every target, I can describe parts of the environment as code.

Using Vagrant with `labnet`

This is where I think Vagrant can actually become useful for my setup.

The interesting use of Vagrant here is the INS lab, not my Parrot HTB VM.

Parrot already exists as a manually configured standalone VM on the default network. I don’t need Vagrant to manage it.

Instead, I can use Vagrant to reproduce machines that belong on my existing labnet.

The architecture becomes:

                  Vagrantfile
                       │
                       ▼
                    Vagrant
                       │
                 libvirt provider
                       │
                       ▼
                    libvirt
                       │
                     labnet
                       │
          ┌────────────┼────────────┐
          │            │            │
       VM target    VM target     etc.

Vagrant’s libvirt provider can attach a VM to an existing libvirt network using:

libvirt__network_name: "labnet"

For example:

Vagrant.configure("2") do |config|

  config.vm.define "lab-target" do |target|

    target.vm.box = "debian/bookworm64"

    target.vm.network "private_network",
      ip: "192.168.100.20",
      libvirt__network_name: "labnet"

    target.vm.provider :libvirt do |libvirt|
      libvirt.memory = 1024
      libvirt.cpus = 1
    end

  end

end

The important bit is:

libvirt__network_name: "labnet"

That says:

Don’t invent another network. Connect this VM to my existing libvirt labnet.

Then:

vagrant up

can create the VM and connect it to the lab.

The interesting part is that the environment definition lives in the repository rather than only existing in my head.

For example:

INS-Lab/
├── Vagrantfile
├── provisioning/
│   ├── target.sh
│   └── setup.sh
└── README.md

Then I can potentially recreate the lab on another machine with the same basic structure.

Vagrant can also provision the guest after creating it:

config.vm.provision "shell", path: "provisioning/setup.sh"

This is where Vagrant starts becoming much more interesting than simply being a replacement for virt-install.

It gives me Infrastructure-as-Code for the virtual lab.

Vagrant vs Docker

There is an important distinction here.

Docker containers generally look like:

Host kernel
    │
    ├── container
    ├── container
    └── container

A VM looks like:

Host
 │
 └── hypervisor
       │
       ├── VM
       ├── VM
       └── VM

Containers share the host kernel.

Virtual machines have their own guest kernel.

For a cybersecurity lab where I want:

Linux attacker
Windows target
vulnerable Linux target

VMs make much more sense because I am interested in interacting with different operating systems and kernels, not just isolated applications.

Vagrant doesn’t change this.

It simply makes the VM environment easier to reproduce.

Why I didn’t start with Vagrant

Ironically, Vagrant could have made the whole process much easier.

But that would have defeated part of the purpose.

If I had started with:

vagrant up

I might have learned:

“This command makes a VM.”

Instead, I wanted to understand:

/dev/kvm
   ↓
KVM
   ↓
QEMU
   ↓
libvirt
   ↓
virt-install / virsh / virt-manager
   ↓
virtual hardware
   ↓
guest OS

Now, if I eventually use Vagrant, I understand what it is automating.

That is a much better position to be in.

The final topology

I ended up with two separate virtual environments because they serve two completely different purposes.

INS lab

This is the network I built for my Information and Network Security class.

                         Fedora Host
                              │
                          labnet_lab
                              │
              ┌───────────────┼───────────────┐
              │               │               │
           Windows       Metasploitable      Kali
            target          target         Distrobox

The vulnerable machines live here.

Kali is my attacker environment for this network.

The Fedora host itself can also interact with the network.

HTB environment

                         Fedora Host
                              │
                           default
                              │
                           ParrotOS
                              │
                           HTB VPN
                              │
                         Hack The Box

Parrot is my standalone HTB workstation.

My setup

This is the setup I ended up using while writing this.

Hardware

Laptop:
Acer Predator PHN16-71

CPU:
Intel Core i9-13900HX

GPU:
NVIDIA RTX 4060 Laptop GPU

RAM:
16 GB

Display:
2560 × 1600

The 16 GB RAM is probably the biggest constraint when running multiple VMs.

For example, running:

Parrot      4 GB
Windows     4 GB
Metasploit  512 MB

already puts a significant chunk of the machine’s memory into VMs before Fedora, QEMU, libvirt and everything else are considered.

This is why I generally kept the main machines around 4 GB rather than throwing 8 or 16 GB at them.

Host OS

Fedora Linux

The virtualization stack is:

Linux
  │
KVM
  │
QEMU
  │
libvirt
  │
virt-install / virsh / virt-manager

My user is also part of the relevant groups:

groups

which includes:

wheel
kvm
libvirt

Virtualization versions

At the time of writing, the versions on my machine were:

libvirt:
12.0.0

QEMU:
10.2.2

virt-install:
5.1.0

I checked these with:

virsh version

which returned:

Compiled against library: libvirt 12.0.0
Using library: libvirt 12.0.0
Using API: QEMU 12.0.0
Running hypervisor: QEMU 10.2.2

and:

virt-install --version

which returned:

5.1.0

I also checked the OS variants known to osinfo:

osinfo-query os | grep -i debian

and had:

debian13 | Debian 13 | 13

available, which is what I used as the --os-variant for Parrot.

VMs

The main VMs in the setup are:

metasploitable
    │
    └── vulnerable target for INS lab

windows-lab
    │
    └── Windows target for INS lab

parrot-htb
    │
    └── standalone HTB workstation

The storage lives under:

/var/lib/libvirt/images/

so the disks look roughly like:

/var/lib/libvirt/images/
├── metasploitable.qcow2
├── windows-lab.qcow2
└── parrot-htb.qcow2

The Windows installation ISO and VirtIO driver ISO were kept under:

/var/lib/libvirt/boot/

Networks

There are two important libvirt networks in my setup:

default
labnet

default is used by my standalone Parrot HTB VM.

labnet is my private INS class network:

192.168.100.0/24

with the virtual gateway:

192.168.100.1

and a DHCP range such as:

192.168.100.10
-
192.168.100.100

The intended architecture is:

                         Fedora Host
                              │
              ┌───────────────┴────────────────┐
              │                                │
            labnet                           default
              │                                │
        ┌─────┼─────┐                      Parrot
        │     │     │
     Windows Meta   Kali
               Distrobox

The two networks are deliberately separate.

Final thoughts

The biggest thing I took away wasn’t how to install a VM.

It was that a VM isn’t a single thing.

When I say:

“I have a Windows VM.”

I’m actually talking about a collection of layers:

Physical hardware
      │
      ▼
Linux kernel
      │
      ▼
KVM
      │
      ▼
QEMU
      │
      ├── virtual CPU
      ├── virtual RAM
      ├── virtual disk
      ├── virtual NIC
      ├── virtual TPM
      ├── virtual display
      └── virtual firmware
              │
              ▼
          Guest OS
              │
              ▼
         Applications

And sitting above QEMU/KVM is another layer:

virt-manager
virsh
virt-install
      │
      ▼
   libvirt
      │
      ▼
   QEMU/KVM

Then there are even more abstractions around specific resources:

libvirt
 ├── domains       → VMs
 ├── networks      → virtual networks
 ├── storage pools → storage management
 ├── volumes       → virtual disks
 └── snapshots     → rollback points

Once I understood that, a lot of the weird errors stopped being mysterious.

A permission error on a QCOW2 wasn’t “QEMU being weird”; it was the QEMU process having a different identity from my shell.

A missing Windows disk wasn’t “Windows failing”; it was the guest missing a VirtIO driver.

A UEFI security violation wasn’t “Parrot being broken”; it was virtual firmware enforcing Secure Boot.

qemu:///session and qemu:///system weren’t two versions of QEMU; they were two different libvirt scopes.

And /dev/kvm wasn’t a virtual machine; it was the kernel interface through which QEMU gets hardware-assisted virtualization.

The fact that I could put Windows, Metasploitable, my Fedora host, and Kali into one private network while keeping Parrot in a completely separate HTB environment also made the networking side of virtualization much more tangible.

That, more than anything, is why I’m glad I didn’t just install VirtualBox.

I wanted the feeling of:

“I did something.”

And the extra tinkering actually taught me something.

Encrypt Once, Boot Forever: TPM2 Auto-Unlock on Fedora 44

Anay Pandya — Wed, 20 May 2026 07:39:07 +0000

When I set up Fedora 44 on my Predator Helios Neo 16, I enabled full disk encryption using LUKS. Non-negotiable for a cybersecurity student.

The problem: every boot starts with a password prompt before anything loads. Fine in principle, friction in practice — especially when you're rebooting frequently during a fresh system setup.

The solution: seal the decryption key inside the TPM chip and let the hardware unlock the drive automatically on legitimate boots. No password prompt, full encryption intact.

This is how I set it up.

Understanding the pieces

LUKS

LUKS (Linux Unified Key Setup) is the standard disk encryption layer on Linux. When enabled, your entire partition is encrypted at rest. Before the OS can boot, something needs to provide the decryption key — normally that's you, typing a passphrase.

LUKS2 (the modern version, default on Fedora) supports multiple keyslots and tokens. Think of keyslots as different keys to the same lock — you can have a passphrase keyslot and a TPM keyslot simultaneously. Either one unlocks the drive.

TPM2

TPM (Trusted Platform Module) is a dedicated security chip on your motherboard. It's not software — it's physical hardware that stores cryptographic secrets and enforces conditions on when those secrets are
released.

The relevant capability here: the TPM can seal a secret to specific system state measurements. It will only release that secret if the system is in the expected state. Move the SSD to another machine? No TPM. Different hardware state? Key not released. Your data stays encrypted.

PCRs

PCR stands for Platform Configuration Register. These are values inside the TPM that represent measurements of different stages of your boot process — fingerprints of your firmware, bootloader, Secure Boot
configuration, and so on.

When you seal a key to a PCR, you're saying: "only release this key if PCR X has this exact value." The key relevant PCRs:

PCR	What it measures
0	UEFI firmware
7	Secure Boot state
14	Shim/bootloader

I bound to PCR 7 — the Secure Boot state. This means:

The key is released as long as Secure Boot policy hasn't changed
Firmware updates don't break it (PCR 0 would)
It's the right balance of security and usability for a daily driver

systemd-cryptenroll

systemd-cryptenroll is a tool built directly into systemd for enrolling hardware security tokens — including TPM2 — as LUKS keyslots.

I initially tried clevis, the older and more commonly documented approach. The bind command ran without errors, the tokens appeared in the LUKS dump, dracut rebuilt successfully — but the password prompt kept
appearing at boot. After debugging, the clevis dracut module simply wasn't making it into the initramfs reliably on Fedora 44.

systemd-cryptenroll solved it on the first try. On Fedora 44 with modern systemd, it's the right tool — tighter initramfs integration, no additional packages needed, and it just works.

The setup

Prerequisites

Fedora 44 with LUKS2 full disk encryption enabled
Secure Boot on (verify in BIOS)
TPM2 chip (verify below)

Step 1: Verify TPM2 is available

ls /dev/tpm*
# Expected: /dev/tpm0  /dev/tpmrm0

systemd-cryptenroll --tpm2-device=list
# Expected: shows your TPM2 device with driver info

My output:

PATH        DEVICE      DRIVER
/dev/tpmrm0 INTC6001:00 tpm_crb

The tpm_crb driver is the Intel TPM 2.0 on the i9-13900HX platform.
If you see output here, you're good.

Step 2: Identify your LUKS partition

lsblk
cat /etc/crypttab

My crypttab:

luks-67669a3d-... UUID=67669a3d-... none discard,x-initrd.attach

The partition is /dev/nvme0n1p7, UUID 67669a3d-.... Note your UUID
— you'll need it.

Step 3: Enroll the TPM2 key

sudo systemd-cryptenroll \\
  --tpm2-device=auto \\
  --tpm2-pcrs=7 \\
  /dev/nvme0n1p7

Enter your existing LUKS passphrase when prompted. This authorizes adding a new keyslot. The command:

Generates a new random key
Seals it inside the TPM against the current PCR 7 value
Adds it as a new LUKS2 keyslot with a systemd-tpm2 token

Your original passphrase keyslot is untouched.

Verify the enrollment:

sudo cryptsetup luksDump /dev/nvme0n1p7 | grep -A3 "Tokens"

You should see a systemd-tpm2 token entry.

Step 4: Update crypttab

sudo nano /etc/crypttab

Change the line from:

luks-UUID UUID=UUID none discard,x-initrd.attach

To:

luks-UUID UUID=UUID - discard,x-initrd.attach,tpm2-device=auto,tpm2-pcrs=7

Two changes: none becomes - (means "no keyfile, use token"), and
tpm2-device=auto,tpm2-pcrs=7 is appended to the options. This tells
the initramfs to attempt TPM2 unlock before falling back to passphrase.

Step 5: Rebuild initramfs

sudo dracut --force --regenerate-all

This rebuilds the initramfs for all installed kernels, baking in the TPM2 unlock logic. Let it complete fully before rebooting.

Step 6: Reboot

sudo reboot

The boot sequence should now go straight from GRUB to the KDE login screen — no passphrase prompt. The TPM provides the key automatically
during the initramfs stage.

Security model

This setup gives you encryption at rest against the realistic threat:
physical theft of the device or SSD.

Protected against:

SSD removed and accessed on another machine — no TPM, no key
Cold boot attacks on a powered-off or hibernated system
Forensic disk imaging without your hardware

Not protected against:

Someone stealing your running, logged-in laptop
Evil maid attacks with full hardware access over time
Your passphrase being compromised (keep it safe regardless)

The passphrase remains your fallback. If the TPM fails, if you flash firmware, or if Secure Boot state changes, the TPM unlock breaks and
you'll be prompted for the passphrase. Enter it, boot normally, then re-run the systemd-cryptenroll command to re-seal to the new state.

What breaks the seal

These events change PCR 7 and will require re-enrollment:

Flashing BIOS/UEFI firmware
Toggling Secure Boot in BIOS settings
TPM hardware failure or reset

When this happens: passphrase at boot → login → re-run step 3 → rebuild initramfs → done.

Hardware

Acer Predator Helios Neo 16
Intel i9-13900HX · RTX 4060 · 16GB RAM · 1TB NVMe
Fedora Linux 44 (KDE Plasma Desktop Edition)

The Bayesian Trap - A Mathematical Case for Trying Something New

Anay Pandya — Sat, 11 Apr 2026 10:52:17 +0000

Humans are notoriously terrible at intuitive probability.

Imagine you wake up feeling slightly off. You visit the doctor, and she runs a battery of tests. A week later, she calls with bad news: you tested positive for a rare disease that affects 0.1% of the population.

Panicked, you ask how accurate the test is. "It correctly identifies 99% of people who have the disease," she says, "and only gives a false positive to 1% of healthy people."

If you rely on your gut, you probably assume you have a 99% chance of being sick. But here's where the math kicks in.

Most people latch onto one thing the doctor said — "99% accurate" — and conclude that a positive result means a 99% chance of illness. The human brain is terrible at remembering the prior when presented with shiny new evidence. We fixate on the test's accuracy and forget the other crucial piece of information:

"...a rare disease that affects 0.1% of the population."

So which is it — 0.1% or 99%? Neither. The true probability depends on both — the accuracy of the test and the baseline rarity of the disease. The complete question is:

"Given that 0.1% of the population has this disease AND that you tested positive on a test that is 99% accurate, what are the actual chances you are sick?"

To answer this properly, we need Bayes' theorem.

The Pure Logic

Formulated in the 18th century by Thomas Bayes, the theorem calculates the probability of a hypothesis being true given new evidence:

In plain English: the probability of your hypothesis (A) being true given new evidence (B) depends heavily on P(A) — the prior probability, the baseline reality before the new evidence arrived.

In our medical example, the prior is the rarity of the disease: 0.1%. Because the disease is so rare, the sheer volume of false positives generated from the healthy population completely drowns out the true positives. Bayes' theorem forces us to respect that baseline reality before we let a single test result dictate our conclusions.

The Philosophy of Belief

When Richard Price first published Bayes' work, he compared it to a man emerging from a cave and seeing the sun rise for the first time. The man doesn't know if the sunrise is a permanent feature of the universe or a bizarre one-off event. But every subsequent sunrise updates his mental prior. With each new piece of evidence, his certainty approaches 100%.

We all do this subconsciously. Bayes' theorem is the algorithm running under the hood of human experience. And that is precisely where the trap lies.

Imagine you're trying to learn beatboxing. Let S be the probability of success, and let every approach you try be an action:

Action A — You follow YouTube tutorials. Doesn't help much.
Action B — You read a blog on technique. No real progress.
Action C — You find a dedicated tutorial website. Still not clicking.

With every failure, your brain updates its prior belief in success. Because your environment has been consistently hostile, P(S) begins to drift toward zero.

The Mathematical Imperative

Here is the danger of being too good at Bayesian updating. In Bayes' equation, if your prior P(A) drops to zero, the entire calculation zeroes out — permanently.

If you get stuck on Action C and your prior belief in success hits zero, you subconsciously conclude the game is unwinnable. You stop experimenting. You fall into a self-fulfilling prophecy: no new actions means no success, which perfectly validates your pessimistic prior.

But here's what most people miss. Failing at Action A doesn't mean P(S) is low. It means P(S|A) — the probability of success via that specific approach — is low. The true probability of success remains unknown. You've only ruled out one path.

The Implication

This leads to two uncomfortable truths:

You never truly know the probability of success. You only know the probability of success given your prior experiences — which are, by definition, limited.
Since you can't know the real P(S), Bayes' theorem tells you that you cannot definitively conclude something is impossible — only that your current approach isn't working.

The logical response? Keep experimenting. Try a different vector. The colloquial wisdom of "f*ck around and find out" turns out to have rigorous mathematical backing.

Conclusion

Let's return to the disease dilemma and actually do the math.

Plugging in the numbers:

P(Disease) = 0.001 (the prior — 0.1% prevalence)
P(Positive | Disease) = 0.99 (test correctly catches 99% of sick people)
P(Positive | No Disease) = 0.01 (1% false positive rate)

First, the total probability of testing positive:

Now applying Bayes' theorem:

Not 99%. Not 0.1%. Just 9% — surprising, but mathematically undeniable.

This is the Bayesian Trap in full effect. A 99% accurate test sounds ironclad until you factor in how rare the disease is. The prior swamps the evidence. Most people who test positive are, in fact, perfectly healthy — not because the test is bad, but because the disease is rare enough that false positives vastly outnumber true ones.

The lesson extends well beyond medicine. Whenever we encounter compelling new evidence — a positive test, a failed experiment, a string of rejections — our instinct is to let that evidence rewrite everything. Bayes' theorem says: slow down. Ask what you already knew before the evidence arrived, and how much weight that prior deserves. Strong evidence should update your beliefs — but it should never erase your baseline understanding of reality.

The framework is both humbling and liberating. Humbling, because it reveals how easily our intuition misleads us. Liberating, because it tells us that one data point — one test result, one failed attempt, one closed door — is almost never the whole story.

If you want to go deeper on this:

The Bayesian Trap by Veritasium — a masterclass in how Bayesian reasoning shapes everything from science to superstition.
Bayes theorem, the geometry of changing beliefs by 3Blue1Brown — a visual, intuition-building walkthrough that makes the math feel inevitable.

P.S. I didn't rediscover Bayes' theorem in a statistics textbook or a philosophy seminar. I found it buried in a PDF about Machine Learning methodologies while grinding through AI Red Teamer material on Hack The Box. The context was oddly perfect: in offensive security, every failed payload quietly erodes your confidence. Your internal P(success) bleeds toward zero with each dead end, and at some point you stop probing and start doubting whether the box is even solvable. Bayes reframes that spiral. A failed exploit doesn't indict the goal — it indicts the method. The prior on the target's vulnerabilities hasn't changed; only your evidence about one particular vector has. That distinction — between this approach failed and success is impossible — is the entire difference between a good hacker and one who gives up at the first hardened firewall.

You Don’t Need "Prompt Engineering" to Talk to AI

Anay Pandya — Tue, 25 Nov 2025 10:22:40 +0000

A simple guide to getting what you want from Large Language Models, from a student who lives in the lab.

There is a lot of noise right now about "Prompt Engineering." You see people selling courses, sharing 50-line "super prompts," and treating AI interaction like it’s a complex coding language.

And sure, if you are building a complex software application, that engineering matters. But for the everyday user—for my friends, my dad, or my peers in non-tech fields—you don't need to study the science of prompts to get good results.

If you can hold a conversation, you can master an LLM. You don't need a degree in "Prompt Engineering." You just need to understand the psychology of the machine.

I’m a senior student studying AI and Cybersecurity, so I spend a lot of time looking under the hood of these models. Here is my take on how to interact with them effectively, without making it a chore.

1. Understand How It "Thinks" (The Prediction Game)

To talk to an LLM (Large Language Model), you just need to understand one basic concept: It predicts the next word.

That’s it. It takes the text you typed, looks at the context, and guesses what word likely comes next. That is why you sometimes see the answer typing out one word at a time.

Think of it like this: Imagine you are having a conversation with a friend. You’re struggling to find the words, so your friend starts guessing what you mean based on:

Who they think you are.
What you were just talking about.
The vibe of the conversation.

The difference is, this "friend" (the AI) has read almost everything on the internet, so it has something to say about everything. But it still relies on you to set the scene. If you give it nothing, it guesses blindly. If you give it context, it reads your mind.

2. Context is Currency

This is the single biggest mistake people make: asking a naked question.

The AI doesn't know you, your job, or your style—unless you paste it in. The quality of your output depends entirely on the "Context" you provide. Think of context as the raw material the AI needs to build your answer.

Don't just ask: "Write an email to my boss." Do this instead: "Here is a draft of an email I wrote. Here are three bullet points I need to add. Rewrite this to sound more professional but keep it under 100 words."

Pro Tip: You can paste in old reports, rough drafts, or even screenshots (if the model supports images). The more "reference material" you give it, the less it has to guess.

3. Give It a "Role" (The Before & After)

Since the AI predicts words based on patterns, the easiest hack is to tell it who it is supposed to be. This changes the vocabulary and tone instantly.

❌ The Lazy Approach:

You: "Explain quantum physics." AI: Gives a dry, Wikipedia-style definition that is boring and hard to read.

✅ The "Role" Approach:

You: "Act as a friendly high school science teacher. Explain quantum physics to a class of 15-year-olds using an analogy about video games." AI: "Okay class! Imagine the universe is like a game rendering engine..."

See the difference? The prompt wasn't "engineered." You just gave the AI a persona.

4. Treat It Like a Podcast Interview

A common mistake is asking one giant, complex question and hoping for a perfect answer. That rarely works well.

Instead, treat the chat like you are interviewing someone. You want to "steer" the conversation.

Start broad: "Tell me about photography basics."
Drill down: "Okay, you mentioned 'ISO'. What is that?"
Apply it: "How would I use ISO to take a picture of the night sky?"
Review: "Here is a photo I took; critique it based on what we discussed."

This keeps the AI on track. You are building a "thread" of context that makes every subsequent answer smarter than the last.

5. Direct the Conversation

The AI is always looking for cues from you. To get the best result, you need to be in the "driver's seat" regarding three things:

Assumptions: What should it take for granted? (e.g., "Assume I have a limited budget.")
Ambiguity: What are you okay with being vague?
Specifics: What must be in the answer? (e.g., "Give me a list, not a paragraph.")

If you are vague, the AI will make assumptions for you—and they are usually boring ones.

6. Don't Over-Explain (The Brevity Rule)

Beginners often think that longer prompts are smarter. They write 300 words of instructions before getting to the point.

Don't do this. Over-explaining confuses the model. It forgets the beginning of your sentence by the time it gets to the end. Be clear, be direct, and use constraints.

Bad: "I want you to write a story that is kinda sad but also happy and maybe involves a cat but don't make it too long..."
Good: "Write a 200-word story about a cat. Tone: Bittersweet. Ending: Hopeful."

7. The "Yes-Man" Problem

There is a hidden quirk in these models you need to know about: They are instructed to be nice.

The creators of these models train them to be helpful, harmless, and friendly. While that sounds good, it often means the AI becomes a "Yes-Man." It acts like that overly polite friend who tells you your bad haircut looks great because they don't want to hurt your feelings.

If you have a fundamentally flawed idea, the AI might try to "sugar-coat" it or find a way to make it work, rather than telling you, "No, that's impossible."

The Fix: explicitly tell the AI to take off the kid gloves.

"Please critique my idea brutally. Don't sugar-coat it. Tell me exactly why this might fail."

8. How to Fix a Bad Answer

Sometimes, the AI just gets it wrong. It hallucinates, it rambles, or it misses the point. Don't start over from scratch—just steer it back.

The Clarify: "You misunderstood. I didn't mean X, I meant Y."
The Format Fix: "This is too dense. Rewrite it as a bulleted list."
The Reset: "Ignore the previous instruction. Let's try a different angle."
The Reasoning: "Explain exactly how you got to that number."

9. Watch Out for "The Confidence Trap"

Because the AI is designed to predict the next word that sounds correct, it will sometimes lie to you with 100% confidence.

If the AI doesn't know the answer, it might make one up because it fits the "pattern" of the sentence. Always double-check facts, especially for math, citations, or medical advice. Treat it like a smart friend who has had a few too many espressos—brilliant, but prone to exaggeration.

📝 The 10-Second Cheat Sheet

Save this for your next chat. To get a perfect response, just check these boxes:

Give it a Role: "Act as a..."
Provide Context: Paste in drafts, data, or background info.
Set Constraints: "Under 200 words," "Use a table," "No jargon."
Steer the Ship: If it goes off track, correct it immediately.
Invite Critique: Ask "What am I missing?"
Verify: Never trust a fact you didn't check yourself.

You don't need to be an engineer. You just need to be a good conversationalist.

About the Author

I’m a senior undergrad student exploring Cybersecurity and AI. I like breaking tech down so it actually makes sense.

How I Vibe Coded a Custom Telegram Downloader (Because Browser Throttling is the Worst)

Anay Pandya — Sat, 22 Nov 2025 06:59:51 +0000

We have all been there. You find a course file, a movie, or a project archive on Telegram that is over 1GB. You start the download via the Web or Desktop client, watch the progress bar pick up speed, and then you make the mistake of switching tabs or walking away to grab a coffee.

Ten minutes later, you check back. The progress bar hasn’t moved. The speed is 0 B/s. The download is stuck at 99%.

That gigabyte of data you successfully pulled is now a useless, orphaned file, forcing you to start the transfer from scratch.

While reading about this, realized the problem isn’t that Telegram is slow. The problem is that browsers and OSs hate long-running background tasks.

So, I created TeleDM (Telegram Download Manager). It solves this fundamental frustration by providing a robust, “fire and forget” way to download files from Telegram using the core protocol, eliminating the need to keep a tab in focus.

What is the Problem We’re Addressing?

The core problem TeleDM addresses is the fragility of large file transfers within the standard Telegram ecosystem.

Telegram is amazing for chat, but when you use it to download files exceeding 2GB, you hit a wall. Users consistently report:

Downloads failing silently when the app is
The “Start From Zero” bug: If a download is interrupted, the official Desktop client often fails to resume and restarts from 0%.
Link Expiry: Browser-based downloads rely on signed URLs that expire after an hour. If your internet is slow and the download takes 70 minutes, it will fail at the 60-minute mark.

The Technical Reality: Why Downloads Fail

It’s not just “bad Wi-Fi.” It is a software friction problem.

The Browser/OS Sabotage: Modern operating systems (iOS, Android, Windows) and browsers (Chrome, Edge) are obsessed with battery life and RAM. If a tab is in the background, the OS aggressively throttles its network access. A 2GB download requires a sustained, active connection. The moment you multitask, the OS sees the background process as “unnecessary” and kills the socket.
The Bot API Limit: Most developers try to solve this by building a simple Telegram Bot. But the standard Bot API has a hard limit: it cannot download files larger than 20MB. It is useless for the files that actually cause problems (movies, datasets, archives).

How TeleDM Solves It: The Architecture

TeleDM fixes these issues by abandoning the “Chat Client” approach and adopting a “Download Manager” architecture.

Bypassing the Bot Limit (MTProto)

TeleDM uses the native Telegram Client API (MTProto) via the Telethon

It does not act like a
It authenticates as you (the user).
This removes the file size limit, allowing downloads of up to 2GB (or 4GB for Premium users) directly.

The Headless Advantage

TeleDM runs as a system process, not a browser tab. It will happily utilize 100% of your bandwidth to download a file while you play a game, lock your screen, or switch workspaces. The OS does not throttle it because it doesn’t rely on UI focus to stay alive.

Robust Queue Management

Instead of trying to swallow the file in one go, TeleDM manages downloads in a persistent queue.

Persistence: If your internet cuts out, TeleDM keeps track of the download state in a local database.
Automatic Retries: If a download fails, the manager automatically queues it for retry, ensuring temporary network blips don’t kill your download.

Current Features (v1.0.0)

As of today, TeleDM is a functional application designed to do one thing well: Download reliably.

✅ MTProto Integration: Direct, high-speed connection to Telegram’s Datacenters.
✅ GUI Interface: A clean, modern graphical interface for managing downloads.
✅ CLI Interface: Simple command-line usage for pasting links and starting downloads.
✅ Large File Support: Successfully tested on files >2GB.

Roadmap: What’s Coming Next?

We are actively working to turn this from a script into a full-fledged application. Here is what is in the pipeline:

Resumable Downloads: Checks existing file size on disk before starting; resumes automatically if a partial file is found.
Multi-Threading: optimizing chunk requests to maximize bandwidth saturation.
Docker Support: A containerized version to run TeleDM on your NAS or Home Server easily.
Task Scheduling: Schedule heavy downloads for 3 AM when data is cheap or speed is fast.

Contributions Are Most Welcome!

This project was born out of personal frustration, but I know I’m not the only one facing this. TeleDM is open-source, and we need help to make it the ultimate Telegram utility.

Whether you are a Python pro, a UI designer, or just someone who wants to test it and break it — your contributions are appreciated.

Check out the repo, star it, and open a PR: 👉 github.com/ADPer0705/TeleDM

DEV Community: Anay Pandya

Dual Boot broken after Windows Updates - Fixing LUKS, NVIDIA and Time Sync

LUKS2 + TPM2 Auto-Unlock

NVIDIA

Time Sync

Conclusion

Secure Boot and MOK Enrollment

Hardware

How does an LLM "know" the sky is blue?

How LLMs work.

The Big Question

Virtualization — QEMU/KVM

Before anything else: does KVM actually work?

The first quirk: qemu:///session vs qemu:///system

Building the lab network

Why labnet exists

Creating the network

Connecting the machines to labnet

Creating the Metasploitable VM

Creating the Windows VM

The Third quirk: VirtIO

UEFI is also virtualized

Secure Boot and OVMF

Installing Parrot

Parrot and the default network

Creating Snapshots

Managing the VMs after creation

The UEFI NVRAM surprise

Storage pools

Why QCOW2?

Vagrant: the next abstraction

Using Vagrant with labnet

Vagrant vs Docker

Why I didn’t start with Vagrant

The final topology

INS lab

HTB environment

My setup

Hardware

Host OS

Virtualization versions

VMs

Networks

Final thoughts

Encrypt Once, Boot Forever: TPM2 Auto-Unlock on Fedora 44

Understanding the pieces

LUKS

TPM2

PCRs

systemd-cryptenroll

The setup

Prerequisites

Step 1: Verify TPM2 is available

Step 2: Identify your LUKS partition

Step 3: Enroll the TPM2 key

Step 4: Update crypttab

Step 5: Rebuild initramfs

Step 6: Reboot

Security model

What breaks the seal

Hardware

The Bayesian Trap - A Mathematical Case for Trying Something New

The Pure Logic

The Philosophy of Belief

The Mathematical Imperative

The Implication

Conclusion

You Don’t Need "Prompt Engineering" to Talk to AI

A simple guide to getting what you want from Large Language Models, from a student who lives in the lab.

1. Understand How It "Thinks" (The Prediction Game)

2. Context is Currency

3. Give It a "Role" (The Before & After)

4. Treat It Like a Podcast Interview

5. Direct the Conversation

6. Don't Over-Explain (The Brevity Rule)

7. The "Yes-Man" Problem

8. How to Fix a Bad Answer

9. Watch Out for "The Confidence Trap"

📝 The 10-Second Cheat Sheet

About the Author

The first quirk: `qemu:///session` vs `qemu:///system`

Why `labnet` exists

Connecting the machines to `labnet`

Parrot and the `default` network

Using Vagrant with `labnet`