Hi,
auf der Website befindet sich eine Seite zur Installation einiger UniFi- Geraete [1]. Dort wird unter anderem geschrieben, dass "UniFi AP AC LR und UniFi AP AC Pro" eine Installation des sysupgrade Images auf der mtd-Partition "kernel1" und bei "UniFi AP AC Lite" auf "kernel0" kopiert werden sollen.
Ich habe mal auf zwei Geraeten in unserem Freifunknetz nachgeschaut.
* PL-Raedel18-Parkhotel-EG-1 https://vogtland.freifunk.net/map/#!v:m;n:802aa8c5dc8f
- Ubiquiti UniFi-AC-PRO - 2a03:2260:200f:100:822a:a8ff:fec5:dc8f - mtd-Partitionen::
Creating 7 MTD partitions on "spi0.0": 0x000000000000-0x000000060000 : "u-boot" 0x000000060000-0x000000070000 : "u-boot-env" 0x000000070000-0x000000800000 : "firmware" 2 uimage-fw partitions found on MTD device firmware 0x000000070000-0x0000001c0000 : "kernel" 0x0000001c0000-0x000000800000 : "rootfs" mtd: device 4 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x000000450000-0x000000800000 : "rootfs_data" 0x000000800000-0x000000f90000 : "ubnt-airos" 0x000000f90000-0x000000fb0000 : "bs" 0x000000fb0000-0x000000ff0000 : "cfg" 0x000000ff0000-0x000001000000 : "EEPROM"
- bootselect::
root@PL-Raedel18-Parkhotel-EG-1:~# dd if=/dev/mtdblock7 bs=1 count=1|hexdump -Cv 00000000 00
* PL-Raedel18-Parkhotel-E1-1 https://vogtland.freifunk.net/map/#!v:m;n:802aa8c2a092
- Ubiquiti UniFi-AC-LITE - 2a03:2260:200f:100:822a:a8ff:fec2:a092 - mtd-Partitionen::
Creating 7 MTD partitions on "spi0.0": 0x000000000000-0x000000060000 : "u-boot" 0x000000060000-0x000000070000 : "u-boot-env" 0x000000070000-0x000000800000 : "firmware" 2 uimage-fw partitions found on MTD device firmware 0x000000070000-0x0000001c0000 : "kernel" 0x0000001c0000-0x000000800000 : "rootfs" mtd: device 4 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x000000440000-0x000000800000 : "rootfs_data" 0x000000800000-0x000000f90000 : "ubnt-airos" 0x000000f90000-0x000000fb0000 : "bs" 0x000000fb0000-0x000000ff0000 : "cfg" 0x000000ff0000-0x000001000000 : "EEPROM"
- bootselect::
root@PL-Raedel18-Parkhotel-E1-1:~# dd if=/dev/mtdblock7 bs=1 count=1|hexdump -Cv 00000000 00
Man kann im OpenWrt-Wiki [2] die originalen mtd-Partitionen vom UniFi airOS nachschauen. Dort sieht man, dass "firmware" == "kernel0" und "ubnt-airos" == "kernel1" ist.
Also was ich hier sehe ist, dass
1. OpenWrt erwartet, dass es von "kernel0" gebootet wird (Name "firmware" unter OpenWrt) 2. OpenWrt hardcoded [3] die Position von "firmware" bei beiden Geraeten gleich 3. "kernel1" (Name "ubnt-airos" unter OpenWrt) wird nicht von OpenWrt genutzt 4. OpenWrt wird einfach "firmware" ersetzen bei einem Upgrade [4,5]
Speziell Punkt 4 deutet darauf hin, dass bei einer Installation auf kernel1 entweder:
* bootselect steht auf 0: das alte System von kernel0 gebootet wird * bootselect steht auf 1: ein Upgrade unter OpenWrt dazu fuehren wuerde, dass nur das Rootfs geupgraded wird, aber nicht der Kernel. Das liegt daran, dass OpenWrt immer auf "firmware"/kernel0 beim Upgrade schreibt. Der Bootloader laedt aber entweder den Linux-Kernel von kernel0/firmware oder kernel1. Da bootselect auf 1 (kernel1) steht, wird also der alte Kernel geladen. Aber Linux selber entscheidet anhand der "hardgecodeten" mtd-Partitionen woher er das rootfs-Laden soll - also nutzt er das neue rootfs von firmware/kernel0. Bei einem Upgrade versuch koennte dies dazu fuehren, dass das System nicht mehr laedt, da zum Beispiel Treiber nicht mehr richtig nachgeladen werden koennen
Daher steht die Vermutung im Raum, dass die Anleitung falsch (und gefaehrlich) ist und man in Wirklichkeit bei der Installation kernel0 ersetzen muss. Ausserdem muss dafuer gesorgt werden, dass der Bootloader kernel0 beim Booten laedt und nicht kernel1. Dafuer muesste das erste Byte in der Partition "bs" verantwortlich sein.
Da ist nicht weiss welche Mechanismen Ubiquiti neben dem ersten Byte in "bs" fuer die Auswahl des zu ladenden Linux-Kernels nutzt, koennte diese Beschreibung unvollstaendig sein.
Ich bitte um eine Ueberpruefung/Korrektur des Artikels und gegebenenfalls um Hinweise wo ich eine falsche Annahme getroffen habe.
Gruesse, Sven
[1] https://vogtland.freifunk.net/freifunk-vogtland-router-firmware-einspielen-2... [2] https://wiki.openwrt.org/toh/ubiquiti/unifiac#sectionedit28 [3] https://github.com/openwrt/openwrt/blob/d168c2cf81ab4218df4c9b43e4483b6340bc... [4] https://github.com/openwrt/openwrt/blob/d168c2cf81ab4218df4c9b43e4483b6340bc... [5] https://github.com/openwrt/openwrt/blob/d168c2cf81ab4218df4c9b43e4483b6340bc...
On Samstag, 16. Juni 2018 17:19:57 CEST Sven Eckelmann via Freifunk_info wrote: [...]
Da ist nicht weiss welche Mechanismen Ubiquiti neben dem ersten Byte in "bs" fuer die Auswahl des zu ladenden Linux-Kernels nutzt, koennte diese Beschreibung unvollstaendig sein.
Gerade von Matthias Schiffer noch die fehlende Info bekommen, dass man kernel1 noch zusaetzlich "invalidieren" muss:
<neoraider> ecsv: you need to flash the image to kernel0 and adjust bs; in addition you must either erase kernel1 or just flash the image to kernel1 as well, as the bootloader will prefer a (signed) stock image to the OpenWrt image even when bs says otherwise
Gruesse, Sven
-----Ursprüngliche Nachricht----- Von: Freifunk_info freifunk_info-bounces@freifunk-vogtland.net Im Auftrag von Sven Eckelmann via Freifunk_info Gesendet: Samstag, 16. Juni 2018 21:05 An: info@freifunk-vogtland.net Cc: Sven Eckelmann sven@narfation.org Betreff: Re: [Freifunk_info] Website: Freifunk Vogtland Router Firmware installieren UniFi AP AC
On Samstag, 16. Juni 2018 17:19:57 CEST Sven Eckelmann via Freifunk_info wrote: [...]
Da ist nicht weiss welche Mechanismen Ubiquiti neben dem ersten Byte in
"bs"
fuer die Auswahl des zu ladenden Linux-Kernels nutzt, koennte diese Beschreibung unvollstaendig sein.
Gerade von Matthias Schiffer noch die fehlende Info bekommen, dass man kernel1 noch zusaetzlich "invalidieren" muss:
<neoraider> ecsv: you need to flash the image to kernel0 and adjust bs; in addition you must either erase kernel1 or just flash the image to kernel1 as well, as the bootloader will prefer a (signed) stock image to the OpenWrt image even when bs says otherwise
Gruesse, Sven
Hi Soweit ich mich erinnere hatte das nach # mtd -r -e kernel1 write /tmp/firmware.bin kernel1 hingehauen.. vorher hat der immer wieder die original Firmware gebootet. Tatsächlich hatten wir auch eine andere Anleitung.... vielleicht weiß Maximilian die Seite noch? Pascal.
On Samstag, 16. Juni 2018 21:56:55 CEST P. Wettin via Freifunk_info wrote: [...]
Soweit ich mich erinnere hatte das nach # mtd -r -e kernel1 write /tmp/firmware.bin kernel1 hingehauen.. vorher hat der immer wieder die original Firmware gebootet. Tatsächlich hatten wir auch eine andere Anleitung.... vielleicht weiß Maximilian die Seite noch? Pascal.
Siehe "bootselect steht auf 1: " in meiner originalen Mail um zu verstehen wieso das bei einem sysupgrade nicht korrekt funktionieren sollte. Ist zwar schoen wenn es erstmal bootet, aber wenn es nach dem sysupgrade immer noch den "alten" OpenWrt-Kernel bootet, ist das Geraet trotzdem erstmal non-funktional. Daher muss bei der initialen Installation sichergestellt werden, dass:
* kernel0 gebootet wird - mtd erase kernel0 - dd if=/dev/zero bs=1 count=1 of=/dev/mtdX * das image auf kernel0 geschrieben wird - mtd write /tmp/firmware.bin kernel0
Gruesse, Sven
-
P. Wettin -
Sven Eckelmann