Hallo zusammen,
Wir hatten bei dem letzten Firmware release die Images für die AP-AC Mesh/Lite/Pro aus dem autoupdater genommen. Wie sich im Nachhinein herausstellte, gab es einen Fehler in der OpenWRT Dokumentation. Die Dokumentation ist nun gefixt[0].
Ein wenig technischen Hintergrund will ich euch natürlich auch mit geben da ich ja weiß wie sehr sich einige danach sehnen :)
Jeder der Schonmal einen der o.G. Geräte geflash hat weiß das die Geräte zweit Kernel Partitionen haben. Das ist auf ein Flipflop Flash zurück zu führen und ich daher eigentlich ein ganz nettes Feature. Um nun eine Freifunk Firmware drauf installiert zu bekommen, muss man sowohl kernel0 als auch kernel1 mit der Freifunk Firmware beflashen. Das ist darauf rückzuführen das der Bootloader signierte Images bevorzugt und somit das Stock Image immer bevorzugt. Als Beispiel Flash man nur Kernel 0 oder 1 und läst auf der anderen weiterhin die stockt so würde immer nur die Stock Firmware von kernel1 gebootet werden, das wie oben schon erwähnt der bootloader die Stock Firmware bevorzugt. Nun kommen wir zur Problem Situation wird ein sysupgrade z.b. durch den autoupdater ausgeführt so wird einer der beiden Kernel Partitionen mit dem neuen Image gefalsh die andere Partition beinhaltet nach wie vor das alte Image nun besteht eine (50|50) Chance das von der upgedateten Kernel Partition gebootet wird das soweit kein Problem darstellt. Das Problem entsteht wenn von der 2. Partition gebootet wird das führt dann u.a. zu Kernel ABI Problemen was somit in einem gebrikten Router endet.
Die Auswahl der Kernel Partition finden mit Hilfe der BS Partition statt. Diese ist in Lede read only (ro) im Kernel hinterlegt. Um nun sicherzustellen, das dauerhaft von der richtigen Partition gebootet wird, muss ein null Byte in die BS Partition geschrieben werden. Dieses ist allerdings nicht aus dem lede System möglich, was leider dazuführt das alle die einen der o.g. Router Modelle betreiben ihr Gerät erst mit der Original Firmware recovern müssen und dann wieder beide Kernel Partitionen mit einer Freifunk Firmware beflaschen müssen. Zusätzlich muss ein null Byte in die BS Partition geschrieben werden, damit sicher gestellt ich das immer von der kernel0 Partition gebootet wird, siehe dazu auch in der Doku [0].
Eine Diskussion dazu auf unserer dev liste findet ihr hier [1]. @Ulf hast du Lust einen Blog Artikel daraus zu zaubern? Das wäre durchaus eine wichtige Notiz für Router Betreiber.
Schöne grüße und gute Nacht :) Tarek
[0] https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
[1] https://lists.ffnw.de/hyperkitty/list/dev@lists.ffnw.de/thread/5C5VWAONJTEHN...
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu parsen :)
Am 12.04.2018 um 01:16 schrieb Jan-Tarek Butt via Nordwest:
Hallo zusammen,
Wir hatten bei dem letzten Firmware release die Images für die AP-AC Mesh/Lite/Pro aus dem autoupdater genommen. Wie sich im Nachhinein herausstellte, gab es einen Fehler in der OpenWRT Dokumentation. Die Dokumentation ist nun gefixt[0].
Ein wenig technischen Hintergrund will ich euch natürlich auch mitgeben, da ich ja weiß, wie sehr sich einige danach sehnen :)
Jeder, der schon einmal einen der o.G. Geräte geflasht hat, weiß, dass die Geräte zwei Kernel Partitionen haben. Das ist auf ein Flipflop Flash zurückzuführen und ist daher eigentlich ein ganz nettes Feature. Um nun eine Freifunk Firmware drauf installiert zu bekommen, muss man sowohl kernel0 als auch kernel1 mit der Freifunk Firmware beflashen. Das ist darauf rückzuführen, dass der Bootloader signierte Images bevorzugt und somit wird das Stock Image immer gebootet. Als Beispiel: Flasht man nur Kernel 0 oder 1 und lässt auf der anderen weiterhin die Stock, so würde immer nur die Stock Firmware von kernel1 gebootet werden, da wie oben schon erwähnt der bootloader die Stock Firmware bevorzugt. Nun kommen wir zur Problemsituation. Wird ein sysupgrade z.B. durch den autoupdater ausgeführt, so wird einer der beiden Kernel Partitionen mit dem neuen Image geflasht die andere Partition beinhaltet nach wie vor das alte Image nun besteht eine (50|50) Chance das von der upgedateten Kernel Partition gebootet wird. Das ist soweit kein Problem. Das Problem entsteht, wenn von der 2. Partition gebootet wird das führt dann u.a. zu Kernel ABI Problemen was somit in einem gebrickten Router endet.
Die Auswahl der Kernel Partition findet mit Hilfe der BS (Bootsector ?) Partition statt. Diese ist in Lede read only (ro) im Kernel hinterlegt. Um nun sicherzustellen, dass dauerhaft von der richtigen Partition gebootet wird, muss ein null Byte in die BS Partition geschrieben werden. Dieses ist allerdings nicht aus dem lede System möglich, was leider dazuführt das alle die einen der o.g. Router Modelle betreiben ihr Gerät erst mit der Original Firmware recovern müssen und dann wieder beide Kernel Partitionen mit einer Freifunk Firmware beflashen müssen. Zusätzlich muss ein null Byte in die BS Partition geschrieben werden, damit sicher gestellt ist, dass immer von der kernel0 Partition gebootet wird, siehe dazu auch in der Doku [0].
Eine Diskussion dazu auf unserer dev liste findet ihr hier [1]. @Ulf hast du Lust einen Blog Artikel daraus zu zaubern? Das wäre durchaus eine wichtige Notiz für Router Betreiber.
Schöne grüße und gute Nacht :) Tarek
[0] https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
[1] https://lists.ffnw.de/hyperkitty/list/dev@lists.ffnw.de/thread/5C5VWAONJTEHN...
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Hallo Leute,
ich wüßte gerne, woran ich bei laufender ffnw-firmware erkennen kann, ob ein Gerät einen solchen flip-flop-flash hat. Dann könnte man entscheiden, ob es save, ist den autoupdater dort wieder einzuschalten, bzw. ein sysupgrade durchzuführen.
LG Lorenz
Am 12.04.2018 um 09:43 schrieb Jan-Tarek Butt via Nordwest:
On 04/12/18 08:07, lrnzo via Nordwest wrote:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu parsen :)
Naklar, war gestern schon ein bisschen später... und Rechtschreibung hab ich ja schon öfter mal mit zu kämpfen ;P
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
cat /proc/mtd
Da nach bs Partition schauen.
Das dürfte bei den ubiquiti Geräten recht zuverlässig funktionieren. Das hängt allerdings immer vom bootloader ab, d. H. erstmal sind alle Geräte "gefährdet", die nur ein sysupgrade Image haben und kein factory.
lrnzo via Nordwest nordwest@lists.ffnw.de schrieb am Sa., 14. Apr. 2018, 14:21:
Hallo Leute,
ich wüßte gerne, woran ich bei laufender ffnw-firmware erkennen kann, ob ein Gerät einen solchen flip-flop-flash hat. Dann könnte man entscheiden, ob es save, ist den autoupdater dort wieder einzuschalten, bzw. ein sysupgrade durchzuführen.
LG Lorenz
Am 12.04.2018 um 09:43 schrieb Jan-Tarek Butt via Nordwest:
On 04/12/18 08:07, lrnzo via Nordwest wrote:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu
parsen :)
Naklar, war gestern schon ein bisschen später... und Rechtschreibung hab
ich ja schon öfter mal mit zu kämpfen ;P
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
genau das dachte ich mir auch, aber cat /proc/mtd sieht bei laufender freifunk-firmware auf einer AC-Mesh (Häschenförmig) bzw. AC-Lite (Tellerförmig) exakt gleich aus, nämlich so
dev: size erasesize name mtd0: 00060000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00790000 00010000 "firmware" mtd3: 00150000 00010000 "kernel" mtd4: 00640000 00010000 "rootfs" mtd5: 003d0000 00010000 "rootfs_data" mtd6: 00790000 00010000 "ubnt-airos" mtd7: 00020000 00010000 "bs" mtd8: 00040000 00010000 "cfg" mtd9: 00010000 00010000 "EEPROM"
der einzige kleine Unterschied ist die size von mtd5: 003d0000 bzw 003c0000. Ich bin bisher davon ausgegangen, dass die AC-Lite-Teller keinen flip-flop-flash haben.
LG Lorenz
Am 15.04.2018 um 09:00 schrieb Simon Kurka via Nordwest:
cat /proc/mtd
Da nach bs Partition schauen.
Das dürfte bei den ubiquiti Geräten recht zuverlässig funktionieren. Das hängt allerdings immer vom bootloader ab, d. H. erstmal sind alle Geräte "gefährdet", die nur ein sysupgrade Image haben und kein factory.
lrnzo via Nordwest nordwest@lists.ffnw.de schrieb am Sa., 14. Apr. 2018, 14:21:
Hallo Leute,
ich wüßte gerne, woran ich bei laufender ffnw-firmware erkennen kann, ob ein Gerät einen solchen flip-flop-flash hat. Dann könnte man entscheiden, ob es save, ist den autoupdater dort wieder einzuschalten, bzw. ein sysupgrade durchzuführen.
LG Lorenz
Am 12.04.2018 um 09:43 schrieb Jan-Tarek Butt via Nordwest:
On 04/12/18 08:07, lrnzo via Nordwest wrote:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu
parsen :)
Naklar, war gestern schon ein bisschen später... und Rechtschreibung hab
ich ja schon öfter mal mit zu kämpfen ;P
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Da würde ich aber stark von ausgehen. Es hat einen bootselect und zwei flash Partitionen. Recht eindeutig.
lrnzo via Nordwest nordwest@lists.ffnw.de schrieb am So., 15. Apr. 2018, 09:17:
genau das dachte ich mir auch, aber cat /proc/mtd sieht bei laufender freifunk-firmware auf einer AC-Mesh (Häschenförmig) bzw. AC-Lite (Tellerförmig) exakt gleich aus, nämlich so
dev: size erasesize name mtd0: 00060000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00790000 00010000 "firmware" mtd3: 00150000 00010000 "kernel" mtd4: 00640000 00010000 "rootfs" mtd5: 003d0000 00010000 "rootfs_data" mtd6: 00790000 00010000 "ubnt-airos" mtd7: 00020000 00010000 "bs" mtd8: 00040000 00010000 "cfg" mtd9: 00010000 00010000 "EEPROM"
der einzige kleine Unterschied ist die size von mtd5: 003d0000 bzw 003c0000. Ich bin bisher davon ausgegangen, dass die AC-Lite-Teller keinen flip-flop-flash haben.
LG Lorenz
Am 15.04.2018 um 09:00 schrieb Simon Kurka via Nordwest:
cat /proc/mtd
Da nach bs Partition schauen.
Das dürfte bei den ubiquiti Geräten recht zuverlässig funktionieren. Das hängt allerdings immer vom bootloader ab, d. H. erstmal sind alle Geräte "gefährdet", die nur ein sysupgrade Image haben und kein factory.
lrnzo via Nordwest nordwest@lists.ffnw.de schrieb am Sa., 14. Apr.
2018,
14:21:
Hallo Leute,
ich wüßte gerne, woran ich bei laufender ffnw-firmware erkennen kann, ob ein Gerät einen solchen flip-flop-flash hat. Dann könnte man
entscheiden,
ob es save, ist den autoupdater dort wieder einzuschalten, bzw. ein sysupgrade durchzuführen.
LG Lorenz
Am 12.04.2018 um 09:43 schrieb Jan-Tarek Butt via Nordwest:
On 04/12/18 08:07, lrnzo via Nordwest wrote:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu
parsen :)
Naklar, war gestern schon ein bisschen später... und Rechtschreibung
hab
ich ja schon öfter mal mit zu kämpfen ;P
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Hallo Leute,
habe gerade gesehen, dass ab Version 20180225 die BS-Partition schreibbar ist. Wenn ich es richtig verstanden habe, muss man also hier nicht mehr den Umweg über Stockfirmware gehen, sondern kann direkt in der laufenden Freifunkfirmware mit folgendem Befehl das Nullbyte in die BootSelector-Partition schreiben.
dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')"
ein _danach_ ausgeführter autoupdater (falls dieser deaktiviert wurde, muss er natürlich erstmal wieder aktiviert werden) wirft dann wegen zur Sicherheit umbenannter Images einen Fehler 404, sagt einem aber auch, welches Image er herunterladen wollte. Bsp:
============================8<============================ Downloading 'http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-...' Connecting to 2a06:e881:2000:12::15:80 HTTP error 404 ============================>8============================
also ist in diesem Fall nichts weiter zu tun als:
============================8<============================ cd /tmp/ wget http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-... sysupgrade gluon-ffnw-20180413-ubiquiti-unifi-ac-lite-sysupgrade.bin-m ============================>8============================
ich kann zwar keine Garantie dafür geben, dass das immer totsicher klappt, aber ich habe es schon auf einigen Routern so durchgeführt und bisher ist mir jeder mit 20180413er Firmware wiedergekommen.
Sollte wie gesagt ab Firmware 20180225 funktionieren.
LG Lorenz
Am 12.04.2018 um 08:07 schrieb lrnzo via Nordwest:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu parsen :)
Am 12.04.2018 um 01:16 schrieb Jan-Tarek Butt via Nordwest:
Hallo zusammen,
Wir hatten bei dem letzten Firmware release die Images für die AP-AC Mesh/Lite/Pro aus dem autoupdater genommen. Wie sich im Nachhinein herausstellte, gab es einen Fehler in der OpenWRT Dokumentation. Die Dokumentation ist nun gefixt[0].
Ein wenig technischen Hintergrund will ich euch natürlich auch mitgeben, da ich ja weiß, wie sehr sich einige danach sehnen :)
Jeder, der schon einmal einen der o.G. Geräte geflasht hat, weiß, dass die Geräte zwei Kernel Partitionen haben. Das ist auf ein Flipflop Flash zurückzuführen und ist daher eigentlich ein ganz nettes Feature. Um nun eine Freifunk Firmware drauf installiert zu bekommen, muss man sowohl kernel0 als auch kernel1 mit der Freifunk Firmware beflashen. Das ist darauf rückzuführen, dass der Bootloader signierte Images bevorzugt und somit wird das Stock Image immer gebootet. Als Beispiel: Flasht man nur Kernel 0 oder 1 und lässt auf der anderen weiterhin die Stock, so würde immer nur die Stock Firmware von kernel1 gebootet werden, da wie oben schon erwähnt der bootloader die Stock Firmware bevorzugt. Nun kommen wir zur Problemsituation. Wird ein sysupgrade z.B. durch den autoupdater ausgeführt, so wird einer der beiden Kernel Partitionen mit dem neuen Image geflasht die andere Partition beinhaltet nach wie vor das alte Image nun besteht eine (50|50) Chance das von der upgedateten Kernel Partition gebootet wird. Das ist soweit kein Problem. Das Problem entsteht, wenn von der 2. Partition gebootet wird das führt dann u.a. zu Kernel ABI Problemen was somit in einem gebrickten Router endet.
Die Auswahl der Kernel Partition findet mit Hilfe der BS (Bootsector ?) Partition statt. Diese ist in Lede read only (ro) im Kernel hinterlegt. Um nun sicherzustellen, dass dauerhaft von der richtigen Partition gebootet wird, muss ein null Byte in die BS Partition geschrieben werden. Dieses ist allerdings nicht aus dem lede System möglich, was leider dazuführt das alle die einen der o.g. Router Modelle betreiben ihr Gerät erst mit der Original Firmware recovern müssen und dann wieder beide Kernel Partitionen mit einer Freifunk Firmware beflashen müssen. Zusätzlich muss ein null Byte in die BS Partition geschrieben werden, damit sicher gestellt ist, dass immer von der kernel0 Partition gebootet wird, siehe dazu auch in der Doku [0].
Eine Diskussion dazu auf unserer dev liste findet ihr hier [1]. @Ulf hast du Lust einen Blog Artikel daraus zu zaubern? Das wäre durchaus eine wichtige Notiz für Router Betreiber.
Schöne grüße und gute Nacht :) Tarek
[0] https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
[1] https://lists.ffnw.de/hyperkitty/list/dev@lists.ffnw.de/thread/5C5VWAONJTEHN...
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Ahh super! Danke für die Info!
lrnzo via Nordwest nordwest@lists.ffnw.de schrieb am Fr., 27. Apr. 2018, 23:52:
Hallo Leute,
habe gerade gesehen, dass ab Version 20180225 die BS-Partition schreibbar ist. Wenn ich es richtig verstanden habe, muss man also hier nicht mehr den Umweg über Stockfirmware gehen, sondern kann direkt in der laufenden Freifunkfirmware mit folgendem Befehl das Nullbyte in die BootSelector-Partition schreiben.
dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')"
ein _danach_ ausgeführter autoupdater (falls dieser deaktiviert wurde, muss er natürlich erstmal wieder aktiviert werden) wirft dann wegen zur Sicherheit umbenannter Images einen Fehler 404, sagt einem aber auch, welches Image er herunterladen wollte. Bsp:
============================8<============================ Downloading ' http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-... ' Connecting to 2a06:e881:2000:12::15:80 HTTP error 404 ============================>8============================
also ist in diesem Fall nichts weiter zu tun als:
============================8<============================ cd /tmp/ wget http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-... sysupgrade gluon-ffnw-20180413-ubiquiti-unifi-ac-lite-sysupgrade.bin-m ============================>8============================
ich kann zwar keine Garantie dafür geben, dass das immer totsicher klappt, aber ich habe es schon auf einigen Routern so durchgeführt und bisher ist mir jeder mit 20180413er Firmware wiedergekommen.
Sollte wie gesagt ab Firmware 20180225 funktionieren.
LG Lorenz
Am 12.04.2018 um 08:07 schrieb lrnzo via Nordwest:
Danke Tarek! Habe mir aber erlaubt, das einmal rechtschreibmäßig zu
parsen :)
Am 12.04.2018 um 01:16 schrieb Jan-Tarek Butt via Nordwest:
Hallo zusammen,
Wir hatten bei dem letzten Firmware release die Images für die AP-AC
Mesh/Lite/Pro aus dem autoupdater genommen. Wie sich im Nachhinein herausstellte, gab es einen Fehler in der OpenWRT Dokumentation. Die Dokumentation ist nun gefixt[0].
Ein wenig technischen Hintergrund will ich euch natürlich auch
mitgeben, da ich ja weiß, wie sehr sich einige danach sehnen :)
Jeder, der schon einmal einen der o.G. Geräte geflasht hat, weiß, dass
die Geräte zwei Kernel Partitionen haben. Das ist auf ein Flipflop Flash zurückzuführen und ist daher eigentlich ein ganz nettes Feature. Um nun eine Freifunk Firmware drauf installiert zu bekommen, muss man sowohl kernel0 als auch kernel1 mit der Freifunk Firmware beflashen. Das ist darauf rückzuführen, dass der Bootloader signierte Images bevorzugt und somit wird das Stock Image immer gebootet. Als Beispiel: Flasht man nur Kernel 0 oder 1 und lässt auf der anderen weiterhin die Stock, so würde immer nur die Stock Firmware von kernel1 gebootet werden, da wie oben schon erwähnt der bootloader die Stock Firmware bevorzugt. Nun kommen wir zur Problemsituation. Wird ein sysupgrade z.B. durch den autoupdater ausgeführt, so wird einer der beiden Kernel Partitionen mit dem neuen Image geflasht die andere Partition beinhaltet nach wie vor das alte Image nun besteht eine (50|50) Chance das von der upgedateten Kernel Partition gebootet wird. Das ist soweit kein Problem. Das Problem entsteht, wenn von der 2. Partition gebootet wird das führt dann u.a. zu Kernel ABI Problemen was somit in einem gebrickten Router endet.
Die Auswahl der Kernel Partition findet mit Hilfe der BS (Bootsector ?)
Partition statt. Diese ist in Lede read only (ro) im Kernel hinterlegt. Um nun sicherzustellen, dass dauerhaft von der richtigen Partition gebootet wird, muss ein null Byte in die BS Partition geschrieben werden. Dieses ist allerdings nicht aus dem lede System möglich, was leider dazuführt das alle die einen der o.g. Router Modelle betreiben ihr Gerät erst mit der Original Firmware recovern müssen und dann wieder beide Kernel Partitionen mit einer Freifunk Firmware beflashen müssen. Zusätzlich muss ein null Byte in die BS Partition geschrieben werden, damit sicher gestellt ist, dass immer von der kernel0 Partition gebootet wird, siehe dazu auch in der Doku [0].
Eine Diskussion dazu auf unserer dev liste findet ihr hier [1]. @Ulf
hast du Lust einen Blog Artikel daraus zu zaubern? Das wäre durchaus eine wichtige Notiz für Router Betreiber.
Schöne grüße und gute Nacht :) Tarek
[0] https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
[1]
https://lists.ffnw.de/hyperkitty/list/dev@lists.ffnw.de/thread/5C5VWAONJTEHN...
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
On 04/28/18 00:30, Simon Kurka via Nordwest wrote:
Ahh super! Danke für die Info!
Das Problem wird nach wie vor sein das ja der falsche kernel zu dem zeitpunkt gebootet sein könnten. Wenn müssten man vor dem update dann noch ein Reboot machen. wobei ich mir generell nicht sicher bin ob die Methode klappt. Könnte aber durchaus!!
vg Tarek
Darum ging es nicht. Lorenz hat mitgeteilt ab welcher Version man das Problem fixen kann, ohne die original Firmware.
Jan-Tarek Butt via Nordwest nordwest@lists.ffnw.de schrieb am Sa., 28. Apr. 2018, 12:19:
On 04/28/18 00:30, Simon Kurka via Nordwest wrote:
Ahh super! Danke für die Info!
Das Problem wird nach wie vor sein das ja der falsche kernel zu dem zeitpunkt gebootet sein könnten. Wenn müssten man vor dem update dann noch ein Reboot machen. wobei ich mir generell nicht sicher bin ob die Methode klappt. Könnte aber durchaus!!
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
Hallo zusammen,
On 04/27/18 21:21, lrnzo via Nordwest wrote:
Hallo Leute,
habe gerade gesehen, dass ab Version 20180225 die BS-Partition schreibbar ist. Wenn ich es richtig verstanden habe, muss man also hier nicht mehr den Umweg über Stockfirmware gehen, sondern kann direkt in der laufenden Freifunkfirmware mit folgendem Befehl das Nullbyte in die BootSelector-Partition schreiben.
dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')"
Wichtig ist das die mtd-Partitionen nur mit mdt beschrieben werden können! Und das ganze auch nur über die ganze Partition. D.h. der o.g. Befehl von lorenz wird nicht funktionieren. Wir wollen natürlich nach wie vor, nur das erste Byte überschreiben. Der befehl sollte also wie folgt lauten:
dd if=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')" of=/tmp/bs.bin && cat /dev/zero | dd conv=notrunc bs=1 count=1 of=/tmp/bs.bin && mtd write /tmp/bs.bin bs
befor mit den unten erklärten Autoupdate fortgefahren werden sollte, sollte ein reboot ausgeführt werden um sicherzustellen das die richtige Kernel Partition gebootet ist, um eventuelle Kernel ABI Probleme zu vermeiden. Sollte kein reboot ausgeführt worden sein besteht nach wie vor eine 50% Chance auf ein bricken des devices.
ein _danach_ ausgeführter autoupdater (falls dieser deaktiviert wurde, muss er natürlich erstmal wieder aktiviert werden) wirft dann wegen zur Sicherheit umbenannter Images einen Fehler 404, sagt einem aber auch, welches Image er herunterladen wollte. Bsp:
============================8<============================ Downloading 'http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-...' Connecting to 2a06:e881:2000:12::15:80 HTTP error 404 ============================>8============================
also ist in diesem Fall nichts weiter zu tun als:
============================8<============================ cd /tmp/ wget http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-... sysupgrade gluon-ffnw-20180413-ubiquiti-unifi-ac-lite-sysupgrade.bin-m ============================>8============================
ich kann zwar keine Garantie dafür geben, dass das immer totsicher klappt, aber ich habe es schon auf einigen Routern so durchgeführt und bisher ist mir jeder mit 20180413er Firmware wiedergekommen.
Sollte wie gesagt ab Firmware 20180225 funktionieren.
vg Tarek
da möchte ich aber kurz einwerfen, dass die beiden AC-Router, wo ich das wie oben beschrieben (und sogar ohne reboot vor dem sysupgrade) durchgeführt habe auch nach 5 Reboots immer noch nicht tot sind. Wenn das mit dd nicht funktioniert, müsste hier also ein Ereignis mit p=((0.5)^5)^2)=1/1024 vorliegen und das wäre ja schon ein ziemlicher Zufall. Dies sind die Geräte:
FF-Hilter-Rathaus-DF29 https://map.ffnw.de/#/de/map/788a20286b7b FF-Hilter-Rathaus-DF31 https://map.ffnw.de/#/de/map/788a202b43f0
LG Lorenz
Am 01.05.2018 um 23:19 schrieb Jan-Tarek Butt via Nordwest:
Hallo zusammen,
On 04/27/18 21:21, lrnzo via Nordwest wrote:
Hallo Leute,
habe gerade gesehen, dass ab Version 20180225 die BS-Partition schreibbar ist. Wenn ich es richtig verstanden habe, muss man also hier nicht mehr den Umweg über Stockfirmware gehen, sondern kann direkt in der laufenden Freifunkfirmware mit folgendem Befehl das Nullbyte in die BootSelector-Partition schreiben.
dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')"
Wichtig ist das die mtd-Partitionen nur mit mdt beschrieben werden können! Und das ganze auch nur über die ganze Partition. D.h. der o.g. Befehl von lorenz wird nicht funktionieren. Wir wollen natürlich nach wie vor, nur das erste Byte überschreiben. Der befehl sollte also wie folgt lauten:
dd if=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')" of=/tmp/bs.bin && cat /dev/zero | dd conv=notrunc bs=1 count=1 of=/tmp/bs.bin && mtd write /tmp/bs.bin bs
befor mit den unten erklärten Autoupdate fortgefahren werden sollte, sollte ein reboot ausgeführt werden um sicherzustellen das die richtige Kernel Partition gebootet ist, um eventuelle Kernel ABI Probleme zu vermeiden. Sollte kein reboot ausgeführt worden sein besteht nach wie vor eine 50% Chance auf ein bricken des devices.
ein _danach_ ausgeführter autoupdater (falls dieser deaktiviert wurde, muss er natürlich erstmal wieder aktiviert werden) wirft dann wegen zur Sicherheit umbenannter Images einen Fehler 404, sagt einem aber auch, welches Image er herunterladen wollte. Bsp:
============================8<============================ Downloading 'http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-...' Connecting to 2a06:e881:2000:12::15:80 HTTP error 404 ============================>8============================
also ist in diesem Fall nichts weiter zu tun als:
============================8<============================ cd /tmp/ wget http://autoupdate-lede.ffnw/fastd/stable/gluon-ffnw-20180413-ubiquiti-unifi-... sysupgrade gluon-ffnw-20180413-ubiquiti-unifi-ac-lite-sysupgrade.bin-m ============================>8============================
ich kann zwar keine Garantie dafür geben, dass das immer totsicher klappt, aber ich habe es schon auf einigen Routern so durchgeführt und bisher ist mir jeder mit 20180413er Firmware wiedergekommen.
Sollte wie gesagt ab Firmware 20180225 funktionieren.
vg Tarek
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de
-
Jan-Tarek Butt -
lrnzo -
Simon Kurka