summaryrefslogtreecommitdiff
path: root/config/grub
AgeCommit message (Collapse)Author
2024-06-01grub.cfg: remove unnecessary path for isolinuxLeah Rowe
the path "/boot/EFI" is unnecessary because the ESP is always a FAT32 partition, so we don't need to scan it as a subdirectory within a subdirectory. the ESP is always mounted as its own partition, FAT32, and EFI/ is always at the root of it Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01grub.cfg: don't scan EFI on btrfs subvolsLeah Rowe
the esp is always a fat32 partition so this makes no sensgrub.cfg: don't scan EFI on btrfs subvols the esp is always a fat32 partition so this makes no sense Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-28grub.cfg: actually support setting boot orderLeah Rowe
replace variables ahcidev/atadev/nvmedev with a single one named bootdev the for loop goes through grub_scan_disk, so now it is effectively a bootorder configuration Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27grub.cfg: add spdx headerLeah Rowe
it has always been gpl 3 or later, but it helps to have the license declaration within the file there's a copying file anyway. put spdx in the config Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27grub.cfg: use grub_scan_disk to set boot orderLeah Rowe
Previously, grub_scan_disk could set ata, ahci or "both", which would make both be tried (ahci first). This worked when we only dealt with ata and ahci devices, but now we support nvme devices so the logic is inherently flawed. Instead, use grub_scan_disk to store the boot order, e.g.: grub_scan_disk="ahci nvme ata" grub_scan_disk="nvme ata" In the first example, it would make GRUB scan ahci first, then nvme and then ata. In the secontd example, it would make GRUB scan nvme first, and then ata. If "both" is set, or anything other than ahci/ata/nvme, grub_scan_disk is now changed to "nvme ahci ata". Actual grub_scan_disk entries in target.cfg files will now be modified, to match each machine. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27GRUB: remove XHCI patches for now (will re-add)Leah Rowe
Fixes this bug: https://codeberg.org/libreboot/lbmk/issues/216 Well, fix is the wrong word. We want xHCI ideally. Mate is working on it as I write this. I've also: * Disabled CONFIG_FINALIZE_USB_ROUTE_XHCI on Haswell boards (coreboot) * Disabled the GRUB payload on HP 820 G2 for now We will need to re-add the xHCI patches once fixed. If Mate/we can't fix it, I'll contact Patrick Rudolph who originally wrote the xHCI patches. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-21Merge pull request 'Also try unlocking encrypted volume on NVMe' (#213) from ↵Leah Rowe
mkukri/lbmk:master into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/213
2024-05-21Also try unlocking encrypted volume on NVMeMate Kukri
2024-05-21Merge pull request 'Add NVMe support to GRUB2 payload' (#212) from ↵Leah Rowe
mkukri/lbmk:master into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/212
2024-05-20Add NVMe support to GRUB2 payloadMate Kukri
Tested on OptiPlex 3050 (via injecting grub2.elf into WIP coreboot port).
2024-05-18Add pt qwerty keymap to lbmksamuraikid
Signed-off-by: samuraikid <samuraikid@noreply.codeberg.org>
2024-05-04Libreboot 20240504 release20240504Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03Merge pull request 'Implemented failsafe options at boot and inside menus ↵Leah Rowe
for enabling/disabling serial, spkmodem and gfxterm' (#203) from livio/lbmk:failsafe into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/203
2024-05-02Merge pull request 'Fixed boot selection menu' (#204) from ↵Leah Rowe
livio/lbmk:livio_290424 into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/204
2024-05-01Fixed boot selection menulivio
2024-04-29Implemented failsafe options at boot and inside menus for enabling/disabling ↵livio
serial, spkmodem and gfxterm
2024-04-28build/roms: simplified seagrub handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-05grub xhci supportLeah Rowe
see: https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/ grub only supports xhci on bios/uefi targets, but not coreboot. some newer machines don't have ps/2 controllers, and boot in a way where ehci isn't available at startup; the controller can't be used by ehci code, there must be xhci support. the code is from Patrick Rudolph working on behalf of 9elements. the code was also sent here for review: https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html however, upstream never merged these patches. libreboot will have to maintain these from now on. the patches have been rebased for use with grub 2.12. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-02-25Libreboot 2024022520240225Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-26Libreboot 2024012620240126Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-21grub/target.cfg: move --disable-werrorLeah Rowe
i meant to push it in configure args, not bootstrap Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-21grub: use --disable-werror on ./configureLeah Rowe
work around build issues on very bleeding edge distros Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-18GRUB: insert only 1 keymap per board, in cbfsLeah Rowe
There is no need to add multiple keymap files, because GRUB can load keymaps from CBFS. The current build logic is designed to avoid building multiple GRUB binaries, which are expensive computationally because each one would then have to be compressed for each board. This patch provides the best of both worlds: less space used in flash like in the old lbmk design (1 keymap per board), but retaining the current build speeds and therefore not re-introducing the slowness of lbmk's previous GRUB build logic. The grub.cfg file has been modified, accordingly. It now only loads a keymap.gkb file from CBFS, by default. It does this, only if that file exists; if not, GRUB already defaults to US Qwerty layout anyway. ALSO: compress all keymap gkb files with xz -6 GRUB automatically decompresses files when accessed. This results in about 2KB of flash space saved in CBFS. Here is real-world data, showing the increased flash space: < fallback/payload 0x3eb80 simple elf 548821 none < keymap.cfg 0xc4bc0 raw 16 none < (empty) 0xc4c00 null 11633316 none --- > fallback/payload 0x3eb80 simple elf 546787 none > keymap.gkb 0xc43c0 raw 344 none > (empty) 0xc4540 null 11635044 none This was taken by diffing the cbfstool "print" output, both before and after. The *after* result is with this change. 11633316. In this example, 1728 bytes have been saved. Therefore, with compression taken into account, this patch saves about 1.7KB of space in CBFS. This change means that lbmk can now scale to support hundreds of keymaps, without increasing the amount of flash space used, in each given image. Since the keymap files are compressed in lbmk.git, in advance, we spend no additional time on compression at build time. The resulting change in build speed in negligible. Adding your own keymap.gkb file was already possible, for changing the keymap in libreboot images, if you didn't want to change the memdisk (and thus re-compile grub.elf). Now, this is the default behaviour, and the only way to do it. It's much more efficient. The original keymap files can be restored, by running unxz. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-30update/trees: support custom make/autogen argumentLeah Rowe
this is now used in grub, for the FS_PAYLOAD_MODULES option in the make command lbmk should generalise as much logic as possible. in some parts of it, logic is hurrently hardcoded, specific to a given project that lbmk uses, but lbmk is essentially a source-based package manager, like what you might find on a small linux distro, so we need to try to be as generic as possible. lbmk is the "build system of build systems", so it has to work generically with as many of them as possible Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-30update/trees: dont hardcode autoconf/bootstrap argLeah Rowe
at present, the bootstrap and configure script is only directly executed for grub, because grub is the only project that uses them in lbmk however, when i start adding linuxboot support, i will have to start building a lot of projects, some of which make use autoconf and bootstrap scripts e.g. ./bootstrap --foo ./configure --bar the "bootstrap" script is often used on GNU programs, because they like to over-engineer absolutely everything Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg syslinux: support scanning /boot/EFI/Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: fix pathLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: handle btrfs subvols for extlinux.confLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: scan extlinux/extlinux.confLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: support grub and extlinux on ata/ahciLeah Rowe
there are special menuentries just for loading configs, without handling luks, lvm and whatnot. it's intended for users of cd/dvd drives. well, now we support both extlinux and grub, with this patch. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: merge isolinux/grub usb menuentriesLeah Rowe
many modern distros use grub in their installer images, so scan for grub.cfg first. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: handle extlinux in the default menuentryLeah Rowe
isolinux/syslinux/extlinux config files should all work, using the syslinux parser function in grub the current behaviour is to only search for grub.cfg, so extlinux users can't use the default libreboot setup. with this change, their systems should hopefully work. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg syslinux: support ESP and extlinux.confLeah Rowe
the so-called EFI System Partition (ESP) is used on many UEFI-based setups. some users may be migrating to libreboot, so let's support it. on BIOS setups, it would be e.g. /boot/syslinux/syslinux.conf on UEFI setups, it would be e.g. /boot/EFI/syslinux/syslinux.conf additionally, support scanning for extlinux.conf Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: don't boot linux without a grub.cfgLeah Rowe
the fallback code in the main menuentry is potentially unsafe, depending on user config. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18grub.cfg: scan lvm volumes lastLeah Rowe
lvm/* is slow to resolve in grub, on some machines, because grub enumeration is very slow in general. however, many people will install distros with any number of lvm configurations, so we should try to support them. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18Revert "grub.cfg: try luks2/crypto-lvm before non-crypto"Leah Rowe
This reverts commit 20389655e42e62ebf6d96dd106c91fbe74282557. If the user actually has encryption, but has /boot unencrypted, this will considerably slow down the boot, so the patch has been reverted. The patch was originally meant to favour encrypted /boot setups, but the old behaviour also still works there.
2023-12-18grub.cfg: try luks2/crypto-lvm before non-cryptoLeah Rowe
when the user sets up an encrypted machine, grub.cfg defaults to non-encrypted setups if found, first this patch reverses the order, deferring to non-encrypted installations only when encrypted ones are unavailable Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-18Update config/grub/config/grub.cfgsemigel
grub.cfg: add BTRFS subvol support
2023-11-13grub: re-add fat/nt file system modulesLeah Rowe
apparently some people use fat file systems for /boot on linux systems this is apparently a thing it's ridiculous, but also a thing a user reported they could not boot their t400 because of those, because they have such a distro installed on their machine apparently it was a gentoo user i don't really care. re-add 1980s dos file system support. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-06add grub mods: diskfilter,hashsum,loadenv,setjmpLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-06re-add grub modules: f2fs, json, read, scsi, sleepLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-06Libreboot 2023110620231106Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: avoid printing empty error messagesLeah Rowe
this replaces the previous behaviour, which erred on a specific value of grub_errno, which was a problem if other types of errors used that value. due to the way i patch out the prefix error messages, this new patch ensures that only those errors are silenced. all other messages will be printed. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05further silence grub prefix errorsLeah Rowe
it still printed "error: ." on screen, instead of the prefix message. now it's silent. it just says: Welcome to GRUB! Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: don't print messages if a module isn't foundLeah Rowe
it can annoy some users, so just silence it. we don't need a lot of modules so we only have a few, but some distro grub configs can load modules frivilously. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: don't print prefix errors on the screenLeah Rowe
still set grub_errno, and behave the same, but don't print anything. just carry on execution as normal. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-01Libreboot 2023110120231101Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-01grub.cfg: use better description in menu entriesLeah Rowe
more user friendly, especially the GRUB (USB) one Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-10-31GRUB: don't spew "Unknown key 0xff" in errorLeah Rowe
Faulty keyboards make GRUB unusable. Normally it happens when a user plugs in a faulty USB keyboard, but if it's the laptop keyboard, then GRUB becomes unusable and the user cannot boot anything. So, your laptop keyboard is a ticking timebomb if you use GRUB; with this patch, that's no longer the case. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-10-31fix grub keyboard init on dell e6400 and e6430Leah Rowe
also, enable seabios_withgrub on e6400, but not grubfirst; right now, we also support dgpu which would brick on grubfirst. on my tested nvidia model, loading grub from seabios worked, so i'm going to re-add seabios_grubfirst functionality like in older libreboot revisions, enabled selectively on a given target. e6430 currently only has igpu support anyway, but i've done the same thing there, in anticipation of future dgpu support. e6400 and e6430 ec report scancode set 2 with translation by default, but only actually output scancode set 1 grub is trying to use scancode set 2 without scancode translation, so the key inputs get messed up fix it by forcing scancode set 2 with translation, but only on coreboot; other build targets on GRUB will retain the same behaviour as before courtesy goes to Nicholas Chin who inspired me, and helped me to fix this. tested on Nicholas's E6400 and E6430, and my E6400; Riku also tested it on non-Dell, as did I (some thinkpads), and all seems OK. The new behaviour in coreboot GRUB is essentially no different to that of SeaBIOS, which does the same. Signed-off-by: Leah Rowe <leah@libreboot.org>