OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Medium
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Alexander Couzens - 16.08.2017
Last edited by Adrian Schmutzler - 06.11.2019

FS#966 - ar71xx: images are not named to their board_names

Create an image using the imagebuilder (e.g. ar71xx/generic)

- make PROFILE=ubnt-loco-m-xw image
- the resulting image is than named lede-ar71xx-generic-ubnt-loco-m-xw-squashfs-factory.bin
- but looking into /tmp/sysinfo/board_name it’s called “loco-m-xw”

original reporter: aparcar
Additional reference:

Closed by  Adrian Schmutzler
06.11.2019 17:29
Reason for closing:  Implemented
Project Manager
Matthias Schiffer commented on 17.08.2017 00:48

Naming images after board_name is not feasible on ar71xx, as it is very common to use the same board name for different models that are the the same internally (but magic numbers in the image header differ).

I agree though that the image naming could be improved. In Gluon, we use a sanitized version of /tmp/sysinfo/model for the autoupdater image selection on most targets (for an example, have a look at the TP-Link and Ubiquiti sections in - the first argument of the "device" directive defines the Gluon/autoupdater image name, while the second argument is the name used by LEDE)

Project Manager
Alexander Couzens commented on 17.08.2017 02:39

So we have:
- image profile (the filename is based of)
- machine name (the kernel depends on this)
- board_name (user space depends of)
Did I missed a type?

IMHO if the image needs to be different (because of some magics), it should have it's own board_name.

Project Manager
Matthias Schiffer commented on 18.08.2017 16:10

Using a separate board_name for models that are basically the same hardware sounds like unnecessary code duplication in /lib/, /lib/upgrade/, /etc/board.d/* etc. to me.

How about adding a new file /tmp/sysinfo/image_name? This would default to board_name in generic code, while ar71xx and other targets could override it where necessary.

Another target that uses board_name quite unusually is x86: here board_name is set to a sanitized version of the product name (as read from DMI data); this board_name is then used to identify platforms like the APU and set up LEDs etc. accordingly. So this would be another platform where deriving the image name from board_name is not possible.

Note: Another reason we base our image names on /tmp/sysinfo/model instead of board_name even on platforms that have a unique board_name → image name mapping is that the model names are easier to understand for end users, as they usually include the vendor and the full unabbreviated name of the device.

aparcar commented on 04.10.2017 22:12

Hi, any news on how to handle the naming?
I build a parser for hardware overview and there seems to be no mapping between e.g. the specific hardware info and the used profile tl-wdr3600-v1, except maybe parsing the URL with replacing '_' with '-'.
Is there a more convenient way to map the device name (as printed on device) to the profile to create the image?

Project Manager
Adrian Schmutzler commented on 06.11.2019 17:29

I think this discussion is obsoleted by retirement of ar71xx. Despite, I tried to achieve a similar goal when harmonizing names in ramips.


Available keyboard shortcuts


Task Details

Task Editing