View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007591||Kali Linux||[All Projects] General Bug||public||2022-02-18 12:13||2022-02-24 12:36|
|Target Version||Fixed in Version|
|Summary||0007591: Kali live boot (USB) Everything distro will not produce a bootable USB per documentation.|
|Description||I am new to Kali but have been unable to get a successful USB boot of Kali Linux on a Windows PC (UEFI mode) despite following the doc. After trying many iterations of using the recommended tools and suggested fixes, the best I could get was a boot to a grub command line.|
Making one change - switching to the point release live image - everything worked without issue.
Changing that back to Live Everything ISO resulted in the same failure, keeping everything the same
|Steps To Reproduce||1. Create bootable USB per doc using the point release iso - succeeds to boot|
2. Create bootable USB per doc using the Everything release iso - fails
|Additional Information||I noticed a couple of things using Rufus to create a persistent bootable USB - when I chose the everything iso, the file system in Rufus changes from Fat32 to NTFS no doubt because of the larget size. Perhaps this is the source of the problem as I have found mention of problems with a non-FAT filesystem on Windows UEFI based PC. |
Rufus doc may suggest a root cause, but this is beyond my linux knowledge.
From Rufus FAQ: https://github.com/pbatard/rufus/wiki/FAQ#Using_an_UEFI_bootable_ISO_based_on_grub_all_I_get_is_the_grub_prompt
Using an UEFI bootable ISO based on grub, all I get is the grub prompt
This can happen if the people who created the ISO chose not to add FAT32 module support in their GRUB EFI bootloader (for instance, the Manjaro distro maintainers are currently doing just that, which is VERY BAD PRACTICE), because they are relying a bit too much on the kludge that is ISOHybrid. Of course, since Rufus tries to use as much of the original ISO as it can, if the distro maintainers decide to use a crippled bootloader and completely ignore the de-facto way of booting a UEFI ISO, which is to copy all its content, as-is, onto a FAT32 drive, then you will encounter issues...
In this case, as Rufus explicitly advises you to do if you find that copying files in ISO-mode doesn't work properly, you can try recreating the USB and select DD-mode when prompted. Or you can voice your concerns directly to to the distro maintainers, so that they include FAT32 support in their GRUB EFI bootloader, as this is what they should have done from the start.
Alternatively, you may also run into issues when booting a drive that was partitioned as GPT if the distro maintainers also chose not to include the part_gpt module when running grub-mkimage (See here). In this case, you need to select MBR partition scheme for UEFI computer, and the grub.efi boot should work as expected.
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
||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.
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
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|
|2022-02-18 12:13||jxxbrown||New Issue|
|2022-02-21 19:40||daniruiz||Note Added: 0015788|
|2022-02-21 19:41||daniruiz||Assigned To||=> daniruiz|
|2022-02-21 19:41||daniruiz||Status||new => closed|
|2022-02-21 19:41||daniruiz||Resolution||open => no change required|
|2022-02-22 08:06||arnaudr||Note Added: 0015791|
|2022-02-22 18:37||jxxbrown||Status||closed => feedback|
|2022-02-22 18:37||jxxbrown||Resolution||no change required => reopened|
|2022-02-22 18:37||jxxbrown||Note Added: 0015798|
|2022-02-22 18:40||jxxbrown||Note Added: 0015799|
|2022-02-22 18:40||jxxbrown||Status||feedback => assigned|
|2022-02-23 04:24||arnaudr||Note Added: 0015800|
|2022-02-23 06:10||daniruiz||Note Added: 0015801|
|2022-02-23 18:33||jxxbrown||Note Added: 0015804|
|2022-02-23 18:51||jxxbrown||Note Added: 0015805|
|2022-02-24 09:14||daniruiz||Note Added: 0015811|
|2022-02-24 12:35||daniruiz||Note Added: 0015813|
|2022-02-24 12:36||daniruiz||Status||assigned => resolved|
|2022-02-24 12:36||daniruiz||Resolution||reopened => fixed|