You are not logged in.
I have issues when installing grub (via grub-install) on a fresh arch linux installation within arch-chroot environment. The installation succeedes, but the system does not boot (nothing, really nothing visible happens).
However, when I install grub OUTSIDE arch-chroot (inside the linux arch live environment), the installation succeedes as well, and my computer boots normally.
Here are the details of my setup / environment:
- I followed this guide https://wiki.archlinux.org/title/Installation_guide
- I have an older netbook with 32 bit UEFI which supports 64 bit cpus
- The notebook has 32 GB mmc storage, 2GB Ram and a intel atom cpu (yes, it runs arch linux 64 bit, I will describe how)
- I have 4 partitions: p1:512 GB, /efi, p2: 512 GB, /boot, p3 [SWAP] 4GB, p4 /root (encrypted via Luks).
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk1 179:0 0 29.1G 0 disk
├─mmcblk1p1 179:1 0 512M 0 part /efi
├─mmcblk1p2 179:2 0 512M 0 part /boot
├─mmcblk1p3 179:3 0 4G 0 part [SWAP]
└─mmcblk1p4 179:4 0 24.1G 0 part
└─root 253:0 0 24.1G 0 crypt /
mmcblk1boot0 179:8 0 4M 1 disk
mmcblk1boot1 179:16 0 4M 1 disk - (I even managed to enable Secure boot, but this is probably not an important detail).
As mentioned, installing grub, via grub-install works in both cases (in arch-chroot and outside, meaning in the linux arch live iso environment). But only when I execute the command outside arch-chroot, meaning when I execute the install command in the linux arch live iso environment, my system boots after the installation properly. Probably one would think first, it is because the paths of efi and boot are wrong. I believe this is not the case, since I executed the grub-install command as follows:
a) Inside arch-chroot /mnt
grub-install --target=i386-efi --efi-directory=/efi --boot-directory=/boot --bootloader-id=arch --recheck
grub-mkconfig -o /boot/grub/grub.cfgb) outside arch-chroot /mnt, meaning inside regular arch linux live iso
grub-install --target=i386-efi --efi-directory=/mnt/efi --boot-directory=/mnt/boot --bootloader-id=arch --recheck
grub-mkconfig -o /mnt/boot/grub/grub.cfgThe target "i386-efi" is required, since the intel atom cpu only support 32 bit uefi. But I doubt, that this is somehow involved in my issue, since the system works properly when installing grub from the arch live iso and not from arch-chroot /mnt.
efibootmgr -v confirms, that I have in both cases a valid nvram entry (which is definitely the case, since I would not be able to boot the device and write this post. ;-)
But I really can't figure out, why I have to execute grub-install outside chroot. Even when I recently updated grub via pacman, I tried to install from my rrunning linux arch installation. But the result was the same: booting fails and there is nothing shown on the display. I only was able to fix it by booting from the arch linux iso again and install grub (again) from the iso live environment after mounting all partitions. Installation failed again from arch-chroot /mnt.
What is going on?
Last edited by Arphi (Yesterday 18:26:51)
Offline
"chroot" changes the meaning of "/". (root of directory hierarcy) you missed.
move necessary files manually or use /dev/sdX instead of "/" if grub accept it.
Offline
Thanks for the reply. But could you please elaborate what I "missed"?
I provided the values for the grub-install parameters --efi-directory and --boot-directory depending on whether I am in chroot, or not. So I do not believe that I missed something, since I considered these two paths.
But If I understood the meaning of these values or the way grub-install works, I'd appreciate a hint very much!!
Offline
hi. i insisted this is path issue but not because you did NOT something wrong instead grub is assumed something wrong and not expected it called inside chroot.
something "hardcoded" into grub cant understand it is called inside chroot.
its looks for a /dev/sdX to take it as root=/dev/sdX to boot i think.
it take that root=/dev/sdX wrong when called inside chroot i assumed.
to test:
after you issue the "grub --install" cmd inside chroot then see the path you give the grub to see whether grub put files there.
or save then compare grub created config files after install to see whether its different or same.
Last edited by unixman (Yesterday 18:54:03)
Offline
I am sorry, I would like to understand to try what you suggest, but I cannot follow. I am not sure, but what I understood, is, that grub (for some reason) seems to handle paths wrong, when installed chroot. I do not believe so, since almost every installation guide suggests the installation from inside chroot...
so I am still unsure what causes grub-install to function from outside chroot, although doing it inside chroot is the common approach...
Offline
edit my above post.
"since almost every installation guide suggests the installation from inside chroot"
i am not avare. just manupulating on top of given. sory.
since its an efi laptop you feel free to try others efi bootloaders if you take the issue serious.
Offline
i recently struggled installing arch linux; specifically with grub so if you have uefi i recommend just creating an entry in your efi with efibootmgr; please discard this advice if you have plans that absolutely involve grub, but as long as your kernel is not encrypted i believe you should not have an issue with luks. i can provide links to the wiki / my forum post but i dont want to insist on advice you may not necessarily be looking for!
Offline
@unixman
you're way off with this one
the old syntax
grub-install ... /dev/sdais for bios/legacy/csm only
as this is an efi system (no matter if 32bit efi or 64bit efi) the correct command is
grub-install ... --efi-directory=/efior whatever mountpoint of the ESP
so OP does call grub-install correctly
@Arphi
from when is your install image? a comparison between the versions would be interesting
please provide
pacman -Qi grubfrom both within the chroot / installed system and from the regular install media prompt
depending on how old your image is the one outside the chroot is likely older which could lead to hint some regression specific to your system
we had a couple of threads after the recent grub update causing issues on older hardware - so your system could be affected as well
in one thread there was a hint to the BLI module
can you please try this:
install grub from within the chroot
generate config from within the chroot
modify the config and commend out this section:
### BEGIN /etc/grub.d/25_bli ###
if [ "$grub_platform" = "efi" ]; then
insmod bli
fi
### END /etc/grub.d/25_bli ###then exit chroot and reboot
if this works this could hint to some regression in the BLI module - at least that was the solution in similar topics
Offline
@efog4
Thanks, but the issue does not lie with luks, although I struggled with it a bit as well. Luks works fine if configured properly, even when the kernel lies on the encrypted partition. grub for me is the only option I have, since my notebook only supports 32 bit uefi but the cpu (although quite old and weak) is already 64 bit cpu. Therefore I need a grubloader which supports mixed boot (32 bit uefi + 64 bit cpu). Grub supports it and even further supports signature validation of kernel, initramfs and other grub modules with custom keys. If it wasn't a 32 bit uefi system, i would have probably chosen another bootloader like systemd and go with Unified Kernel Images. (I hope this makes sense to you, since I learned all this only the last month.
@cryptearth
I thank you very much, and you have no idea how many hours this regression error took from me...
Regarding your requests:
1) It seems, that the arch live ISO image I use is "2025.09.01". At least this is what I found on the live iso image file system in /arch/x85_64/version.
2) output of pacman -Qi grub from arch-chroot (my installed system)
Name : grub
Version : 2:2.12.r418.g6b5c671d-1
Description : GNU GRand Unified Bootloader (2)
Architecture : x86_64
URL : https://www.gnu.org/software/grub/
Licenses : GPL-3.0-or-later
Groups : None
Provides : grub-bios grub-common grub-efi-x86_64 grub-emu
Depends On : device-mapper gettext sh xz
Optional Deps : dosfstools: For grub-mkrescue FAT FS and EFI support
efibootmgr: For grub-install EFI support [installed]
freetype2: For grub-mkfont usage [installed]
fuse3: For grub-mount usage [installed]
libisoburn: Provides xorriso for generating grub rescue iso using grub-mkrescue
libusb: For grub-emu USB support [installed]
lzop: For grub-mkrescue LZO support
mtools: For grub-mkrescue FAT FS support
os-prober: To detect other OSes when generating grub.cfg in BIOS systems
sdl: For grub-emu SDL support
Required By : None
Optional For : None
Conflicts With : grub-bios grub-common grub-efi-x86_64 grub-emu grub-legacy
Replaces : grub-common grub-bios grub-emu grub-efi-x86_64
Installed Size : 38.24 MiB
Packager : Tobias Powalowski <tpowa@archlinux.org>
Build Date : Mon Oct 13 07:07:12 2025
Install Date : Fri Oct 17 20:06:09 2025
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature3) output of pacman -Qi grub from NON arch-chroot (live arch is)
Name : grub
Version : 2:2.12.r292.g73d1c959-1
Description : GNU GRand Unified Bootloader (2)
Architecture : x86_64
URL : https://www.gnu.org/software/grub/
Licenses : GPL-3.0-or-later
Groups : None
Provides : grub-bios grub-common grub-efi-x86_64 grub-emu
Depends On : device-mapper gettext sh xz
Optional Deps : dosfstools: For grub-mkrescue FAT FS and EFI support [installed]
efibootmgr: For grub-install EFI support [installed]
freetype2: For grub-mkfont usage
fuse3: For grub-mount usage [installed]
libisoburn: Provides xorriso for generating grub rescue iso using grub-mkrescue
lzop: For grub-mkrescue LZO support [installed]
mtools: For grub-mkrescue FAT FS support [installed]
os-prober: To detect other OSes when generating grub.cfg in BIOS systems
Required By : None
Optional For : None
Conflicts With : grub-bios grub-common grub-efi-x86_64 grub-emu grub-legacy
Replaces : grub-common grub-bios grub-emu grub-efi-x86_64
Installed Size : 35.81 MiB
Packager : Christian Hesse <eworm@archlinux.org>
Build Date : Fri May 9 11:44:00 2025
Install Date : Mon Sep 1 16:37:18 2025
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature4) Yes, commenting the mentioned lines in /boot/grub/grub.cfg made the system boot again without any issues.
Maybe there is even another hint I can provide, but I have to verify this first
What I did not mention until now, that I installed grub also with providing a public pgp key and adding modules for signature verification so that I can verify grub modules I signed manually with own keys. When testing the grub installation from chroot, I also provided the keys, but I did not sign all grub modules. After reboot, the system loaded grub, but complained with something about signing. I booted again from the live stick, signed the modules as I did earlier and rebooted again. I expected the system to boot normally now, but at the end I got stuck with the frozen screen as described earlier.
I do not know what the BLI module is, but
a) It is the reason why my system did not boot when installing grub from my arch installation itself
b) it could be related to signature checking. But that is something I have to check again.
In case you would like me to do another "test", please let me know. Otherwise I suppose I have to add "[SOLVED]" in the subject and close the topic.
But once again: Thank you very much for pointing out, that it is a grub regression error and nothing else. Otherwise I would have doubted myself a bit...
Offline
well - when I first searched for "grub bli" as when I read the other topic only the doc came up with this: https://www.gnu.org/software/grub/manua … e/bli.html
seems harmless so far
HOWEVER: although not mentioned in the doc the BLI module seem to do something with TPM - more specifically something that has changed between the initial 1.0 and some 1.1 revision: https://bbs.archlinux.org/viewtopic.php?id=308474 -> https://lists.gnu.org/archive/html/grub … 00194.html and https://gitlab.archlinux.org/archlinux/ … /issues/14
so whatever that BLI module does - it does way more then what's noted in the doc - and as I don't have an easy way to browse grub source (I couldn't find any public repo and just git clone from gnu.org takes forever for me) I can't tell what's the connection between the BLI module and TPM stuff is - but it's linked somehow and causing issues with older hardware
btw - that's quite common: so many issues reported every day I just look at: "well, either it's me doing something right or everybody is doing something wrong - cause I'm not affected" - turns out: either some really old or really new hardware is used - or some very weird setups - or the user messed up some configs - in your case its just that damn old (and quite limited) hardware of yours - to which my very own opinion is: nothin wrong with usin old hardware - but use era-appropriate software - or simple: when you want to keep using a decade old hardware also use a decade old software on it - don't expect 10+ year old hardware to run smooth with something as close-to-upstream as arch
also: instead of splitting 2x 512mb for /efi and /boot I recommend either change the split more towards 100mb /efi + 900mb /boot - you won't ever need half a gig for anything bootloader related - but may exceed half a gig for kernel + initrd + maybe fallback initrd including a load of drivers - but that's up to you
Offline
@cryptearth
Thanks for the links!
The following made me think:
1) The Boot Loader Interface specifies a set of EFI variables that are used to communicate boot-time information between the bootloader and the operating system.
(from https://www.gnu.org/software/grub/manua … e/bli.html)
and
2) The call was added in the 1.1 revision of the spec, 1.0 does not have it, and there are some machines out there with a TPM2 and a UEFI firmware that only supports version 1.0, so the call fails in those cases. Check the reported version before calling get_active_pcr_banks().
(from https://lists.gnu.org/archive/html/grub … 00194.html)
I was wondering whether the Boot Loader Interface (BLI) not only provides some EFI variables to the system, but also some hints regarding the TPM version and protocols available (if any). I tried to figure out, whether the TPM version and protocols are stored in any uefi variables. This does NOT seem to be the case. Rather it seems that the TPM version is determined by bootloaders by looking for that "tpm protocol" by using some UEFI calls, since this information is not stored in UEFI variables directly.
Nevertheless, I was still surprised, how the TPM is involved in the boot process, because I assumed, that any key material which is used for signature verification of bootloader and other components (basically secure boot) is stored in the UEFI firmware / nvram (exept when I use grub and pgp signatures in my scenario, but that is something else). I googled a bit and this seems to be the case, that for pure signature verification no TPM is needed.
BUT there is something called "measured boot" which also involves a TPM. What happens is, that hash values of involved hardware and software components are stored in so called TPM PCRs (Platform Configuration Registers). So when Secure Boot is enabled, and whenever a hardware component changes, the hash of that component changes. The system can then pinpoint which component changed and tell the user by comparing hashes of earlier boots with the newer / later ones stored in the PCRs. (Seems like you can only add hashes, but not intentionally delete hashes).
Now have a look at the last sentence of the quote 2): Check the reported version before calling get_active_pcr_banks(). The type / version of the PCR banks seems to be checked in the grub module.
Based on my understanding, I would summarize:
- the grub bli module provides basic (environment) information to the loader like some uefi variable values AND information about the TPM (version and protocols)
- It seems, that the bli module is loaded quite early by the looader, which makes sense, because uefi variables and other environmental information need to be provided early
- the bli modules (in its current version) fails to check for the TPM PCRs (Platform Configuration Registers)
- Checking the PCRs happens in UEFI (done by grub). This makes sense, but it is not documented, that additional hardware like TPMs are checked
- The check for PCRs fails in certain cases
- When the check fails, a bootloop is the result (which would also fit to my problem description, since I did not see "nothing", but "nothing" ony my screen change.)
To me it all this makes sense, but I would like to emphasize, that I did not spend too much time with grub so far...
Maybe one important detail in case one uses this post as kind of error description in order to support fixing the issue in grub:
My notebook does NOT have a TPM at all! But I successfully enabled secure boot with grub 2:2.12.r292.g73d1c959-1 (from arch live iso). But the error with the newer grub version occured in both situations (with secure boot enabled and disabled).
Thanks @cryptearth. At the end, it was kind of fun to figure out how bli module and tpm are interacting (I hope what I understood the way it works correctly, and that it does not only make sense in my head).
Last but not least:
- Reagrding my disk layout and sizes of efi and boot partition. I totally agree. I wanted to be within recommended sizes (most say at least 512MB for efi and boot) just to be sure, that my booting issues is not related to the size of my efi partition. But since I only have 32 GB of disk space I definitely will rather split the layout as you suggested.
- Regarding hardware support: Fair enough. So far everything works very (!) smooth which surprised me. But I will try to keep in mind, that this could change in the future (when some hardware drivers are dropped from future releases). Thanks!
Offline
well - from what I understand about all that tpm stuff and secure boot and measured boot you seem to be quite spot on: that BLI module does something more than what's explained in its docs - it fails because it's written in a way implying any system complies with the 1.1 revision - and now something was changed between r292 and r359 the BIL module fails and causes boot loops
fun fact: if you would had used one iso later - the current october one - you would had not gotten away as it already has the faulty r359 with the breaking patch
Offline
Try to not use EFI partition. Even I don't have EFI partition, I can start my arch system
[root@XXX]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 500M 0 part /boot
└─sda2 8:2 0 19.5G 0 part
└─SYSTEM 254:0 0 19.5G 0 crypt
├─OS-SWAP 254:1 0 4G 0 lvm [SWAP]
└─OS-ROOT 254:2 0 15.5G 0 lvm /
sr0 11:0 1 1024M 0 rom
Offline