ext4 module missing from grub2win installation?
Brought to you by:
drummerdp
Menu
▾
▴
long story short, i've been trying to dual boot kali linux alongside my existing windows installation. the setup has been giving me issues for days, and i've addressed every issue i've encountered to no avail. the kali installation exists on my drive, and the files are present as well (confirmed by using a debian live usb to access the partition and confirm the existence of the kernel/files required to boot, and create a uefi boot entry since there wasn't an existing one for kali), and yet i still can't boot into it. my last lead was the fact that in the grub terminal while in the grub2win menu, almost all of my partitions are listed as "No known filesystem detected", and when i use "insmod ext4", it says that the module doesn't exist. lo and behold, i check the installation on my pc, and sure enough, ext2.mod is present, but there is no ext4.mod to be found. why in the world would it be missing? unless i'm checking the wrong place, but considering the folder i checked is full of .mod files and includes an ext2.mod, and due to the aforementioned grub behavior, i am 99.9% certain i genuinely am missing the module. i am quite baffled, and while i hope it solves my boot issue, i really can't fathom why i would be missing such a random but essential module from my installation. any help or explanation would be appreciated, and i am including a diagnostic.
Hey Max,
I've seen this a couple of times recently.
First, there is no ext4.mod in the GNU Grub distribution and never has been.
All extx filesystems are handled by the GNU Grub ext2.mod code.
Second, apparently some Linux distributions are using non-standard ext4 formats which GNU Grub version 2.06 cannot handle at boot time. It shows "No known filesystem detected" for these partitions.
It is possible that the unreleased GNU Grub version 2.12 RC1 can decode these formats.
But 2.12 is still in beta so it's not helpful in this case.
A workaround is to use Ubuntu to properly create and format the ext4 partition and then install Kali to the preformatted partition without letting Kali actually format it.
Have a look at this discussion very similar to yours that happened recently.
The Ubuntu method worked for this Endeavour Linux user.
https://sourceforge.net/p/grub2win/discussion/general/thread/be098935d1/?limit=25#3b0a/a006
Please let me know if this works for you.
Note: I will be away on vacation with very limited computer access (iPad only) returning home September 24.
Thanks,
Dave
I see! That's actually incredibly interesting. Good to know that ext2 covers all the bases, and I'm not just missing something so crucial. That makes much more sense than it just missing the capabilities entirely. Thank you so much for your very quick response though!
I wonder if I could look into whether kali could be in the same boat as endeavor with the non-standard ext4 formats, because I suppose that would make all of my troubles make a lot more sense.
I actually had read through that thread, but admittedly wrote it off once it turned into re-installation as a solution, because I had already reinstalled kali multiple times and was frustrated at the idea of having to do it again, because the installation takes probably upwards of an hour. But, after continuing to have to fiddle with it for days, I think that may be my only other option at this point. I'm not sure when I'll get around to it, but I will try to set up the partition how you instructed before installing kali.
Thanks so much again!
Hey again Max,
Glad to help.
Please keep me posted on your progress.
I'll be watching from the sidelines with my iPad while I'm on vacation.
Dave
Dave,
Hello again. Throughout today I got around to following the previous instructions and reinstalling Kali, but much to my dismay I am in fact having the same issue as before with the "no such device", "no known filesystem detected", etc. I'll attach some pictures of the grub terminal at boot, and another diagnostic. Here are the bases I've covered:
I confirmed that my root directory is being identified correctly by GUID. The GUID in the grub.cfg in Kali's grub folder, as well as grub2win's Kali config, match the GUID provided by gparted on the Ubuntu live USB.
I noted that Linux identifies the hard drive containing the Kali installation as /dev/sdb, and the partition containing the installation is /dev/sdb4, with the EFI partition being /dev/sdb3.
I tested out how GRUB identifies my drives (the hdx,gptx format), and when I boot WITHOUT any other external USB in, it identifies my SSD as hd0, and my HDD as hd1. However, when I boot with a USB in (not a bootable one, just basic data storage), it shifts those over a number each. The USB becomes 0, the SSD 1, and the HDD 2.
I took note of the fact that Kali's grub.cfg file refers to both the GUID of the partition, as well as the (hd1,gpt4) address in multiple places. This is a little confusing to me -- maybe this is basic information I'm missing, but what is the difference between the two formats of address (dev vs. hdx)? From the format of the cfg file, I assume it uses the GUID as a fallback in case the other address doesn't work, but if the address changes when there's a new device introduced, why bother even using that address at all instead of an ID that is pretty much guaranteed not to change?
Also, I notice that in the grub terminal when attempting to boot, it says no such device, with the GUID, but then when I skip the countdown it moves on and says it set the root to the GUID. But then, it says "File not found" and "You need to boot the kernel first" when trying to find the kernel to run. Is this just incorrect feedback output, and it appears as if it set the root when it didn't, or is there something else going on? Apologies for the abundance of questions, I'm still learning some of the intricacies of this stuff. Linux tends to come easy to me when it's functioning as expected, but it gets complicated fast when it doesn't.
Thank you, and apologies for the very long response,
Max
pictures attached, I will attach the diagnostic in a separate reply (hopefully) because I can't attach the pictures and the diagnostic, too large of a request.
vvvv diagnostic vvvv
Hi again Max,
As i mentioned, I'm away from home working on my iPad.
This allows me only minimal diagnostic tools.
The relevant symptom is the "No Known Filesystem detected" message.
As soon as you see this message, you can be sure it is from bad ext4 formatting.
I suspect that Kali improperly reformatted the ext4 that you originally formatted with Ubuntu.
You can confirm this by formatting an ext4 partition under Ubuntu.
Do not install Kali to this partition.
Then immediately boot to Grub and run the ls command on the partition.
If the partition formatted by Ubuntu is OK, then that implicates the Kali install process.
Dave
Alright, thank you very much Apologies, I forgot about your vacation. Considering that the issue is still a bad partition, even though I'm specifically instructing Kali NOT to format it, I take it there wouldn't be much I could do to salvage this? I don't mind using a different distro, and I've never had this much trouble with any other distro either. I was just hoping to get into the more complicated stuff and I've had Kali recommended to me. But, no big deal if I can't get it up and running. God knows there's enough distros to go around, haha. I'll do what you mentioned about making the partition and leaving it empty to check when I get home.
I hope you're enjoying your vacation!
Max
A bit of an even more confusing update. I did as you suggested, by formatting the ext4 partition and then booting straight into grub. I'm still getting a NKFsD message. I was stumped before, but now even more so. Could it be that grub2win's grub is bad? I just installed grub2win fresh a few days ago during this entire process, and even updated it since then. This is getting even weirder.
Hey again Max,
Grub2Win is used by hundreds of users every day. No other reports of issues with normally formatted ext4 partitions. The Gnu Grub kernel and code are unchanged since early 2022.
Could this be some sort of wierd firmware or hardware issue? Probably not since I was able to create the exact same scenario on my machine when installing Endeavour Linux.
Question, Which Ubuntu boot disk did you use to format the ext4 partition? Was the partition actually created by Ubuntu or was it created elsewere?
You may also want to try formatting the partition btrfs instead of ext4.
I was able to install Endeavour Linux to btrfs without incident using the normal install disk.
There was no problem decoding btrfs by Gnu Grub at boot time.
There's a good writeup on the kali.org site about installing to btrfs.
Please let me know.
Thanks,
Dave
If I understand your question, I downloaded the latest LTS build from Ubuntu's website. The partition was created by ubuntu because I deleted the existing Kali partition using Ubuntu before reformatting. I can try again using btrfs later, and I'll keep you updated.
Thanks again,
Max
Update again. Same problem when formatted as btrfs.
Hi there, im one of the users that had the same problem as yours;
What procedure do you use to get the "grub.cfg" file from Kali? From what directory do you copy the file from? Do you install Kali in GPT UEFI mode or BIOS MBR mode? Have you tried booting into the system without importing the Grub config, using the Kali Linux config in Grub2Win if there is one or the Ubuntu/Debian config since Kali is based on Debian?
About this, most probably as far as i know it's just Grub2Win trying to continue the boot process but failing, since it couldn't find the disk via the GUID and couldn't open the initramfs kernel file to boot the system correctly.
If the problem still persists and you want to change distro for pentesting, i reccomend using Parrot Linux or Backbox, or installing a fresh install of whatever distro you'd like to fill it up with pentesting tools.
Hello,
Unfortunately, yes. Before making my forum post I had already covered all of my bases - checking boot modes, fiddling with grub2win, checking the GUID of the partition a million times, attempting to boot from the ubuntu autoconfig, attempting to boot from the debian autoconfig, and using the custom imported kali config (for which I don't remember the exact file path I used, but I believe it was the one grub2win tells you to use).
I already basically gave up on Kali. I don't think its an issue with my hardware or my PC itself, as it is a new computer, but I've already had linux dual-booted on it previously. The only other factors that seem out of place are the old boot entry (on an entirely different disk from the one I'm trying to use now), which I absolutely can't delete no matter how many times it seems like I did, and the fact that I tried installing Ubuntu instead yesterday, and that's having its own issues now but will at least get further into the boot process than Kali would. It's strange, I've never had this many issues with Linux before. Sure sometimes I've struggled with grub itself, but this is a whole new level of confusion and mess.
And shoutout to Dave for all his help. I wish the help had helped, but I appreciate the effort a LOT anyways.
I'll keep you guys updated on whether I get Ubuntu working. It's being weird too, but it's slightly more promising than Kali. If it means anything, it seems that installing Ubuntu this time around had the same issue as Kali in that it did not create a boot entry for itself, so I can't try to boot straight into it from the UEFI settings either. No access unless it's with my live USB or grub2win so far. It tries to boot, runs through some text in the terminal, and then it says the automatic fsck failed and a manual one is required. I perform the manual one, but it doesn't help so far. I can give more detail when I get home if either of you want, but I also understand if not. This is way off topic for my original post now, haha.
Max
Hi Max,
This is getting really wierd. I'm in Porrtugal with only my imagination to work with. No computer tools.
You might want to try the following to eliminate errant hardware and bad partition tables.
Unplug all drives except a single HD or SSD drive. No flash or SD cards.
Use Ubuntu boot disk to run gpartd.
Create a new GPT partition table on that single disk.
This will ensure that the environment is controlled and completely clear.
Now create two partitions, one ext4 and one btrfs.
Now boot into grub and see if these completely new partitions on a completely new disk are readable.
If this doesn't reveal the issue, I'm completely stumped.
Please let me know.
Thanks,
Dave
Last edit: Drummer 2023-09-09
Hi Dave,
By create a new partition table, do you mean to entirely clear and reformat the whole disk? Because it might be a while before I can get around to a fix like that. I may have an external HDD that I can borrow from someone to get my files off of the drive before I clear it, but I'm not sure. I can let you know more later on whether I would be able to do that anytime soon.
Thanks,
Max
Hey again Max,
Yes, creating a new GPT partition table effectively removes all partitions from the disk
The partition table is a special file at the front of your disk drive that describes the partitions that reside on that drive
If the partition table is corrupt or incorrectly formatted, you can see all kinds of strange problems with partitions on the drive.
It is not enough to simply delete the partitions, a new fresh partition table is reuired to help reveal the problem.
Thanks for your patience.
Dave
Update: I created a new GPT partition table and reformatted everything and created the correct partitions. Grub now recognizes every filesystem type on the drive besides the SWAP partition -- but I take it grub doesn't need that. It recognizes the fat EFI partition, the ntfs windows partition I made, and displays the linux filesystem as ext*.
I am going to continue to attempt to install Ubuntu, and hopefully I can get it up and running. At this point, Kali lost its appeal, and I'd rather install Ubuntu anyways, but it seems as though this uncovered issues that needed fixing anyways so I'm thankful I tried Kali at least!
Hey Max,
Thanks for the positive update.
So it seems that an improperly formatted partition table may have been the problem from the very start. Maybe the mystery is finally solved!
Please keep me updated on your progress.
Many thanks,
Dave
Hey Dave,
I'm sorry for my late response! The good news is, I have another positive update! After getting the GPT partition table recreated and double checking grub's functionality, I was able to install Ubuntu again onto the drive, and it worked like a charm. There weren't any errors and I was able to boot into it perfectly fine from grub2win after fixing the partition table. Thank you so much again for all of your help!! I don't think I could have figured out any of this on my own. Thank you for helping me through the very tedious process of elimination and figuring it out. :)
Thank you!!!!!
Max
Great!!
Glad it all worked out for you.
Dave