Manjaro KDE Bootloader - dual disk issue

Hey everyone, I’ve been trying to dual-boot Manjaro KDE alongside Windows 10, and I’ve hit some roadblocks. Here’s my setup:

Disk 1: Windows 10 only

Disk 2: Contains my personal files + newly created partitions for Manjaro:

One partition for Root (/)

One partition for /boot/efi

I installed Manjaro on Disk 2 without any issues. GRUB appeared after installation, but when I select Manjaro, I get these errors:

-Failure writing to sector (number) on hd2
-Failure reading from sector (number) on hd2
-You need to load kernel first

I unplugged all USB devices and rebooted, but now I see:

-Environment block too small
-Error reading sector (number) from hd1
-You need to load kernel first

I tried reinstalling GRUB using the following method:

Booted into a Manjaro live USB

Ran lsblk -f to identify root and EFI partitions

Mounted the partitions:

sudo mount /dev/sdXn /mnt # Root sudo mount /dev/sdYn /mnt/boot/efi # EFI sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys

  1. Entered chroot:

sudo chroot /mnt

  1. Tried reinstalling GRUB:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro update-grub

But grub-install fails with the error: “EFI variables are not supported on this system.” Even though I’m sure I’m in UEFI mode, not Legacy.

I’m stuck at this point. Any help or insight would be really appreciated!

recheck info for linux

in your UEFI

disable secure boot
disable fastboot
disks on AHCI
no legacy
no CSM
UEFI only or others ( not windows )

create profile for linux

you should see
UEFI < USB vendor name > < partition 1 > → boot in EFI

reboot on USB live manjaro and recheck all ( report if any return failed )

inxi  -Mxa ( check for UEFI only , not UEFI[legacy] or Bios )
test -d /sys/firmware/efi && echo efi || echo bios
efibootmgr 
lsblk -fs

then go in chroot ( report if any return failed )

manjaro-chroot -a
cat /etc/fstab 
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck 
grub-mkconfig -o /boot/grub/grub.cfg 
mkinitcpio -P
sync
exit 
2 Likes

Hey Thanks for the support,
i tried everything you have mentioned, Here is the complete konsole log.
everything seems to be fine yet i still gets the Issue, (even before grubmenu)
“error: Environment block too small.
error: failure reading sector 0x38a96d80 fron ‘hd2’
error: you need to load the kernel first.
Press any key to continue…
Failed to boot both default and fallback entries.”

Complete Console Log - Bootloader Issue - Pastebin.com
(if its trouble to access please tell ill paste the log here)

have you installed this ?

  -> Running post hook: [sbctl]
Secureboot key directory doesn't exist, not signing!

you should read carefully

2 Likes

I’m sorry but confused with you question.
I have disabled my sercue boot in my BIOS settings and not cleared Sercue boot keys. Do i need to do so ?

Also do i need to install sbctl and follow all the commands in given url ?
That seems like huge work

i cant go further , because you cant boot with secure boot with USB live iso.

  • can you explain where come this sbctl ?
  • have you used a script / git / github ?

@linux-aarhus : is there a solution , because this need a chroot , and we cant activate secure boot with USB live iso

No that is not necessary - disabling secure boot is prerequisite to boot a Manjaro ISO.

No that is not a requirement. You can keep secure boot disabled.

If you are getting the message your system is not booted using EFI but BIOS.

sbctl is a prerequisite to use secure boot and is included on recent ISO via the shared root filesystem.

shared/Packages-Root · master · Profiles & Settings / iso-profiles · GitLab

sbctl does not do anything on it’s own; without configuration - that is a key and a bundle - it is just sitting there.

If you feel the message is disturbing - remove the package

sudo pacman -Rns sbctl

Or you can leave it and instead run

sudo sbctl create-keys

@stephane already pointed you to the topic that describes how you setup secure boot - but unless you actually create a configuration, sbctl does absolutely nothing.

Let me emphasize - sbctl is not the reason for your woes.

1 Like

One notice before everything
Basically my root mount point on a disk which is connected via my cd/dvd rom. coz im tryina install this to old lap which doesnt have any extra storage.

As per @stephane’s instructions i booted into live usb (secure boot off) and logged into chroot and tired grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
no issues it passed without error. then did,
grub-mkconfig -o /boot/grub/grub.cfg
after executing that is the part where i got that sbctl error yet the execution completes.
Complete log as follows

Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.12-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-6.12-x86_64.img
Found initrd fallback image: /boot/initramfs-6.12-x86_64-fallback.img
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.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sdc1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdc1.  Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
done
[manjaro /]# mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux612.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.12-x86_64 -g /boot/initramfs-6.12-x86_64.img
==> Starting build: '6.12.21-4-MANJARO'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [microcode]
  -> Running build hook: [kms]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [plymouth]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.12-x86_64.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Running post hooks
  -> Running post hook: [sbctl]
Secureboot key directory doesn't exist, not signing!
==> Post processing done
==> Building image from preset: /etc/mkinitcpio.d/linux612.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.12-x86_64 -g /boot/initramfs-6.12-x86_64-fallback.img -S autodetect
==> Starting build: '6.12.21-4-MANJARO'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
  -> Running build hook: [modconf]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'wd719x'
==> WARNING: Possibly missing firmware for module: 'bfa'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
==> WARNING: Possibly missing firmware for module: 'qed'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'aic94xx'
==> WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [plymouth]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.12-x86_64-fallback.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Running post hooks
  -> Running post hook: [sbctl]
Secureboot key directory doesn't exist, not signing!
==> Post processing done ```
  • No i havent used any script /git / github just fresh installed and tried to boot

just followed above instructions only.

i havent tried that ? do i need to try so

basically now im struck on here

It is not an error - it is an information.

Just like these are warning messages …

This is a message telling you the key is not present - this is not an error - unless you expect the keys to be present - and you don’t - right?

Yes, I dont need those keys im already booting windows with rescue boot off.

Does that using Sata enclose mounted disk for my Root Directory can be the cause of these errors ?

Generally, yes, but please see your mainboard BIOS manual to verify the exact procedure; it can vary per manufacturer.

Note that the quoted commands would not have completed successfuly as there was nothing to separate them.

Either enter them as separate commands;

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro

update-grub

…or, like this:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro && update-grub

Notice the && between the commands.


At this point, more information would be needed to allow others to form an opinion. Please provide system information as described (below), as well as the outputs of the following commands;

  • lsblk -f
  • cat /etc/fstab

I’m sure someone will help when they are able.

Regards.


Welcome to the Manjaro community

As a new or infrequent forum user, please take some time to familiarise yourself with Forum requirements, and the many ways to use the forum to your benefit:


Update Announcements

The Update Announcements contain important information and a Known Issues and Solutions section that should generally be checked before posting a request for support.

System Information

While information from *-fetch type apps might be fine for someone wishing to buy your computer, for Support purposes it’s better to ask your system directly; :eyes:

Output of the inxi command with appropriate parameters will achieve this (naturally, formatted according to forum guidelines) and will generally be more useful for those wishing to help:

inxi --filter --verbosity=8

or the short form:

inxi -zv8

Be prepared to provide output from other commands whenever asked. It’s equally important to provide as much actionable information as possible in your first post, rather than simply indicating there is a problem.

Highly Recommended
Required Reading
Technical Resources

Hey thanks,
Here are requested informations
lsblk -f:

 ✔ 
NAME   FSTYPE   FSVER            LABEL            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squashfs 4.0                                                                          0   100% /run/miso/sfs/livefs
loop1  squashfs 4.0                                                                          0   100% /run/miso/sfs/mhwdfs
loop2  squashfs 4.0                                                                          0   100% /run/miso/sfs/desktopfs
loop3  squashfs 4.0                                                                          0   100% /run/miso/sfs/rootfs
sda                                                                                                   
├─sda1 ntfs                      System Reserved  74240A332409F8BE                                    
├─sda2 ntfs                                       C48E0C5D8E0C4A7E                                    
├─sda3 vfat     FAT32                             BCCB-5200                                           
├─sda4 ntfs                                       6EA679AAA6797405                                    
└─sda5 vfat     FAT32                             52C2-21B4                                           
sdb                                                                                                   
├─sdb1 ntfs                      Local Disk       3244C7DC44C7A0C9                                    
├─sdb2 ext4     1.0                               6d420b87-ae34-413f-a135-5f722a66affb                
└─sdb3 ntfs                      Local Disk       60B0D4D8B0D4B62E                                    
sdc    iso9660  Joliet Extension MANJARO_KDE_2500 2025-04-14-17-23-11-00                     0   100% /run/miso/bootmnt
├─sdc1 iso9660  Joliet Extension MANJARO_KDE_2500 2025-04-14-17-23-11-00                              
└─sdc2 vfat     FAT12            MISO_EFI         0880-DD28

And

cat /etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=52C2-21B4                            /boot/efi      vfat    defaults,umask=0077 0 2
UUID=6d420b87-ae34-413f-a135-5f722a66affb /              ext4    defaults

Mod edit:- Corrected minor formatting errors.
Still expecting system information, as requested.

You are having the $esp (EFI System Partition) on one disk and the root on the second disk.

As you say SATA enclosure - I assume it is connected using USB.

This could be the cause of your problem especially if the target - assumed USB connected - disk is not available when you try to boot the entry.

Always keep your $esp and root on the same disk.

Never mix EFI and BIOS boot - grub cannot handle the mix and it is therefore either/or when you are using grub.

IF you use the firmware boot override (like you do with install media) thus skipping the grub boot loader; there is no issues mixing EFI and BIOS - again - only if your $esp is on the same - assumed USB connected - disk.

Thank you everyone for the support—I found the issue.

It was my SATA enclosure. The enclosure was connected using IDE mode, which doesn’t support loading the kernel. Unfortunately, my BIOS doesn’t allow me to force the enclosure to use an AHCI connection. So, I mounted my boot mount point on a disk that is directly connected to the motherboard, which resolved the issue.

How did you reach that conclusion?

IDE mode is a common connection - in fact for decades the defacto standard - and as such it is supported quite well.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.