Flash systemu turris do NOR

Stále je ve fázi testování. Je tam velký potenciál nevědomého poškození továrního resetu a tak v tomto případě do hloubky testujeme. Pokud se ale ptáte na to jestli to v řádu týdnů vydáme, tak to je asi nepravděpodobné.

Verzi nor asi nejjednodušeji zjistíte pomocí našeho nástroje diagnostics:

/usr/share/diagnostics/diagnostics.sh turris_version

To mi nefunguje:

root@turris:~# /usr/share/diagnostics/diagnostics.sh turris_version
############## turris_version
== current ==
3.9.1
== factory ==
mount: wrong fs type, bad option, bad superblock on /dev/mtdblock3,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
tar: can't open '/tmp/tmp.oqRMbn/medkit.tar.xz': No such file or directory
umount: /tmp/tmp.oqRMbn: not mounted
************** turris_version

a dmesg obsahuje toto:
[32969.108137] squashfs: SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock3

Co s tím můžu udělat? Obnova firmwaru resetovacím tlačítkem funguje, takže úplně rozbité to není.

Zkoušel jsem to i na druhém Turrisu a dopadlo to stejně neúspěšně.

Jo oprava. Děkuji, že jste našel bug. V původních verzích Turris 1.0 byly image uloženy v FS jffs2.
V podstatě tedy musíte udělat toto:

MNT="$(mktemp -d)"
mount -t jffs2 /dev/mtdblock3 "$MNT"
tar -xJf "$MNT/medkit.tar.xz" ./etc/turris-version -O
umount "$MNT"
rmdir "$MNT"

Pro úplnost: https://gitlab.labs.nic.cz/turris/diagnostics/issues/1

Má to asi pět řádků pro typ routeru a je to celkem nové. Ale obecně diagnostiky už máme dlouho a tohle je jen skript který je řeší na pozadí. Jinak je to to co je v záložce diagnostiky ve Forisu. Jak to funguje je implementační detail.

1 Like

tak je to posun, ale nefunguje to:

root@turris:/usr/share/diagnostics/modules# mount -t jffs2 /dev/mtdblock3 /mnt
mount: /dev/mtdblock3: can't read superblock

výpis z dmesg (je to podstatně delší, ale opakuje se víceméně to samé:

[87802.444356] jffs2: Old JFFS2 bitmask found at 0x0095d294
[87802.444362] jffs2: You cannot use older JFFS2 filesystems with newer kernels
[87802.450730] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960000: 0x7550 instead
[87802.450740] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960004: 0xf99c instead
[87802.450747] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960008: 0x5352 instead
[87802.450753] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0096000c: 0x36d8 instead
[87802.450759] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960010: 0xc125 instead
[87802.450766] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960014: 0xcd56 instead
[87802.450772] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960018: 0x77f6 instead
[87802.450778] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0096001c: 0x825d instead
[87802.450784] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960020: 0x2ed5 instead
[87802.450791] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00960024: 0x39a2 instead
[87802.450795] jffs2: Further such events for this erase block will not be printed
[87802.545050] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980000: 0xad52 instead
[87802.545062] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980004: 0x2831 instead
[87802.545068] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980008: 0x5742 instead
[87802.545074] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0098000c: 0xc2b3 instead
[87802.545081] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980010: 0xe765 instead
[87802.545087] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980014: 0x28d3 instead
[87802.545093] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980018: 0x538c instead
[87802.545100] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0098001c: 0x11a8 instead
[87802.545106] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980020: 0x5cc7 instead
[87802.545112] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00980024: 0xb40a instead
[87802.545117] jffs2: Further such events for this erase block will not be printed
[87802.634219] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
[87802.634230] jffs2: empty_blocks 11, bad_blocks 0, c->nr_blocks 88

Dobrá ještě jedna oprava, o pár commitů níže došlo ke změně ještě rozložení, takže na Turris 1.0 rootfs je asi v mtdblock9 (pěkná zábava hrabat se ve více jak pět let starých commitech). Tak ještě zkuste změnit číslo.

1 Like

Tak jo, jsme o krok dál, ale nevím jestli správným směrem:

############## turris_version
== current ==
3.9.1
== factory ==
tar: can't open '/tmp/tmp.FbRe75/medkit.tar.xz': No such file or directory
************** turris_version

No a problém je, že v tom že, v když to namountuju: /dev/mtdblock9 on /mnt type jffs2 (rw,relatime) tak tam ten soubor medkit fakt není. Je tam toto:

root@turris:/mnt# ls -la
drwxrwxr-x   18 root     root             0 Dec 12 20:13 .
drwxrwxr-x   18 root     root             0 Dec 12 20:13 ..
-rw-------    1 root     root          1024 Apr 22  2017 .rnd
drwxr-xr-x    2 root     root             0 Dec 12 20:13 bin
drwxr-xr-x    3 root     root             0 Dec 21 12:36 boot
-rw-------    1 root     root       1601536 Mar  9  2017 core
drwxr-xr-x    2 root     root             0 Feb  6  2014 dev
drwxr-xr-x   44 root     root             0 Jan 14 04:21 etc
-rwxr-xr-x    1 root     root            78 Sep 14 13:53 init
drwxr-xr-x   14 root     root             0 Dec 21 12:35 lib
drwxr-xr-x    2 root     root             0 Jun 22  2016 mnt
drwxr-xr-x    2 root     root             0 Feb  6  2014 proc
drwxr-xr-x    2 root     root             0 Dec 12 20:13 rom
drwxr-xr-x    2 root     root             0 Jan 14 13:24 root
drwxr-xr-x    2 root     root             0 Dec 21 12:35 sbin
drwxr-xr-x    2 root     root             0 Feb  6  2014 sys
drwxrwxrwt    2 root     root             0 Feb  6  2014 tmp
drwxr-xr-x    8 root     root             0 Nov 30  2016 usr
lrwxrwxrwx    1 root     root             4 Jun 28  2016 var -> /tmp
drwxr-xr-x    5 root     root             0 Jun 26  2017 www
drwxr-xr-x    8 root     root             0 Nov 25  2015 www2

přičemž

root@turris:/mnt# cat /mnt/etc/turris-version
3.9.1

ale žádný soubor medkit* tam není ani v podadresářích (resp. find ho nenašel). Co teď?

No ono je možné, že je tam přímo root a ne ten medkit. Ale ta 3.9.1 je divný, to asi těžko. Na tuhle verzi jsme ani nevydali sd kartu. Asi ještě prostuduji starší verze toho recovery co jsem minul. Za chvíli se ozvu s tím jestli jsem něco nenašel. (Jinak proč tak slepě, nejsem v práci a neběží mi žádný router 1.0 na který bych se mohl připojit).

Edit: Dobře tak je to mtdblock3, 9 je root. Ale to mtdblock3 nemá žádný filesystem a postup je asi toto tedy:

dd if=/dev/mtdblock3 of=/tmp/rescue-medkit.tar.xz
tar -xJf /tmp/rescue-medkit.tar.xz ./etc/turris-version -O
rm /tmp/rescue-medkit.tar.xz

Asi tam bude ještě nějaký jiný problém - ale klidně to nechte až budete v práci…

root@turris:~# dd if=/dev/mtdblock3 of=/tmp/rescue-medkit.tar.xz
22528+0 records in
22528+0 records out    
root@turris:~# tar -xJf /tmp/rescue-medkit.tar.xz ./etc/turris-version -O
tar: corrupted data
tar: ./etc/turris-version: not found in archive

Jak se podívat co je v záchraném oddílu se řešilo tady a je to ověřené.

No jo, ověřené to možná je, ale mě nefungují první kroky - zjištění, jakou verzi v NOR mám, viz diskuse výše. První problém je, že mount očekává ntfs a já tam mám jffs2. Jenže aktuální verze systému odmítá jffs2 namountovat i když ho zadám explicitně, takže veškeré postupy obsahující na začátku mount tím pádem končí s chybou. Holt mám Turris 1.0 a ne 1.1.

Proč vlastně prvně neuděláte reflash nor z sdkarty? To je oficiálně supportovaný postup a jen co vidím ten postup odkazovaný tak tuším, že na 1.0 nebude fungovat kvůli tomu, že tam je jffs2 ne ubifs a před migrací na btrfs se musí provést migrace na ubifs a to právě kvůli updatu nor který v odkazovaném návodu není podchycený.

Skutečný a jediný podporovaný postup je napsaný v dokumentaci a jeho součástí je reflash z sdkarty kvůli updatu nor. Odkazovaný návod se o to samé pokouší ale naprosto míjí podstatu proč je to v návodu udělané. Pokud máte ubifs tak nemusíte nor updatovat, protože není ve skutečnosti důvod.
https://doc.turris.cz/doc/cs/troubleshooting/sdcard_recovery#prechod_z_jffs2_na_ubifs
https://doc.turris.cz/doc/cs/howto/btrfs_migration

@zab vy už jste podle toho návodu zkoušel už mtd write? Prosím to nedělejte, jak jsem psal, mezi Turris 1.0 a 1.1 se změnilo zřejmě rozložení nor a nejsem si jistý jakého výsledku by jste se dočkal.

Co vám vypíše cat /proc/mtd

v Turris 1.1 je to:

mtd0: 00020000 00020000 "NOR (RO) DTB Image"
mtd1: 001a0000 00020000 "NOR (RO) Linux Kernel Image"
mtd2: 00180000 00020000 "NOR (RO) JFFS2 Root File System"
mtd3: 00b00000 00020000 "NOR (RO) NAND FW backup"
mtd4: 000c0000 00020000 "NOR (RW) Cert backup"
mtd5: 00100000 00020000 "NOR (RO) U-Boot Image"
mtd6: 00200000 00020000 "NAND (RW) DTB Image"
mtd7: 00500000 00020000 "NAND (RW) Linux Kernel Image"
mtd8: 0f900000 00020000 "NAND (RW) JFFS2 Root File System"
mtd9: 10000000 00020000 "rootfs-ubifs"

Jinak s tím že mount nefunguje a dožaduje se NTFS jsem se setkal když byla jiná verze zavaděče systému (/boot/zImage, pro upřesnění jednalo se o BRFS na kartě kdy mi to nepřepsalo ten zImage soubor, který je čten v případě katry z její první partition /dev/mmcblk0p1 ) a verze balíčků uložená v systému.

Pokud si dobře pamatuji tak uvedené změny v rozložení probíhaly v updatu 2.4 a to při změně z JFFS2 na UBIFS.
Hledání verze v NOR nemá ani smysl řešit. Stejně pro přechod na UBIFS je třeba sériová konzole, protože je potřeba smazat nand. To už při rozebrání tam tu kartu můžu strčit.

1 Like

Ne, zápis jsem nezkoušel, právě proto, že jsem si nebyl jistý výsledkem, když nefunguje ani čtení. Ale dneska jsem koupil pro oba routery SD karty a ten přechod udělám podle oficiálního návodu. Můj úvodní dotaz vlastně začal tím, že jste zmínil že se chystáte udělat automatický přechod na ubifs, což by mi ušetřilo ředu rizikových operací.

1 Like

Mám to úplně přesně stejné. Uvidím, jak zafunguje přechod na ubifs.

Napadlo mne, když je ten medkit již tak velký že se nevejde co zkomprimovat všechny binárky exe packerem z https://upx.github.io/, který umí i ppc elf. Tím se dá místo ušetřit a třeba by se to pak vešlo. Zkusil jsem medkit pro turris přejmenovat na tar.xz a rozbalit a pak zkomprimovat pomocí tohoto packeru příkazem upx * v \bin adresářích a většinou to srazilo velikost na 50% nemám ale odvahu to vyzkoušet flashnout do turrise

@cynerd co na to rikas? Fungovalo by to?

jeste mi tam chybi posledni krok a to je zabalit zpet do tar.xz a pak porovnat. protoze jestli tomu dobre rozumim tak se tam nevejde ten .tar.xz ktery uz je komprimovany. dvojita komprese uz toho vetsinou moc neusetri

Asi takhle. Vlastně děláte dvojí kompresi takže nečekám úžasné výsledky. Je pravděpodobné, že se to o něco zmenší, ale nečekám obrovskou změnu. Udělal jsem si test na aktuální nightly.

$ fakeroot
# tar -xJf medkit-turris-nightly.tar.xz -C o
# cd o
# du -h bin /usr/bin
1.9M	bin
7.5M	usr/bin
# find -exec file {} \; | awk '/ELF 32-bit MSB executable/{print substr($1, 1, length($1)-1)}' | xargs upx --best
# tar -cJf ../new-medkit.tar.xz .
# du -h bin /usr/bin
1.1M	bin
5.6M	usr/bin
# exit
$ du -h medkit-turris-nightly.tar.xz new-medkit.tar.xz
17M	medkit-turris-nightly.tar.xz
18M	new-medkit.tar.xz

Jak je vidět tak bin a usr/bin se skutečně zmenšili ale celkový medkit je následně větší protože na komprimované data (v podstatě náhodná) je zase o něco méně efektivní xz komprese.