You are not logged in.
Greetings.
I tried several times to no avail. Switched from systemd-boot to grub.
Now the os-prober is able to see the kali install on sda3, but is not listed at boot on the grub menu. I can chroot and that looks fine.
The only detail is that I installed kali with manually selecting the sda3 partition and the grub installation failed and I just skipped it, since I assumed I already have a functional install of grub on my arch system and would be just a matter of binding it to it.
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 511M 0 part /boot
├─sda2 8:2 0 79.4G 0 part /
└─sda3 8:3 0 78.4G 0 part /mnt
sdb 8:16 0 223.6G 0 disk
└─sdb1 8:17 0 223.6G 0 part
zram0 254:0 0 4G 0 disk [SWAP] sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img initramfs-linux-fallback.img
Found linux image: /boot/vmlinuz-6.0.0-kali3-amd64
Found initrd image: /boot/intel-ucode.img /boot/initrd.img-6.0.0-kali3-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Kali GNU/Linux Rolling on /dev/sda3
Adding boot menu entry for UEFI Firmware Settings ...
doneIm certainly missing some basic knowledge of how this structure works.
grub.cfg
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Kali GNU/Linux Rolling (on /dev/sda3)' --class kali --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-23464a37-4297-4f30-933e-a6eedbd608c3' {
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 23464a37-4297-4f30-933e-a6eedbd608c3
else
search --no-floppy --fs-uuid --set=root 23464a37-4297-4f30-933e-a6eedbd608c3
fi
linux /boot/vmlinuz-6.0.0-kali3-amd64 root=/dev/sda3
initrd /boot/initrd.img-6.0.0-kali3-amd64
}
submenu 'Advanced options for Kali GNU/Linux Rolling (on /dev/sda3)' $menuentry_id_option 'osprober-gnulinux-advanced-23464a37-4297-4f30-933e-a6eedbd608c3' {
menuentry 'Kali GNU/Linux Rolling (on /dev/sda3)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-6.0.0-kali3-amd64--23464a37-4297-4f30-933e-a6eedbd608c3' {
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 23464a37-4297-4f30-933e-a6eedbd608c3
else
search --no-floppy --fs-uuid --set=root 23464a37-4297-4f30-933e-a6eedbd608c3
fi
linux /boot/vmlinuz-6.0.0-kali3-amd64 root=/dev/sda3
initrd /boot/initrd.img-6.0.0-kali3-amd64
}
}
### END /etc/grub.d/30_os-prober ###thanks for any tips
Last edited by drkoma (2023-01-17 17:28:42)
Offline
Can we see the output of
efibootmgr -uJin, Jîyan, Azadî
Offline
efibootmgr -u
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0001* GRUB HD(1,GPT,9a63afd9-3bed-43c0-b3db-e9dd7ee235c8,0x800,0xff800)/File(\EFI\GRUB\grubx64.efi)
Boot2001* EFI USB Device 䍒
Boot2002* EFI DVD/CDROM 䍒
Boot2003* EFI Network 䍒
➜ ~Offline
What is on /dev/sdb? Your machine seems to be booting from an EFI system partition on that disk, or at least I think it is.
Check the output of
findmnt -no partuuid /dev/sdb1Does that match the PARTUUID listed in the efibootmgr output? (9a63afd9-3bed-43c0-b3db-e9dd7ee235c8)
EDIT: please also post the output of
grub-mkconfig | curl -F 'file=@-' 0x0.stLast edited by Head_on_a_Stick (2023-01-14 17:13:02)
Jin, Jîyan, Azadî
Offline
sdb its a second SSD drive for data
findmnt -no partuuid /dev/sdb1
223ff6c0-01$sudo grub-mkconfig | curl -F 'file=@-' 0x0.st
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img initramfs-linux-fallback.img
Found linux image: /boot/vmlinuz-6.0.0-kali3-amd64
Found initrd image: /boot/intel-ucode.img /boot/initrd.img-6.0.0-kali3-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Kali GNU/Linux Rolling on /dev/sda3
Adding boot menu entry for UEFI Firmware Settings ...
done
http://0x0.st/o7U7.txtOffline
sdb its a second SSD drive for data
findmnt -no partuuid /dev/sdb1 223ff6c0-01
Oops, sorry. I misinterpreted the efibbotmgr output, how silly of me. I presume the PARTUUID for /dev/sda1 matches the efibootmgr output then?
The full grub.cfg shows menuentries for booting Arch with Kali's kernel (which seems to be located on the ESP for some reason) in the "Advanced options" submenu and the os-prober menuentries are trying to boot Kali with Arch's kernel (which seems to be located on /dev/sda3 for some reason). That is very strange. Can you explain that at all?
What do you actually see when you boot the machine? What options are available? Have you tried all of the menuentries?
Jin, Jîyan, Azadî
Offline
sda3 would be correct for the kali install , and sda2 for the arch install
On the grub options I just have
Arch linux
Arch advanced options
Firmware
Offline
Once more:
Have you tried all of the menuentries?
I am thinking of the "advanced options" submenu in particular here.
Can we also see the output of
find /boot
cat /mnt/etc/fstab(With /dev/sda3 mounted under /mnt/.)
Jin, Jîyan, Azadî
Offline
find /boot
/boot
/boot/intel-ucode.img
/boot/vmlinuz-linux
/boot/initramfs-linux.img
/boot/initramfs-linux-fallback.img
/boot/EFI
/boot/EFI/grub
/boot/EFI/grub/grubx64.efi
/boot/EFI/arch
/boot/EFI/arch/grubx64.efi
/boot/loader
/boot/loader/entries
/boot/loader/entries/2022-12-31_13-08-35_linux.conf
/boot/loader/entries/kali.conf
/boot/initramfs-custom.img
/boot/vmlinuz-6.0.0-kali3-amd64
/boot/initrd.img-6.0.0-kali3-amd64
/boot/grub
/boot/grub/grub.cfgSorry the /mnt was just me experimienting by chrooting into kali
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 511M 0 part /boot
├─sda2 8:2 0 79.4G 0 part /
└─sda3 8:3 0 78.4G 0 part
sdb 8:16 0 223.6G 0 disk
└─sdb1 8:17 0 223.6G 0 part
zram0 254:0 0 4G 0 disk [SWAP]I really dont get it , it looks like it should appear. When I hit advanced options on grub it just shows like initfram fallback classic option , I dont have more kernels installed or something .
Offline
hmm, even this file looks correct
cat /boot/loader/entries/2022-12-31_13-08-35_linux.conf
# Created by: archinstall
# Created on: 2022-12-31_13-08-35
title Arch Linux (linux)
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options root=PARTUUID=e5e6a6d1-bde8-4f43-a42d-a034cafd5184 zswap.enabled=0 rw intel_pstate=no_hwp rootfstype=ext4
# Created by: archinstall
2 # Created on: 2022-12-31_13-08-35
3 title Kali (linux)
4 linux /vmlinuz-6.0.0-kali3-amd64
5 initrd /intel-ucode.img
6 initrd /initrd.img-6.0.0-kali3-amd64
7 options root=PARTUUID=90725d79-c421-4083-8713-2d04e270c806 zswap.enabled=0 rw intel_pstate=no_ hwpOffline
/boot/EFI/grub/grubx64.efi [...] /boot/EFI/arch/grubx64.efi
So you're probably not booting from Arch's current grubx64.efi then.
I presume you copied over the Kali kernel & initramfs to make systemd-boot work with them?
This should fix things:
# efibootmgr -b 1 -B
# grub-install --target=x86_64-efi --removable^ That removes the NVRAM entry that is loading /boot/EFI/grub/grubx64.efi and instead relies on the removable loader location, which should boot automatically once the old NVRAM entry is removed.
Another alternative is to generate a new NVRAM entry for Arch's grubx64.efi:
# efibootmgr --create --label 'Arch' --loader '/EFI/arch/grubx64.efi'But I'm not sure if that will work because grub-install from Arch should already have created it's own entry but that can't be seen in your efibootmgr output.
EDIT: also remove Kali's kernel & initramfs from the ESP, they will confuse grub-mkconfig and cause Kali to break when their kernel is updated.
Last edited by Head_on_a_Stick (2023-01-14 20:49:10)
Jin, Jîyan, Azadî
Offline
I presume you copied over the Kali kernel & initramfs to make systemd-boot work with them?
Thats exactly what I did , should have rembered and mentioned it.
*Edit , I deleted the files
grub-install --target=x86_64-efi --removable --efi-directory=/boot/EFI/
Installing for x86_64-efi platform.
Installation finished. No error reported.Just added the efi directory cause it was complaining about it .
Still no luck , I also tried regenerating with grub-mkconfig -o /boot/grub/grub.cfg
But yes , indeed this looks like something is off definitely
/boot/EFI
├── arch
│ └── grubx64.efi
├── EFI
│ └── BOOT
│ └── BOOTX64.EFI
└── grub
└── grubx64.efiIts indeed using EFI/arch/ according to efibootmgr
Boot0000* Arch HD(1,GPT,9a63afd9-3bed-43c0-b3db-e9dd7ee235c8,0x800,0xff800)/File(\EFI\arch\grubx64.efi)And probably my system modifies /boot/EFI/grub instead, right ?
Thanks for the hints I can kind of get the picture now but not a clear way to victory, but is a start
Another alternative is to generate a new NVRAM entry for Arch's grubx64.efi:
Tried but it just creates an extra entry at the end of the list which is the same as the one I had already
Last edited by drkoma (2023-01-15 10:20:13)
Offline
grub-install --target=x86_64-efi --removable --efi-directory=/boot/EFI/ Installing for x86_64-efi platform. Installation finished. No error reported.Just added the efi directory cause it was complaining about it .
But in your OP the EFI system partition is mounted under /boot/, not /boot/EFI/. Did you change the mountpoint? What is the content of /etc/fstab?
Its indeed using EFI/arch/ according to efibootmgr
Boot0000* Arch HD(1,GPT,9a63afd9-3bed-43c0-b3db-e9dd7ee235c8,0x800,0xff800)/File(\EFI\arch\grubx64.efi)
So what happens if you remove that NVRAM entry and just rely on $ESP/EFI/Boot/bootx64.efi instead? The system should boot that automatically in the absence of any specific EFI loader NVRAM entries.
Last edited by Head_on_a_Stick (2023-01-15 10:29:02)
Jin, Jîyan, Azadî
Offline
But in your OP the EFI system partition is mounted under /boot/, not /boot/EFI/. Did you change the mountpoint? What is the content of /etc/fstab?
Right , such a mess. I did not change actively anything on fstab that I know of
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=2f4784a2-77c3-40c1-b8d3-69d4f4c242c3 / ext4 rw,relatime 0 1
# /dev/sda1
UUID=443E-91C3 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
#UUID=2a89f1b2-a623-4160-911b-eeea30adef5f /home/xcarlo/second_drive ext4 auto,user,rw 0 0Just the second_drive to share data between future distros on distro hopping puprposes , but thats not going so well.
Should have installed grub by default when installing arch instead of this mess of going from systemd-boot to grub that Im at now.
So what happens if you remove that NVRAM entry and just rely on $ESP/EFI/Boot/bootx64.efi instead? The system should boot that automatically in the absence of any specific EFI loader NVRAM entries.
Im not sure If I understood correctly this.
EFI initramfs-custom.img initramfs-linux.img loader
grub initramfs-linux-fallback.img intel-ucode.img vmlinuz-linuxyou mean like this ?
efibootmgr -b 0 -B -vOffline
Hello from no bootable device :-)
In the end wasnt that bad , I arch-chroot and followed this stepts , nuking the /boot completely and regenerating did the trick
Now all entries are there , so SOLVED
I have other issues now but those are related to Kali , might as well try parrotOS for my school since we can use both.
Maybe parrot is more distro hoping fiendly
Thanks a lot for the tips
Offline
EDIT: waffle deleted.
Well I'm glad you got it fixed but unfortunately I still don't really understand why it was broken in the first place ![]()
Last edited by Head_on_a_Stick (2023-01-15 12:13:34)
Jin, Jîyan, Azadî
Offline
Well I guess I will not find out any soon. Parrot installation was much better , with the tiny detail that while the ParrotOS install worked , my main arch install was stuck on the boot logo of my vendor and wont work. Luckily could chroot from parrot and do some fixes also there , so yeah. Somehow marking it as solved.
Offline