Solved (Packaging an OS) Debian GRUB works while Kali's doesn't

Solved issue

berdanka

New Member
Joined
May 25, 2026
Messages
10
Reaction score
1
Credits
95
Hi everyone,

I am using live-build to create Kali Linux OS to then package it as boot.img and root.img. I am using a script that was made for Debian, just changing the repo to Kali's. However, with the GRUB from Kali's repo the EFI folder is much less populated and I am unable to boot properly. What could be the issue? (Also using grub-installer from the debian repo while keeping everything else from Kali repo didn't work either)

When I create a debian image instead of kali my EFI folder looks like this

.
├── EFI
│ ├── BOOT
│ │ ├── BOOTAA64.CSV
│ │ ├── BOOTAA64.EFI
│ │ ├── grub.cfg
│ │ ├── grubaa64.efi
│ │ └── mmaa64.efi
│ └── debian
│ ├── BOOTAA64.CSV
│ ├── fbaa64.efi
│ ├── grub.cfg
│ ├── grubaa64.efi
│ ├── mmaa64.efi
│ └── shimaa64.efi
└── m1n1
└── boot.bin

While Kali's looks like this:

├── EFI
│ ├── BOOT
│ │ └── BOOTAA64.EFI
│ └── kali
│ └── grubaa64.efi
└── m1n1
└── boot.bin

So why just by changing the repo, my EFI folders differs so much? Also below I attached the photo of boot failing with the Kali's EFI setup
 

Attachments

  • screenpic.jpeg
    screenpic.jpeg
    85.3 KB · Views: 29


Some more context:

I am trying to port Kali Linux on Apple Silicon. Due to MacOS being closed-sourced and the security measures it takes, it is a bit hard to make another OS work on Mac. The Asahi Linux project successfully achieved this, and made Fedora installable with just a one-liner script. Same goes for Debian Bananas Team, who did the same for Debian. Currently I am using their script with minor differences to also port Kali Linux.

The part that confuses me is that I almost don't change the script, except for changing the repo. However, creating a Debian image works fine while creating a Kali one lacks a lot of stuff in the EFI folder.

The repo: https://gitlab.com/the_dragons/m2-kali/image-packager
 
If Grub doesn't know where the boot image is, it can't boot it:-
Is the debian-asahi-image based on Debian Testing or Sid? Remember: Kali is built on Debian Testing.

I would look at what the Kali EFI folder lacks compared to the Debian equivalent.
And, double check your script....and sit back and think what could you add if anything.

--:Last thought of what you could try:--

Maybe try adding " systemd.unit=multi-user.target" to kernel cmd line when grub starts.
Press e when Grub comes up 'e' to edit and F10 to save.
It will start system in text mode, log-in and you're in. You can fix what's wrong but yo won't have a UI or browser.
Just an idea.:)
 
If Grub doesn't know where the boot image is, it can't boot it:-
Is the debian-asahi-image based on Debian Testing or Sid? Remember: Kali is built on Debian Testing.

I would look at what the Kali EFI folder lacks compared to the Debian equivalent.
And, double check your script....and sit back and think what could you add if anything.

--:Last thought of what you could try:--

Maybe try adding " systemd.unit=multi-user.target" to kernel cmd line when grub starts.
Press e when Grub comes up 'e' to edit and F10 to save.
It will start system in text mode, log-in and you're in. You can fix what's wrong but yo won't have a UI or browser.
Just an idea.:)
debian-asahi-image is also built on Debian Testing, so that's not the issue. Also, interestingly enough, using GRUB explicitly from Debian testing doesn't help either :/
Thanks for the advice though! I'll also send a text to Brickwizard
 
When one has only the grub rescue prompt it can only be a 'few things' going on that are holding up the show.

One of the things I recall is that if the grub config files are completely gone that will cause the system not to boot.
Do the initramfs Linux img and the vmlinuz files exit? (very important files)

You'll have to 'ls' into each one of your partitions to see which is the root. You'll need a Live Linux usb to do this.
You'll see: lost+found, /var, /dev, /etc, /sys, /proc, /lib64 and etc....

Once you find the /root partition you can set that drive as root with:
Code:
grub> set root=(hd0,msdos1)
grub> linux /boot/vmlinuz-linux root=/dev/sda1
grub> init
Possible commands are...
grub> initrd /boot/initr
possible files are....
grub> initrd /boot/initramfs-linux.img
grub> boot

If the grub config is missing you'll have to make it:

Code:
grub -mkconfig- -o /boot/grub/grub.cfg

Doing so should show your fall back initrd and iniramfs-linux image.Update grub and install grub.
Code:
grub-install /dev/sda
And reboot


This is 'just an example' from the grub boot prompt to try. You'll need to know which partition is your /root.

Code:
To manually boot from the grub rescue> prompt ...

grub rescue>  set root=(hd0,2)/boot
grub rescue>  insmod linux
grub rescue>  linux (hd0,2)/boot/vmlinuz-2.6.32-33-generic
grub rescue>  initrd (hd0,2)/boot/initrd.img-2.6.32-33-generic
grub rescue>  boot
 
When one has only the grub rescue prompt it can only be a 'few things' going on that are holding up the show.

One of the things I recall is that if the grub config files are completely gone that will cause the system not to boot.
Do the initramfs Linux img and the vmlinuz files exit? (very important files)

You'll have to 'ls' into each one of your partitions to see which is the root. You'll need a Live Linux usb to do this.
You'll see: lost+found, /var, /dev, /etc, /sys, /proc, /lib64 and etc....

Once you find the /root partition you can set that drive as root with:
Code:
grub> set root=(hd0,msdos1)
grub> linux /boot/vmlinuz-linux root=/dev/sda1
grub> init
Possible commands are...
grub> initrd /boot/initr
possible files are....
grub> initrd /boot/initramfs-linux.img
grub> boot

If the grub config is missing you'll have to make it:

Code:
grub -mkconfig- -o /boot/grub/grub.cfg

Doing so should show your fall back initrd and iniramfs-linux image.Update grub and install grub.
Code:
grub-install /dev/sda
And reboot


This is 'just an example' from the grub boot prompt to try. You'll need to know which partition is your /root.

Code:
To manually boot from the grub rescue> prompt ...

grub rescue>  set root=(hd0,2)/boot
grub rescue>  insmod linux
grub rescue>  linux (hd0,2)/boot/vmlinuz-2.6.32-33-generic
grub rescue>  initrd (hd0,2)/boot/initrd.img-2.6.32-33-generic
grub rescue>  boot
Soo for some reason it states that the filesystem for my supposed root partition is uknown, and for others it just states "ext2" without the contents, which is very weird
Considering that I create my partitions with
LODEVICE="$(losetup --show -Pf disk.img)"
mkfs.vfat "${LODEVICE}p1"
mkfs.ext4 "${LODEVICE}p2"
mkfs.ext4 "${LODEVICE}p3"
So now I will add more modules while installing grub, hopefully that will help


arch-chroot "${MNTDIR}" grub-install --modules="fat part_gpt ext2 efifwsearch" --target=arm64-efi --boot-directory=/boot --efi-directory=/boot/efi --removable
arch-chroot "${MNTDIR}" grub-install --modules="fat part_gpt ext2 efifwsearch" --target=arm64-efi --boot-directory=/boot --efi-directory=/boot/efi --recheck
arch-chroot "${MNTDIR}" update-grub
 
Our Moderator @Brickwizard may be able to advise you on this.
I can make a couple of quick comments as i have never tried a multi boot on an apple machine
Apple Silicon is a 64-bit ARM CPU so make sure you download the 64 bit arm version
once installed to get linux to boot you are not looking for a grub as such but the apple boot parameters, [differs on age and make of machine] try

  • Turn on your Mac and continue to press and hold the power button as your Mac starts up.
  • Release the power button when you see the startup options screen, which shows your startup disks and a gear icon labeled Options.
  • From this window you can start up from a different disk, start up in safe mode, use macOS Recovery, and more

I much prefer Parrotsec, a nice helpful membership and it has all the same tools as Kali [many of the Kali tool were written for other distributions the ported to Kali]
 
@Alexzee What could cause grub to not recognize the partition?
Sorry for the delay.

A deleted (resized) or corrupt partition. Maybe os-prober was disabled as it it by default. Bio's mode mismatches.
For example: System is MBR but BIOS is UEFI (and vise ver) then Grub can't read the partition table.

Power outage leading to: unexpected inconsistency (happened to me) so I fixed it with FSCK with a Live Debian usb thumb drive. Also, a bad sector on the HDD thus preventing Grub to be able to read the partition. OR> a loose SATA cable.

I'm familiar with mkfs.vfat however LODEVICE (loop device?) is foreign to me.
I read that the command attaches the disk.img and is saved directly to your device variable...... but again I don't know how it works.
 
Parrot is good I've tested it. Support on their forum is great! :)
Black Arch Linux is really good as well..... and has so many utilities that it's mind blowing!

-:Another thought is that the Mac machines boot manager may not be playing nice with Grub in some way shape or forum:-
 
I can make a couple of quick comments as i have never tried a multi boot on an apple machine
Apple Silicon is a 64-bit ARM CPU so make sure you download the 64 bit arm version
once installed to get linux to boot you are not looking for a grub as such but the apple boot parameters, [differs on age and make of machine] try

  • Turn on your Mac and continue to press and hold the power button as your Mac starts up.
  • Release the power button when you see the startup options screen, which shows your startup disks and a gear icon labeled Options.
  • From this window you can start up from a different disk, start up in safe mode, use macOS Recovery, and more

I much prefer Parrotsec, a nice helpful membership and it has all the same tools as Kali [many of the Kali tool were written for other distributions the ported to Kali]
I am using the framework that is used by Asahi Linux, where they use U-boot to launch GRUB

I forked repo that is used to build working Debian Asahi images and am trying to implement the Kali's repo, but for some reason just by changing the repo GRUB stops working properly

My assumption is that the grub-install binary used on Kali Linux differs from the Debian Testing one, so right now I am trying to create the image using grub-install --modules"..."

Hopefully this works :)

(Currently will be using all modules that are default on ubuntu)
 
Sorry for the delay.

A deleted (resized) or corrupt partition. Maybe os-prober was disabled as it it by default. Bio's mode mismatches.
For example: System is MBR but BIOS is UEFI (and vise ver) then Grub can't read the partition table.

Power outage leading to: unexpected inconsistency (happened to me) so I fixed it with FSCK with a Live Debian usb thumb drive. Also, a bad sector on the HDD thus preventing Grub to be able to read the partition. OR> a loose SATA cable.

I'm familiar with mkfs.vfat however LODEVICE (loop device?) is foreign to me.
I read that the command attaches the disk.img and is saved directly to your device variable...... but again I don't know how it works.
LODEVICE is used to attach a disk image as a /dev/loop1 device

The part that confuses me is that GRUB fails to recognize the root partition even though it has the same ext4 filesystem as the others, which it recognizes :(

I assume it is due to Kali's grub-install possibly having less default modules, so will try adding more modules and installing like that

grub-install --modules"..."

Will report on whether it worked or not once its done being created :)
 
Parrot is good I've tested it. Support on their forum is great! :)
Black Arch Linux is really good as well..... and has so many utilities that it's mind blowing!

-:Another thought is that the Mac machines boot manager may not be playing nice with Grub in some way shape or forum:-
I am using U-boot to launch GRUB (Process that Asahi Linux uses), so the mac shouldn't be the issue

Also I tried converting the disk.img to a VirtualBox disk and launching it, grub also fails there. So I assume the issue is in the image itself.

Does GRUB have some kind of limits on partition sizes? Another big difference from the Debian Image that I based the Kali on is that I create a larger root partition to accommodate all of its tools (32 GB, compared to standart 12 GB used by Debian)
 
I am using U-boot to launch GRUB (Process that Asahi Linux uses), so the mac shouldn't be the issue

Also I tried converting the disk.img to a VirtualBox disk and launching it, grub also fails there. So I assume the issue is in the image itself.

Does GRUB have some kind of limits on partition sizes? Another big difference from the Debian Image that I based the Kali on is that I create a larger root partition to accommodate all of its tools (32 GB, compared to standart 12 GB used by Debian)
Looking in the GNU Grub Manual....the platform limitations for Grub is 1 EiB (Exbibyte).

Lack of modules could very well be the issue. I think your right on this.
**-Further thought is that the mod's will be different from Debian verses Kali because of more or less lib's and engines that are not identical to Debian testing or sid.

I'd ask one of the dev's over on the web page for Asahi Linux OR> join Git Hub and ask there.
 
Looking in the GNU Grub Manual....the platform limitations for Grub is 1 EiB (Exbibyte).

Lack of modules could very well be the issue. I think your right on this.
**-Further thought is that the mod's will be different from Debian verses Kali because of more or less lib's and engines that are not identical to Debian testing or sid.

I'd ask one of the dev's over on the web page for Asahi Linux OR> join Git Hub and ask there.
Turns out the mods were the issue! Added Ubuntu's default ones and fixed the issue. Thank you and everyone else for their time and support! :)
 
Turns out the mods were the issue! Added Ubuntu's default ones and fixed the issue. Thank you and everyone else for their time and support! :)
You're welcome berdanka.Thanks for the details.
 


Follow Linux.org

Staff online

Members online


Top