Hi, i am looking for a recipe for building and installing LEDE on a small uefi only atom x5 cherrytrail box (beelink bt4 / z83). The bios is already reflashed to 64 bit and it works fine with ubuntu 16.04 and openbsd, other OSses boot fine from usb sticks.
I want to make this box my primary home office router, but was unlucky with the usual suspects, freebsd router distros have problems with the newer serial ports in cherry trail devices, the openwrt minnowboard solution doesnt boot and efi framebuffering did not work, so i dont know why, since there is no physically accessible serial port on the mainboard.
I also tested this with LEDE with no success, but LEDE worked fine in several virtual enviroments in my home lab, thats why i like it and ask here.
LEDE already works fine under Hyper-V with Gen1 drivers (takes just a quick qemu-img conversion run on a x86-64-combined-ext4.img to .vhdx). State of the art Hyper-V Gen2 driver based systems are faster, but they require UEFI support.
And a lot of "tablet without display" type small pcs or nucs require it too. Its the present state of the bios art in x86 systems. And it should be workable. I just need some hints.
Do you have some?
System
Hostname lede
Model Microsoft Corporation Virtual Machine
Firmware Version LEDE Reboot SNAPSHOT r3114-1a83d4d / LuCI Master (git-17.024.46287-ec99429)
Kernel Version 4.4.42
Lokale Zeit Sat Jan 28 01:19:10 2017
Laufzeit 0h 2m 6s
Durchschnittslast 0.07, 0.02, 0.00
Seems the regular LEDE x86_64 Kernel is EFI enabled enough to be booted from gummiboot.
Installation was a sick hack, i had to install debian 8 with uefi support on a usb stick, installed and configured gummiboot there, extracted partition 2 from x86-64-combined-ext4.img to partition 4 on that stick and copied vmlinuz to the uefi boot partition and after some tries with different kernel option in the loader it bootet on my Beelink z83.
I don't have a hdmi tty yet, but i will see, first i have to clean this hacked mess up and straighten the install process.
root@lede:~# login as: root
Password:
BusyBox v1.25.1 () built-in shell (ash)
_________
/ /\ _ ___ ___ ___
/ LE / \ | | | | | |
/ DE / \ | || || |) | |
/______/ LE \ |||/|| lede-project.org
\ \ DE /
\ LE \ / -----------------------------------------------------------
\ DE \ / Reboot (17.01-SNAPSHOT, r3042-ec095b5)
_/ -----------------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
The same is true for Hyper-V Gen2. One can install LEDE piggyback on a Debian UEFI Hyper-V Gen2 installation using gummiboot as the loader.
It should also be possible to remove Debian completely afterwards, but for me it makes more sense to keep it as a kind of "rescue image" and work environment for upgrades.
\ DE \ / Reboot (17.01.0-rc1, r3042-ec095b5)
________/ -----------------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
I don't think that this is a sick hack. I actually found this to be an excellent idea and I am going to set up my OpenWRT like this as a default on x86 platforms. In the meantime (2y later) it seems that there there will be a combined UEFI 64bit OpenWRT image released quite soon that should work out of the box in Gen2 virtual machines (after conversion to a hper-v virtual disk). But I will stick to your "hack".
I just wanted to add to your explanations the basic steps that I took to sucessfully install 64bit OpenWRT 18.x in a Gen2 hyper-v machine:
Downloaded 64bit Debian 9 minimal ISO
Downloaded 64bit OpenWRT rootfs-ext4.img.gz and vmlinuz (compressed kernel) and moved the 2 files into an ISO-file (I used folder2iso on Windows) for mounting into the virtual machine later on
Create new Gen2 virtual machine (I assigned 512MB RAM, a 4GB disk and two network interfaces) and I did not check secure boot in the firmware
Mounted Debian ISO and booted from it, I used a minimal install without graphical interface as there was no need for me to do a full Debian install. I chose manual GPT partitioning and created an 256MB EFI boot partition (sda1), a 1 GB part for OpenWRT (sda2, unmounted as the UUID will change later), a 512 MB swap partition on sda3 and a 2GB+ Debian partition on sda4 taking up the remaining space. This way it is possible to expand the disk and enlarge the Debian partition later if needed. Finished Debian installation.
Mounted the 2nd ISO to the VM, booted Debian and copied the OpenWRT kernel to /boot (EFI partition)
Unzipped and wrote rootfs-ext4.img.gz to sda2 with dd, resized OpenWRT partition with resize2fs -p /dev/sda2 to its full size (1GB). Beware that this changes the UUID, that is also why I did not mount sda2 during install. I saw no need to use UUIDs to mount the partition in Debian. I just added /dev/sda2 in fstab to mount to a new folder named /openwrt. This mount will still work if you upgrade (dd) to a new image version.
Told the bootmanager (GRUB2 by default in Debian 9) to boot the OpenWRT kernel
The past part seemed a bit complicated at first glance, but it is actually very simple if you know how to do it. Gummiboot or its sucessor are not needed (can be used optionally to replace GRUB). All you have to do for GRUB is to copy the following text to /etc/grub.d/40_custom and run update-grub
Of course you have to match the name of the kernel file to your version. I also changed the default to OpenWRT in /etc/default/grub (the 3rd menuentry is grub_default=2). Remark: You can also change the OpenWRT initial default LAN IP through /openwrt/lib/preinit/00_preinit.conf from Debian (only before you boot for the first time!). After a reboot of the Debian system OpenWRT should start.
The nice thing about having a rescue system is that it is now super easy to update, customize, backup or un-brick the image in case of troubles by booting into the Debian system. And all this takes up just 4GB. As I said before - not a sick hack at all.