Fedora 36 Workstation, with the command you said.
@Crystalyne Did you make this change?
DisableCapsuleUpdateOnDisk=true
in /etc/fwupd/uefi_capsule.conf
Yeah, that’s been set.
@Crystalyne If you are using stock fedora (gnome) you can try gnome-firmware.
Use it to verify the download and/or redownload. If it is verified you can try to upgrade through gnome-firmware.
Hey folks, any idea on how to install the BIOS update if you don’t have a battery (e.g. Frameworks Creators program members)?
This actually was the first thing I tried before giving up and going to Terminal. Unfortunately, same results.
Yup. Seems to be exactly the issue I’m having too.
@Crystalyne and @Jason_Hottelet - I apologize if I missed it, but how large is your EFI partition, and how much free space do you have in yet?
Mine’s 100MB, with ~50MB free. I did have to do some cleaning out of the EFI partition as LVFS stupidly doesn’t clean up after itself if an update fails.
Just followed the LVFS guide above on Linux (Fedora) and it worked great!
629 MB — 577 MB free
Weirdly enough, the available BIOS update just showed up in GNOME software right after I used it to do the latest system updates (kernel, pipewire etc.). After hitting “install” from there instead of in the terminal as before, it worked and I am now on 3.10
No issues here, except fwupdmgr still sees my current BIOS version wrong and I had to pass --allow-older
to get it to do the update: after having updated to 3.10 fwupdmgr get-devices
now reports my current version as 784 (which is the decimal equivalent of 0x310, following the pattern I’ve been seeing).
This is just a vague annoyance but I am curious as to why it’s happening.
Solved it myself, find the guide for updating BIOS without a battery here:
Also, updated with this method from 3.07 to 3.10 (from Windows, because I have no knowlegde of the CLI switches needed to make it work via UEFI boot), no issues there. Was my first update and I panicked for a moment when the machine just shut off after the update. But turning it on revealed everything was working perfectly.
The “100% battery” requirement seems to be essential.
I had my battery set to cap charging at 80%, and the LVFS update did nothing. I changed the charge limit in my BIOS to 100% and fully charged the battery, and then the fwupdmgr update
followed by a reboot installed the new BIOS correctly.
(By “correctly” I mean it installed 3.10; it still wiped out the BIOS settings so that I needed to reset all my BIOS customizations, boot with the “F3” boot menu, and re-install GRUB. But those are known problems with the BIOS update.)
Updated from 3.09 to 3.10 using
sudo fwupdmgr refresh
sudo fwupdmgr update
Opened the BIOS to reset my power button brightness and max battery level. Then rebooted and used F3 to browse to the image for y mcurrent Manjaro and re-install the boot manager. From the Manjaro Wiki:
sudo su -
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg
exit
Rebooted and all’s well. Posting this here so I remember how to do it next time.
10mb remaining out of 100, so I suspect you’re on to something.
Is there a noob-friendly guide for resizing my EFI parition? There must be a way to do it that doesn’t require command-line fluency, rsync, etc.
gparted will probably do it but the space has to come from somewhere, which means moving the beginning of the next partition. That will take a long time.
I’ll shorten the original question to avoid confusion about what I’m looking for:
If you’re using systemd-boot
, you could feasibly create an “Extended Boot Loader Partition”, which could be used to store things like the kernel without putting them on the undersized EFI partition.
https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points
https://wiki.archlinux.org/title/Systemd-boot#Installation_using_XBOOTLDR
But, the other option is to try and resize the partitions after to then shift them down and then resize the EFI partition; most things I’ve read imply that they give up and just reinstall remembering to increase the size (or, if this is Windows’ fault, trick its installer into using a larger partition than 100MB, its default).