Thanks for speaking up. As a heavy x86 user, I agree this article is due for some attention. Do you plan on updating the wiki yourself or would you like me or someone else to do it on your behalf once you’ve finished “workshopping” the copy?
3 Likes
One thing I am thinking about when reading the wiki sub part about uefi and secure boot is that the part with secure boot seems very old. And the contents in the Github branch the link is connected to is not updated for 8years!?
Are those secure boot packages even alive anymore and does they even work with todays kernels. If we want secure boot I think it should be included in the official packages in some way?
1 Like
secure boot support is very unlikely.
- it needs very expensive certificates from Microsoft
- the first stage bootloader (usually shim) would need to be signed by Microsoft for each build, this takes weeks+ for each iteration
- OpenWrt would need to deploy its own CA for trusted grub, kernel, qemu, kexec, etc. OpenWrt-signed binaries and integrate that into the buildbot infrastructure
Building OpenWrt from source, sorry, no longer possible.
Changing kernel options, sorry, no longer possible.
PRs for kernel updates, sorry, no longer possible.
Read 'no longer possible' as 'very hard', developers would have to create their own keys, enroll them into UEFI, build everything using them, etc. pp. - technically possible, but you'd reduce the number of contributors pretty much to zero.
3 Likes
@joshenders
It'd be great if you or someone with a wiki account can update it. And in my case, I am mostly done with the information that I know of. If there is going to be more editing, it will be from the suggestions of other community members. 
1 Like
I guess the practical solution regarding secure boot is to disable it in the motherboard boot setting. In my simplified understanding, it is there to ensure only credible stuff can boot the device; and in its absence, we take the responsibility of decide if an image is trustworthy (by verifying checksums, etc).
2 Likes
In some kind of theory the idea seems to be that the cert key for the “my” build are in the bios key bank and are verified with the encrypted software at boot to see that no malware has included it self between bios start and boot time.
That is possible, but would need quite considerable changes to the build process of grub (maybe introducing shim, but not strictly necessary if you enroll your own MOK keys), kernel, a couple of other packages (procd?) and change the image recipe - possible, but not exactly fun.
That is the thing with the instruction on the wiki for secure boot. That link to a github repository that was made 8years ago and hasn’t been touched since then. That means the packages that are downloaded are also 8years old.
So I doubt anything of that work with current OpenWrt.
Last time I used sysupgrade on EFI and virtualized x86-64 couldnt boot system and lost data/history from additional packages..
Is it now possible to do that using the regular sysupgrade and not lose data?
You mean configurations, or stuff like rrd logs? If the former, then LuCI ASU and CLI auc work fine for keeping your installed packages and their configs. (This, of course, assumes no major changes between old and new installs.)
The latter is more problematic and package-specific (see thread on maintaining the aforementioned rrd database as an example: Saving dynamically-generated files during sysupgrade).
1 Like
I'll review this thread in more detail, test upgrading a few of my routers, and then update the wiki. Thank you for your contribution!
1 Like
Oh my golly gosh. I read that wiki article a while ago, saw it was quite involved, was planning to set some time to fully comprehend it (quite comfortable with resizing partitions on a normal linux machine, but I also fully understand the boot process of a normal linux machine, hardware or VM).
Added complication was that all other hardware types have a dedicated sysupgrade image. Doesn't help that the sysupgrade page linked to can't filter for x86, but there is no dedicated sysupgrade image in the x86 download tree. The hint above to just download the same image type you started with was the hint I needed. Now which image did I install with? Fortunately, my original wget command was still in my commandline history because my history is infinite these days. df -T can probably give a hint as to what you originally installed too.
All seems to be working... Just reinstated the same environment via my ansible playbook, and all seems to be good. If it's not, I just revert my VM snapshot 
That's another thing auc and LuCI Attended Sysupgrade do for you: they reconstruct what is needed on the fly, so you don't have to remember...
...and it's probably worth mentioning the nice pre-checking script that a certain forum user efahl shared a couple of weeks ago that may be very useful on actual x86 hardware.
It will provide some reassurance if you need to be more careful about upgrade downtime on real-life hardware than on a VM (where you can simply roll back to a VM snapshot if something goes wrong and not get shouted at for too long)
pkg-scan.sh upgrade pre-check script post by .efahl.
a VERY very useful script I've used about 30 times in the last 2 weeks - many thanks
1 Like
Just pushed a new version that adds the sysupgrade type to the header output. And to be clear, it should work on any openwrt device, not just the x86 boxes: I test it on x86 (snapshot-efi-squashf, snapshot-efi-ext4, 23.05-bios-squashfs), mt7622 23.05-ubi and ath79 23.05.
$ ./pkg-scan.sh --check
...
Package-arch x86_64
Root-FS-type squashfs
Version-from SNAPSHOT r24414-255d5c9bf8
Version-to SNAPSHOT r24586-f3cdc9f988
Image-prefix openwrt-x86-64-generic combined-efi
2024-01-09 - Added more info into the header output, specifically the respective kernel versions.
$ ./pkg-scan.sh -c -V 23.05-snapshot
Board-name tplink_archer-c7-v4
Target ath79/generic
Package-arch mips_24kc
Version-from 23.05.2 r23630-842932a63d (kernel 5.15.137)
Version-to 23.05-SNAPSHOT r23699-67d998e25d (kernel 5.15.145)
Image-prefix openwrt-23.05-snapshot-r23699-67d998e25d-ath79-generic-tplink_archer-c7-v4
Root-FS-type squashfs
Sys-type sysupgrade
Image-file openwrt-23.05-snapshot-r23699-67d998e25d-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin
Build-at 2024-01-07T12:57:30.000000Z
...
Does the regular LUCI-based upgrade process work on EFI machines? I've got a x64 box that was install on the ext4 EFI image.
Looking to go from 22.03.5 to 23.05.2
Yes.
1 Like
Thanks, I saw a comment earlier in the thread about issues with EFI upgrades.
THIS.
I switched to squashfs, and this script is just all i needed.
Maybe we can get this script mentioned in the main docs page for x86 openwrt and pointing that install using squashfs will result in similar experience in upgrade and factory reset just like non-x86 devices.
As some may have stated, the only real issues come into play when a UEFI image is involved. My system is BIOS driven so I stick with ext4-combined.img.gz(sans EFI in the image name). This seems to be a great way to determine if BIOS is in play or not:
# ls: /sys/firmware/efi:
# IF "No such file or directory", then we're currently using BIOS. If so, process to script.
ls /sys/firmware/efi
I use parted to easily expland from the defaults and everything plays nice.
#!/bin/sh
# Create this in /tmp as resize.sh, chmod a+x resize.sh, then sh +x /tmp/resize.sh
# Use parted to fix the partition table, identify and expand the root partition.
# Install packages
opkg update
opkg install parted
# Identify disk name and partition number variable
storage=$(parted -l | awk '/^Disk \/dev\// {print $2}' | sed 's/://')
# Expand root partition and check the exit status
parted -f -s "$storage" resizepart 2 100%
if [ $? -eq 1 ]; then
echo "Error resizing the partition. Exiting without reboot."
exit 1
fi
# Apply changes
wait 20
# Reboot
reboot