HTTP Internet booting stock OpenWrt image

Installing and Using OpenWrt
1

Hello OpenWRT community,

First of all, I wanted to say how grateful I am for the good work you are doing.

I have a device with a microSD card slot that runs just fine using a standard stable OpenWRT image, as provided on the OpenWRT website.

Rather than flashing the OpenWRT image to my SD card, I would like to have a minimal "loader" Linux image on the SD card which reads a text file from the SD card that contains a URL, and then downloads and boots the image from that URL. The goal is for the "loader" to boot the OpenWRT image and behave exactly as that image would have done were the "loader" not present.

The "loader" image will contain static network configuration and will need to download the OpenWRT image over the internet. In other words, traditional BOOTP/TFTP network booting is not an option - it will have to boot over the internet, most likely with HTTP, but I am open to other solutions that work over the internet.

It is complicated and risky to either build my own OpenWRT images or modify the standard OpenWRT images, so I would like this setup to be able to boot stock stable OpenWRT images from the OpenWRT website. The device will be in a remote location and I would like to be able to reboot it and have it load new images while minimising the risk of rendering the device inoperable, which custom images would increase. U-Boot supports some form of network booting, but from what I have read, it does not reliably support HTTP booting, so I expect I will need U-Boot to load a minimal Linux image that will then download the OpenWRT image over HTTP and boot from it. If possible, I would like to store an OpenWRT image on the SD card and in the event of being unable to download an image over HTTP, the device should boot from the image stored on the SD card. Note, this backup image will be an image file on the file system, rather than an expanded image that would typically be written to an SD card.

My device has more than enough RAM to download the OpenWRT image to RAM, keep it there and then run reliably using the remaining free RAM. I would prefer a solution that operates entirely in RAM once the "loader" has finished downloading the OpenWRT.

Since I would like to boot a stock OpenWRT image, essentially the work will be in building the "loader" image.

Has anyone done something like this before, or does anyone have any ideas how I may go about it?

Would it be easier for me to start working on the "loader" image by taking a stock OpenWRT image and trying to strip it down?

What exactly will I need to do in order to prepare the loader to boot a stock OpenWRT image?

Thank you in advance for any input.

1 Like
2

While 'anything' is possible, if you develop/ implement it, this endeavour doesn't really make sense on so many accounts.

  • http/ https is a rather complex protocol, you'd need a full linux (live-) environment just to start the download (in which case, just use that (e.g. the OpenWrt image) to handle your routing)
  • you end up with the chicken or egg dilemma, in order to download your image, you need full internet access (PPPoE and friends), on rather unknown (to the image) hardware
  • things like persistency and hardware detection (a router tends to have 2+ ethernet interfaces, so one needs to be designated WAN, one LAN - no, you can't guess this enumeration order for random hardware in advance) will become 'fun' rather soon
  • what does 'generic loader' even mean in the first place (even for x86, we have BIOS vs UEFI, 32 bit vs 64 bit, other platforms (ARM/ mips) are even more complex)

I think you're overcomplicating a rather simple (for a human being) thing, in an attempt to make it easier, while actually making it harder both for the developer (you) and the potential user (who will be quite in the dark when suddenly faced with setting this up in the first place).

Think about it, if internet access were as easy as plugging an ethernet patch cable into the wall and waiting for the DHCP lease to cover the rest, you wouldn't even (technically-) need a 'router distribution' to begin with - and if it's that simple, the default -pre-downloaded- OpenWrt image would do just as well, at least up to the point of upgrading itself. In reality this does often involve more configuration than that.

3 Likes
3

This can't really happen with OpenWrt, AFAIK. You have to bring up the kernel and enough of the subsystems to have a fully functioning networking stack to even get to a place where you could potentially download something from the internet. Then you'd have to replace the running system with whatever was downloaded, which is not really practical in this context.

As I said before, I don't think this is possible based on how OpenWrt operates (and I'm sure someone will let us know if I'm mistaken), but even if it was possible, HTTP would be a very bad idea since it is not a secure transport protocol. You could end up with a security nightmare.

Not necessarily. There is the online image builder and the attended sysupgrade system that can make this super easy. And using the image builder is not that difficult or complicated.

It is highly recommended that you have another identical device so that you can test any images you plan to use (including the standard stable images... just in case) when you have a system that will be difficult to access, but aside from that, setting up custom images is really not that hard.

What you're kind of talking about is the initramfs type operating model. This is really good for testing and running experimental builds because nothing ever gets flashed to memory (so simply reboot and it goes poof). The problem is that this is generally loaded with a tftp server and often requires a serial console connection to do this. It isn't a standard boot process.

EDIT: @slh beat me to the punch. We were writing simultaneously :slight_smile:

2 Likes
4

I figure it might be worth the following question:

Why do you want to do this? What advantage does it provide and/or what problem does it solve? (aside from the idea of "always being up to date")

2 Likes
5

…and what kind of hardware are we talking about in the first place?

  • x86_64, maaaybe - with a lot of question marks and guaranteed failures to happen, when encountering slightly different hardware (the mere presence of a USB stick being plugged in -or not- can change enumeration order).
  • A single known device platform distributed by yourself, sure - but why complicating a simple matter of providing a preconfigured image (or even physical rescue medium) with a dynamically downloaded image that's just bound to break.
  • a range of loosely 'supported' embedded devices, forget it, there is nothing generic enough in embedded hardware to even boot from a 'generic' loader image.
2 Likes
6

Thank you all for your input. I would like to clarify a few things.

I am looking to set this up for a single hardware device used at a single location. The location has simple internet access by setting a static IP and default gateway (or even retrieving these with DHCP). There is no need for PPPoE or anything else.

Only one Ethernet interface will be connected, and the specific interface will be known in advance, so no need to distinguish between different interfaces.

The "loader" should be customised for this single device in this single scenario. The device itself is an ARM SBC that is already fully supported by OpenWRT. It is not intended to work on any other device or in another environment.

Even though I do not require routing, I have selected OpenWRT because it is a lightweight, efficient, network-enabled system that supports my hardware and contains a package manager with the required packages. I have ruled out Debian/Armbian because the base install is too large and they are designed to regularly write to permanent storage. I am using an SD card which has limited write cycles and this will be a challenge to replace due to the remote location.

If there is a way for me to build a (non-OpenWRT) Linux image that can download and boot an OpenWRT image, I am open to that. Any advice would be appreciated.

I want to do this so I can have an easily updatable OpenWRT device that will not be brought down by a broken SD card (from corruption, excessive writes, high temperatures etc.)

I am happy to build/modify an OpenWRT (or other Linux) image to end up with a loader. I appreciate that the loader will probably already be able to perform routing etc. but I want it to download an OpenWRT image and be able to run that. I am not concerned about corruption of the OpenWRT image being downloaded. Once I get this working, I hope to have it able to download the image over HTTPS and preload a key to the "loader", so it can verify the digital signature of the OpenWRT being booted.

1 Like
7

I'm still not quite understanding the motivation of an internet boot situation. OpenWrt doesn't write to your permanent storage except when you make changes, so it would seem that it does already fit that constraint. But why do you want it to internet boot? What does that accomplish that a locally stored install of OpenWrt does not?

8

It comes down to the general suckiness of SD cards. They are sensitive to temperature swings, have limited write cycles, and even when they are infrequently written to, can fail due to other reasons. I speak from experience.

Internet booting is a way to trade off upfront complexity for improved reliability. I accept that in most cases, it is not a worthwhile tradeoff, but I am willing to accept this tradeoff to mitigate the risk of failing SD cards.

So I can begin, what is required to boot an OpenWRT image from a running system? I assume the OpenWRT images contain U-Boot and various partitions. If I strip these apart, can I boot an initrd kernel from a shell in an already running Linux image?

9

Hi, you may be able to do what you want using u-boot and the initramfs images, preconfigured how you need it to be.

Config uboot to hit a particular server and download the image, then boot it.

Exposing uboot directly to the open internet though is not likely to be recommended!

If the real issue is media reliability, boot your device off something tougher, like an ssd or spinning hard disk connected via usb. Or use an sdcard made for booting like the esxi cards.

10

What happens if during reboot - the downloads site is down (the site has been down enough that it made me think of this question)?

What happens when the SD card containing that "bootloader" fails?

2 Likes
11

I mentioned in a previous post that if possible, I would like to store an OpenWRT image on the SD card that will be used as a fallback if the web server is unreachable.

12

:confused:

:baby_chick: :egg:

This is an interesting concept...intriguing.

13

Thanks for the suggestion. Do you know how I may be able to get started with configuring U-Boot on a fresh image? Do I have to start with an OpenWRT release image and then just extract U-Boot from it?

14

https://www.denx.de/wiki/DULG/Manual

  • U-Boot is usually on the hardware, not in OpenWrt images
  • :spiral_notepad: Usually U-Boot doesn't need editing - and I thought you noted that you didn't wanna expose the bootloader to the Internet
15

Maybe you're buying low quality SD cards. Yes, SD cards can go corrupt and such, but they are remarkably reliable... far more so than you'd think.

Besides, where does your magical loader live? If it lives on an SD card, you haven't improved anything... that SD card that you're worried could fail will still be the limiting factor because a failure of the SD card means that the loader can't run, and therefore can't download your OpenWrt image from the internet.

OpenWrt, for what it's worth, is designed to be used on devices that have significant constraints on the longevity of the storage media -- embedded flash memory is often much less robust and can withstand fewer write cycles than what is common inside SD cards.

2 Likes
16

There are additional issues to consider:

  • https really, really, really wants a correct system clock, which is very hard to accomplish without a battery backed- rtc.
  • image- and path names on the download servers change over time (just think about ar71xx --> ath79)
  • talking about changes, changes akin to swconfig --> dsa or fw3 --> fw4 will happen (again) in OpenWrt
  • even determining the newest image can be 'fun' (no, there is no latest symlink), html parsing at its best
  • there can always be broken builds online
  • image signature keys are regularly replaced
  • automated image downloads can be seen as DoS attack against the download servers and may be blocked (do talk to the server maintainers first and get their buy-in, cache locally).
2 Likes
17

Can anyone give me any pointers on how to boot an OpenWRT initrd kernel from an existing running system? If I can do this, most of the other challenges are manageable.

If it makes the process easier, I can accept having to modify an existing OpenWRT image, e.g. by splitting the partitions and booting from one of them.

18

It looks like U-Boot only supports tftpboot and not HTTP booting. Too bad as a U-Boot solution would have been much simpler than having to load a kernel and then booting from there.

19

kexec (might not be available for your target, might require serious low-level kernel development to get working).

1 Like
20

That's kinda been explained why it wouldn't have high-level HTTP.

...ummm if you load a Kernel...you've loaded an Operating System. Which means you can load the OpenWrt Kernel.

:face_with_spiral_eyes:

Yea...lol...

Sure...the Cisco Meraki MX60(W) requires u-boot manipulation to configure boot, flash and installation of the initial OpenWrt image: https://openwrt.org/toh/meraki/mx60#flashing

Obviously, this would only be an example, you would have to use proper images, memory addresses, etc. for your specific device.