You are not logged in.
Hi,
On a recent Arch installation on a Dell Inspiron 15-7559, I came across a strange issue where after installing GRUB as part of the installation process (into EFI partition), after attempting to reboot into the system, GRUB did not load at all, and just rebooted back to the Dell logo in a continuous loop. I am dual booting so could still boot into the other OS by selecting in the boot menu.
After a bit of experimentation, I discovered that the loading of the bli module was causing the issue. I disabled this by making the grub script non-executable:
chmod -x /etc/grub.d/25_bli
and now everything seems to work fine.
Questions:
- Is this a bug that needs reporting somewhere?
- It it worth me adding to the wiki's GRUB page? I've not seen any posts here or elsewhere with this issue.
- Is this the best course of action - I'm not sure if bli is needed for anything, or if there's a better way to resolve this?
Thanks.
Offline
Hello,
I've had the same issue on my laptop, an ASUS N552VW.
I had to boot using the installation media to edit grub.cfg and comment out the bli lines and it worked. Then I did the same chmod command to prevent bli module lines from coming back on next update.
Thanks a lot for finding this solution!
Offline
https://www.gnu.org/software/grub/manua … e/bli.html
as both affected systems are laptops - and such issues or often happen on laptops (when you search for boot issues on laptops you find several topics) this is more likely caused by "faulty uefi implementations" - or more correct: firmwares specifically designed to work with the windows version of that sticker this device was certified for - and due to either incomplete or faulty implementations of the uefi spec break when trying to be used with anything but windows
hence: when you want to use linux on a laptop you should consider that before buying and look for a device specifically known to either at least work with linux - or, like frame.work or system76, specifically designed for linux
TL;DR: there's nothin to report or note in the wiki - other than reporting to the OEMs: "hey guys, your devices SUXX because you SUXX at correctly implementing the uefi specs correctly so they work with something else but windows" - but for consumer hardware the (now days likely ai done) standard reply "we don't support linux on consumer devices"
Last edited by cryptearth (2025-09-28 18:26:29)
Offline
**grub** package needs the fix applied: https://lists.gnu.org/archive/html/grub … 00194.html
Offline
well - then the docs need some extension, too - as they don't reflect that bli will interact with a tpm at all - hence my wrong assumption of a firmware bug - although it could be argued why the two devices mentioned in this topic are configured this way and if it's actuslly correct or in fact is a firmware bug - but as we likely won't get any info on that side all the open source community can do ONCE AGAIN work around OEMs not playing by the book
Offline
I reported now as a bug: https://gitlab.archlinux.org/archlinux/ … /issues/14
Offline