I wanted to try and give Kali linux a shot installed to bare metal on my Framework but ran into a problem right after making the USB media. Both with the just the installer image and live image when I go to boot from the USB on my laptop it goes directly to a blank grub screen exactly as described in these other two examples:
Neither thread seemed to get to an actual solution. I did find this guide by another Framework community member so clearly it did work at some point, as another example for the year before also had a forum member report a successful install:
When I use the same USB media on my desktop both boot properly, it’s just with my Framework laptop, which I did just update the BIOS of so I secure boot is disabled per the Kali install instructions.
Could anyone else confirm if this is just me or if it’s a possible problem with current 2022.4 image and the Framework BIOS?
Note: Mine is an 11th gen main-board.
Thanks!
Edit: I just tried the old version, 2021.2, and had the same behaviour. I also tried burning the install media using dd instead of Etcher but both attempts had the results as above.
Yep, still getting the same behaviour. Flashed a fresh USB just now just to be sure cause I noticed those instructions show using the conv=fsync flag using the dd method. But same as before, the USB boots and works just fine on my desktop but on my Framework I just get that black screen and cursor.
Is there some setting in my BIOS I should be checking? I even added the EFI hash as trusted and Secure Boot is definitely disabled so I’m not sure what else to try.
Okay, I have something, and I’m not sure what it is or why this behaviour is what it is.
So this wasn’t just with the Kali installation, with another USB installer with Debian 11 flashed I got the same behaviour. After realising this I opened up the laptop and pulled my NVMe SSD with my main OS and BOOM, the Live media USB booted! Both Kali and Debian.
My NVMe SSD has PopOS 22.04 installed to it. I’m not sure what it might be about the Pop installation that would stop a USB installer from booting. After all, I selected to boot from the USB, why would Grub read any data at all from the NVMe?
So I’m at a loss, but it is what is. If anyone might be able to provide an explanation that’d be cool. I might cross post this over to the System76 forums just so they’re aware because I doubt this is just because my specific installation, I had reinstalled Pop fresh a few weeks ago.
Okay, so clearly we may have a drive issue. I’d try re-seating it one more time. Check that it’s seen in the BIOS. Please also open a support ticket for this as it sounds like the NVMe drive is the culprit.
I had this same problem. I’m not sure of the exact cause but I am sure of the solution from within the grub> prompt. I figured out how to do this from this thread.
This assumes you are trying to do a live boot of kali linux. It might work for dual-booting as well others but I haven’t guaranteed it.
run ls to see all drives/partitions available.
Identify which of these drives/partitions is your kali linux bootable USB. (You can do this by exploring the folders within the drive by usingls (drive)/. The trailing forward slash is necessary for the ls command to return any output. If you are unable to see what’s in a file with ls, then this is not the correct drive.)
Using the kali linux drive you have just found, run the following commands, replacing (drive) with your own drive’s name: set cmdpath=(drive)/EFI/kali set prefix=(drive)/boot/grub set root=(drive) insmod normal normal
This is all it took for me, and I was able to get to the graphical Kali Linux installation prompt. Something between PopOS and Kali Linux seems to screw with the bootloader. Grub is a finnicky thing. I hope this helps in the future.
I just wasted almost a day on this problem. It looks like the issue is caused in part by the existence of /.disk/info on the PopOS recovery partition that gets created as part of their standard install. I looked through the Kali grub configs and saw this:
search --set=root --file /.disk/info
set prefix=($root)/boot/grub
configfile ($root)/boot/grub/grub.cfg
The value of the root device is set to the first one found that has a /.disk/info file in its filesystem. This appears to be baked into a few of Kali’s binary boot files so the simplest workaround is to instead move the one in PopOS’ recovery partition into a backup location.
I confirmed that moving it fixed the Kali boot issue for me, but I’m not sure if it has any negative impact on any of the PopOS recovery features. I don’t have much of a need for those so I haven’t tested what impact this change has there, if any.
Edit: Looks like at a minimum it causes the recovery image checksum process to fail during boot since the file is obviously no longer there; it was able to boot successfully despite the error message though.
Disregard the above, that error is expected since there’s no /cdrom mount containing hashes for verification. In the end I upgraded my /recovery filesystem to ext4 and setup a symlink for .dist/info since grub can’t follow them. That solves the problem and gives me some peace of mind that recovery features will work should I need them.