Hello!
I've tested it in windows and I don't understand why rufus changes the partition from fat32 to ntfs only in the live everything image, and not in the everything installer. The thing is that booting linux from a ntfs partition is not normal and we don't support it. So it isn't an issue with FAT32 as we do support it in grub

What you need to do is when you click the write button, you need to select the DD method instead of the ISO one, so that it uses the partition table from the iso image and not a custom one that rufus creates.

In the documentation we also recommend the DD-mode
https://www.kali.org/docs/usb/live-usb-install-with-windows/

I don't know Rufus or what it does, but I know for sure that a Kali iso should be copied "as is" on the USB device. There should be no need to talk about filesystems, FAT32 or NTFS. it's just about copying the raw data. Maybe that's what the "DD mode" of Rufus does (at least, that's what "dd" is for on Linux).

To both responses.

Rufus and etcher are both the documented method of installing a Kali ISO image. When choosing the Everything ISO, Rufus does not offer DD mode.

This issue can be replicated by simply following the documented install with both the normal live and the everything live ISO's. Only the Everything ISO fails.

Just a clarification - the option being used is to create a persistent boot USB.

I have been able to use the normal USB kali iso to build a persistent USB boot on a 512GB USB drive.

I used both Rufus and Etcher, neither worked for a persistent bootable USB. Not windows VM or other options. Perhaps the ISO works for other implementations, just not for persistent bootable USB.

I've tested it in windows and I don't understand why rufus changes the partition from fat32 to ntfs only in the live everything image, and not in the everything installer.

So, it makes sense. In the live image, basically the whole system lives in one file, the file "live/filesystem.squashfs". For a "normal" live image, this file is around 3.3 GB. However for the live-everything image, this file will be much bigger, and it will definitely be above 4 GB, which is the max file size for a FAT32 partition. Therefore Rufus is "smart", and forces the use of a NTFS filesystem instead. HOWEVER, grub (the bootloader) doesn't support a NTFS partition, so it will not be able to boot your USB key.

The everything installer image is a different beast. While the .iso is roughly the same size, it doesn't contain one big file like the live image, instead it contains a lot of files (packages), and there's no file that is bigger than 4 GB. So Rufus can use a FAT32 partition.

Now, let's add something else in the picture. If Rufus would let you use the DD method, I guess that it wouldn't even have to create a FAT32 or NTFS partition, instead it would just copy the .iso "as is" on the USB drive, and everything would work.

Just a clarification - the option being used is to create a persistent boot USB

Ok, so can you please do another test maybe: do NOT create a persistent boot USB. Just create the "basic thing" (don't know how Rufus calls it). I guess that then the DD method will be available. Then upon selection of the DD method, I guess that you'll have a functional live-everything USB drive. Except it will not be persistent as you want. But if you can confirm that non-persistent live-everything USB works, that would be already be a progress.

Thanks!

I tested it in windows with rufus and using the DD method everything works perfectly.

I think I know what he's doing. Rufus has a "persistent partition" option integrated in the settings, but adding it doesn't let you use the dd-method so it creates a ntfs partition for the everything live image, and therefore doesn't boot.

@jxxbrown did you follow the official documentation? https://www.kali.org/docs/usb/usb-persistence/

I followed the doc on https://www.kali.org/docs/usb/live-usb-install-with-windows/ but it does not explicitly cover peristence.

Test runs: (same USB stick)

1. USB, no persistence, Kali everything bootable image, using Etcher - boots, no problem
2. USB, no persistence, Kali everything bootable image, using Rufus (no DD prompt nor DD option offered in the app) - boots, no problem
3. USB, persistence (in Rufus now shows NTFS), Kali everything bootable image, using Rufus (no DD prompt nor option offered) - boot fails

So it does look like your assessment is correct. I have not done manual persistence, but the issue is clearly with Rufus at this point in terms of their persistence implementation. I will proceed with manual persistence steps and avoid the Rufus functionality.

I think this ticket can be closed.

Thanks for the help.

Just as a note, I will post the result of:

1. Create Kali everything image bootable USB with Etcher, no persistence
2. Follow the standalone doc to create persistence from the bootable USB

Thanks again.

I've updated the persistent live usb documentation and it's a bit easier now. You can even make the live usb persistent using the same Kali usb, I've tested it. fdisk will complain about the disk being in use, but it does create the partitions anyway and doesn't affect the usb, as it only uses the empty space left in the drive.

I'll add some comments in https://www.kali.org/docs/usb/live-usb-install-with-windows/ making it clear that the persistent option in rufus won't work with larger images and therefore the method from the documentation is the recommended for this case

I've updated the documentation, so I'm closing this now as this is an issue with rufus and not with the Kali images