How to install 18.06.0 to a UEFI-only x86-64 system?

Here I saw a document:
https://openwrt.org/docs/guide-developer/uefi-bootable-image
But it doesn't work: these commits does not exist on https://git.openwrt.org/openwrt/staging/jow.git

I'm wondering if some one could tell me how to make a UEFI bootable image using release images without rebuild entire OpenWrt. Is that possible?

2 Likes

But it doesn't work: these commits does not exist on https://git.openwrt.org/openwrt/staging/jow.git

@NemoAlex I am able to find the commits listed on the wiki page.

I'm wondering if some one could tell me how to make a UEFI bootable image using release images without rebuild entire OpenWrt. Is that possible?

I am also going through the wiki to get OpwnWrt for my MinnowBoard Max and have used the kernel and rootfs from https://downloads.openwrt.org/releases/18.06.1/targets/x86/64/ to successfully boot from an microSD card USB adapter. However, the rootfs doesn't have the packages I need to get networking up and running over a USB wifi dongle. I think the imagebuilder tool can do this. The build process is taking a long time to make download so I would like to try a different method of getting a customized UEFI bootable image of OpenWrt.

@NemoAlex / @lucasrangit , were you able to boot on efi only ?

You might see if http://www.rodsbooks.com/refind/ is helpful as an intermediate-stage boot manager

I too would like to see an EFI image created for us to use.I have a perfectly suitable ASRock J5005 embedded motherboard that I can't use with OpenWRT because it does not have a CSM module in the bios to enable for non-uefi environment.

OpenWrt on UEFI based x86 systems

https://openwrt.org/docs/guide-developer/uefi-bootable-image

If you look at that wiki page, or, as noted in the thread above, you’ll see that there is no such branch.

The two commits rotting there are ancient and there has been no acceptance of them or any other UEFI-boot work that I can find. They date back to 2017, with a fix back in early 2018.

b4a9418606 x86: fix bios mkimage during efi image generation
252559414f x86: Generate EFI grub images

The latest work I'm aware of is https://github.com/openwrt/openwrt/pull/1968 (which is also not getting much upstream attention)

I use Ubuntu and used the following steps to make an UEFI pendrive with OpenWRT (USB was /dev/sdd):

  1. Download the x86 image

  2. Extract the image

    gunzip openwrt-18.06.6-x86-64-combined-ext4.img.gz

  3. Write the image to the USB drive

    dd if=openwrt-18.06.6-x86-64-combined-ext4.img of=/dev/sdd

  4. Resize the second partition but leave 512M at the end of the disk using gparted. This extra space will be used to add EFI system partition in the next step.

  5. Use gdisk to add an EFI partition and covert to GPT. Please note the "EF00" code used to create the new partition.

	gdisk /dev/sdd

	Found valid MBR and corrupt GPT. Which do you want to use? (Using the
	GPT MAY permit recovery of GPT data.)
	 1 - MBR
	 2 - GPT
	 3 - Create blank GPT

	Your answer: 1

	Command (? for help): n
	Partition number (3-128, default 3): 3
	First sector (34-15126494, default = 14077952) or {+-}size{KMGTP}: 
	Last sector (14077952-15126494, default = 15126494) or {+-}size{KMGTP}: 
	Current type is 'Linux filesystem'
	Hex code or GUID (L to show codes, Enter = 8300): EF00
	Changed type of partition to 'EFI System'

	Command (? for help): w

	Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
	PARTITIONS!!

	Do you want to proceed? (Y/N): Y
	OK; writing new GUID partition table (GPT) to /dev/sdd.
	The operation has completed successfully.
  1. Verify the GPT table and the partitions and format the 3rd partition to FAT32 using gparted.

  2. As the UUID of the OpenWRT image partitions are duplicated and EFI GRUB cannot use PARTUUD to find the root FS you have to add label to the first partition of the disk using gparted (umount the partition if the option is grayed out). I used the label "boot". You can use different label but in step 9 use the same label instead of the "boot" word in the first line.

  3. Copy the /boot/efi content of your Ubuntu system to the EFI partition (3rd partition of your disk). If you do it right then you will have an "EFI" directory in the 3rd partition of your disk.

  4. Update the EFI/ubuntu/grub.cfg in the third EFI partition of your disk to use label instead of UUID (use the same label as specified in step 7):

	search.fs_label boot root
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
  1. Fix the grub config in the first partition of the disk (boot) to use the first GPT partition (gpt1) for the kernel and use the GPT PARTUUID (not the old MBR one) of the second (root) partition of the disk (use the command blkid to reveal this information and use your specific PARTUUID):
	serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
	terminal_input console serial; terminal_output console serial

	set default="0"
	set timeout="5"
	set root='(hd0,gpt1)'

	menuentry "OpenWrt" {
		linux /boot/vmlinuz root=PARTUUID=91ed1df5-473e-43ab-b8cd-593e7be7e3ef rootfstype=ext4 rootwait console=tty0 console=ttyS0,115200n8 noinitrd
	}
	menuentry "OpenWrt (failsafe)" {
		linux /boot/vmlinuz failsafe=true root=PARTUUID=91ed1df5-473e-43ab-b8cd-593e7be7e3ef rootfstype=ext4 rootwait console=tty0 console=ttyS0,115200n8 noinitrd
	}
3 Likes

Thank you thank you thank you so much. This works. I was sad because I bought Atmoic Pi and it only supports UEFI. But after following your guide, I was able to install Openwrt 19.xx and it works like charm. Again thank you so much for sharing this information.

Just wondering if I perform firmware update in future, Do I need to perform the same steps or it will be just a simple update?

Worth testing... but i'm guessing you'd have to redo...

( saving a dd of your boot and EFI partions will save time as you can just write those after the resize step aka ... avoid grub edits )

it's alot easier to perform these steps with the .img mounted on a Linux host as loop() prior to dd... albeit a little risky for beginners...

if it's a removable drive you can just copy the vmlinux and rootfs ( after usb rootfspart is mounted and deleted ) across and avoid sysupgrade ( very quick )... that's what i'd do with this method... ( but you'd have to export/import the config separately )

There is also the UEFI PR which would be easier for internal disk... ( also, i've got
a related/unfinished sketchy script that automates much of the stuff similar to whats in this thread... could be useful for hints of you go the loop route )

I develop a script to solve this problem

1 Like