I've recently discovered an interesting problem that makes it impossible / very difficult to install Kali onto a flash drive.

When you finish the Kali installation, GRUB will be installed as well (either on the first disk or wherever you set it). And after you reboot you computer, you'll be able to actually boot into it.

Problem appears when you change your hardware setup (plug/unplug any storage media). You will be able to get into the GRUB menu, but you won't be able to boot into Kali. The reason is most likely that GRUB expects the device to appear the same as before (you've installed Kali onto /dev/sdc, disconnected the installation flash drive and now your Kali flash drive is /dev/sdb, but its GRUB expects it to remain at the same address - /dev/sdc).

So, the question is: Is there any way to make an actually portable Kali flash drive?

Before you mention it:

  • I'm aware of the "live with persistence" boot option, but it's not particularly convenient for me. Besides, I'm curious why doesn't this work with Kali when I'm pretty sure that I've seen this work with Ubuntu quite well.
  • I've already tried the VirtualBox workaround and I wasn't particularly successful with it (Kali only worked for as long as the flash drive remained /dev/sda). Doing the same in VMWare resulted in the very same failure.

I've done what you mention, and I hadn't got problems booting kali from GRUB. I removed the installation media and it just worked.

Anyhow, you can edit the boot command on grub the first time to modify the boot partition and reach the graphical interface. Then, just configure the GRUB to use the disk UUID instead of the sdX names.

You can do that following a process similar to this one: https://askubuntu.com/questions/171446/how-to-fix-the-uuid-in-grub-after-restore-from-another-machine

| improve this answer | |
  • So the UUID is independent on the sdXY identifier, the disk order, etc.? Will it always remain the same for the same device? – natiiix Dec 24 '16 at 3:53
  • Okay, thank you very much. It seems that changing the /dev/sdXY to UUID=ZZZZ actually solved the problem. Too bad it's not clearly mentioned in the GRUB 2.0 manual. Yeah and about the first thing you've mentioned. Your installation disk could have had higher X value than the disk you've installed it onto. Then this problem wouldn't probably occur. – natiiix Dec 24 '16 at 4:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.