Search Criteria
Package Details: limine-entry-tool 1.40.0-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/limine-entry-tool.git (read-only, click to copy) |
|---|---|
| Package Base: | limine-entry-tool |
| Description: | Entry management for the Limine bootloader. |
| Upstream URL: | https://gitlab.com/Zesko/limine-entry-tool |
| Keywords: | boot entry hook limine |
| Licenses: | GPL3 |
| Conflicts: | limine-entry-tool |
| Provides: | limine-entry-tool |
| Submitter: | Zesko |
| Maintainer: | Zesko |
| Last Packager: | Zesko |
| Votes: | 6 |
| Popularity: | 0.77 |
| First Submitted: | 2025-03-28 14:34 (UTC) |
| Last Updated: | 2026-09-27 09:41 (UTC) |
Dependencies (7)
- bash (bash-gitAUR, bash-devel-gitAUR)
- efibootmgr (efibootmgr-json-gitAUR, efibootmgr-gitAUR)
- grep (grep-gitAUR, grep-compatAUR)
- limine
- tar (tar-gitAUR)
- git (git-gitAUR, git-glAUR, git-wd40AUR) (make)
- gradle (make)
Latest Comments
seryogakovalyov commented on 2026-04-27 09:26 (UTC)
Tested with SKIP_LIMINE_VERSION_CHECK=yes - upgraded to Limine 12 successfully.
System boots fine with Secure Boot enabled and full BLAKE2B hashes in config.
Looks compatible so far, thanks!
Zesko commented on 2026-04-27 09:18 (UTC) (edited on 2026-04-27 09:19 (UTC) by Zesko)
@seryogakovalyov
I noticed that Limine v12 does not force config checksum enrollment for Secure boot, while the trunk version does. I am not sure whether this is simply disabled by default in v12.
The entry tool allows you to upgrade any custom Limine version if you enable
SKIP_LIMINE_VERSION_CHECK=yesin/etc/default/limineseryogakovalyov commented on 2026-04-27 09:01 (UTC) (edited on 2026-04-27 09:17 (UTC) by seryogakovalyov)
Limine 12 introduces Secure Boot hash enforcement, but limine-entry-tool already appears to generate the required BLAKE2B hashes correctly.
However, it currently blocks Limine ≥12 and skips EFI updates, leaving systems on Limine 11.
Might be worth confirming compatibility and relaxing the version check if everything is already in place.
Zesko commented on 2025-08-02 15:00 (UTC) (edited on 2025-08-02 15:09 (UTC) by Zesko)
findmnt is technically correct. autofs itself is not fat32, but it is a parent-directory that contains a submount with a filesystem such as fat32, depending on your autofs configuration.
If limine-entry-tool is inspecting a path of the parent-directory directly, it will only see autofs, not fat32, unless you change the mount path.
In this case, you should explicitly set ESP_PATH=[path/to/fat32] to the actual FAT32 mount point created by autofs — not the autofs parent directory itself (e.g., /efi as autofs), but the submount directory inside it (e.g., /efi/any_fat32_directory_name) where the FAT32 filesystem is actually mounted by autofs.
retractant0916 commented on 2025-07-27 21:58 (UTC)
I have set up systemd automounting for my ESP and now, since it's reported as autofs in findmnt, even though it is formatted as FAT32, limine-entry-tool won't add entries to Limine. Is there any way to circumvent this? I'd like to keep systemd automounting, so my ESP doesn't get mounted when I hibernate and I can switch to Windows in dual boot setup. Thank you!