.titleBar { margin-bottom: 5px!important; }

Fehler bei Systemauswahl im Freetz im "no freetz" Modus für 7590

Dieses Thema im Forum "Freetz" wurde erstellt von reinelektronik, 5 Okt. 2018.

  1. reinelektronik

    reinelektronik Neuer User

    Registriert seit:
    6 Dez. 2007
    Beiträge:
    53
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo,

    bei der erstellten Firmware für FB7590 mit Ver.7.01 im no freetz Modus ist bei Neustart die Meldung vorhanden:
    Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:93 [string "/usr/www/avm/system/reboot.lua:93"]:4: unexpected symbol near '<'
    im ersten Teil bei der Systemauswahl und die Auswahl gibt es nochmal und dort kommt:
    Luacgi Parse ERROR in file /usr/www/avm/system/reboot.lua line 107: ?> without <?lua or <?include

    und eine Umschaltung über diese Auswahl ist möglich auch wenn ich das vorherige System anklicke und neu starten lassen geht es immer auf das jetzige und Telnet geht in der Version auch nicht ich muss dann auf EVA gehen um das alte System zu starten.

    Wo liegt da denn der Fehler.

    Gruß Reiner
     
  2. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,068
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #2 PeterPawn, 5 Okt. 2018
    Zuletzt bearbeitet: 5 Okt. 2018
    Selbst mit Patch hat bei mir die Datei "usr/www/avm/system/reboot.lua" keine 93 oder gar 107 Zeilen (und ja, es ist die aus der 154.07.01):
    Code:
      1 <?lua
      2 g_page_type = "all"
    [...]
      8 if box.post.linux_fs_start then
      9 local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
     10 local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
     11 os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
     12 end
     13 webuicookie.set_action_allowed_time()
    [...]
     68 <form action="/system/reboot.lua" method="POST">
     69 <div id="managed_reboot" class="reboot_managed">
     70 <?lua
     71 pipe = io.popen("/usr/bin/gui_bootmanager html_display")
     72 line = pipe:read("*a")
     73 pipe:close()
     74 box.out(line)
     75 ?>
     76 </div>
     77 <div id="btn_form_foot">
    [...]
     88 </script>
     89 <?include "templates/html_end.html" ?>
    
    [ Ich habe die meisten Zeilen gelöscht, damit die Datei nicht als "Vollzitat" erscheint, weil sie halt dem Urheberrecht von AVM unterliegt - wie hoch die Schöpfungshöhe sein mag und ob das für die eigene Verwendung geändert werden darf oder nicht, ist hier nicht das Thema, es geht mir um die "Veröffentlichung" des AVM-Codes in Gänze. ]

    Die Zeilennummer ändert sich auch durch "include"-Statements nicht ... wenn ich in Zeile 70 das "<?lua"-Tag für den serverseitigen Code absichtlich ändere (bei einer 7490 mit 07.01, aber das sollte keinen Unterschied machen), kriege ich die Nachricht:
    Code:
    Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:71 [string "/usr/www/avm/system/reboot.lua:71"]:2: '=' expected near 'pipe'
    
    , obwohl auch davor schon (in Zeile 44 und 55) zwei "include"-Statements stehen.

    Mir fehlt etwas die Phantasie, was hier passiert sein soll ... ich habe zwar keine Ahnung, wie "modpatch" im Inneren arbeitet (und überhaupt keinen Ehrgeiz, das zu erkunden), aber eigentlich kann das dann nur bei der Integration schieflaufen in https://github.com/Freetz/freetz/blob/master/patches/scripts/800-modfs_boot_manager.sh - aber nur "Theorie" ohne jeden Beweis und jeden Versuch, das tatsächlich zu ergründen.

    Die Fehlernachrichten weisen darauf hin, daß da eine Zeile "<?lua" irgendwie falsch ersetzt wurde ... nun hat ja das "?" innerhalb von regulären Ausdrücken eine spezielle Bedeutung und wenn das beim "modpatch" irgendwie gesondert behandelt würde, wäre das zumindest eine Erklärung.

    Denn eine Zeile 70 in der Form:
    Code:
    <?lua<
    
    führt auch bei mir zu der Fehlermeldung:
    Code:
    Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:71 [string "/usr/www/avm/system/reboot.lua:71"]:1: unexpected symbol near '<'
    
    ... aber eben mit vollkommen anderen Zeilennummern und die zweite interessante Frage hier wäre ja, wo die zusätzlichen Zeilen in der "reboot.lua" am Ende herkommen sollten (das liefert vermutlich auch die Erklärung dafür, warum das im Ergebnis syntaktisch falsch ist).

    ------------------------------------------------------------------------------------------------

    Wobei das Handling der verschiedenen Verzeichnisse unterhalb von "usr/www" durch Freetz ohnehin eher "old school" ist und mit modernen Versionen nicht mehr wirklich etwas zu tun hat bzw. dort einigermaßen unnötig ist und außer möglichen Problemen keine begründeten Vorteile mehr liefert.

    Das Zusammenlegen aller vorhandenen Brandings auf "all" (über einen Symlink dorthin) impliziert erstens, daß sich diese Dateien in den verschiedenen Brandings tatsächlich nicht unterscheiden (was zwar meistens, aber eben nicht immer stimmt) und bringt zweitens bei der Verwendung von SquashFS auch keinen wirklich signifikanten Platzvorteil (wobei der Platz ohnehin nicht mehr das größte Problem ist in aktuellen Geräten), weil identische Dateien ohnehin nur einmal im SquashFS gespeichert werden und man nur (unwesentlich) Platz durch wegfallende Verwaltungsinformationen für die Dateien spart.

    Wenn hier merkliche Einsparungen zu erzielen wären, hätte sich AVM bestimmt auch schon mal selbst ans Werk gemacht und etwas umgestellt bzw. auf Firmwares mit mehreren "Brandings" verzichtet (einmal müssen die Dateien aber gespeichert werden). Daher bringt auch der "remove patch" für irgendwelche Brandings nicht wirklich etwas (mal abgesehen davon, daß der ohnehin statisch konfiguriert ist und gar nicht dynamisch von der jeweiligen "Vorlage-Firmware" abhängt) und man sollte ihn bei neueren Modellen besser auch weglassen, wenn man sein Image konfiguriert.

    TL;DR:
    Dazu müßte man den Inhalt der Datei "/usr/www/avm/system/reboot.lua" aus dem betroffenen Firmware-Image kennen, um daraus Rückschlüsse auf die Stelle zu ziehen, wo das Problem seinen Ursprung hat.
     
  3. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    960
    Zustimmungen:
    14
    Punkte für Erfolge:
    18
    Der yf/bootmanager/patch_system_reboot_lua.patch ist höchstwahrscheinlich mehrfach angewandt worden. Die hohen Zeilennummern, die es bei den anderen nicht gibt, sind ein diese Vermutung stützendes Indiz.

    Die mehrfache Anwendung des Patches ist bei der falschen Anwendung von Freetz im "no freetz"-Modus durchaus möglich, es existieren gar keine Vorkehrungen, die das verhindern wie es diese z.B. bei modfs gibt (precheck/postcheck). Die falsche Anwendung ist es, wenn man manche Schritte mehrfach ausführt, dann werden manche Patches eben mehrfach angewandt. Auch erneutes von vorne Starten ohne vorher das build-Verzeichnis zu löschen, kann im "no freetz"-Modus zu solchen Effekten führen.

    @PeterPawn:
    Deine Ausführungen über /usr/www/$branding treffen hier nicht zu. Und zwar insofern, dass im "no freetz"-Modus die gesamte Verzeichnisstruktur unangetastet bleibt (es sei denn der User hat eigene Befehle in fwmod_custom eingebaut). Von Freetz wird diesbezüglich jedoch nichts verändert.
     
  4. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,068
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #4 PeterPawn, 5 Okt. 2018
    Zuletzt bearbeitet: 5 Okt. 2018
    Sorry, die letzten drei Absätze hätte ich besser mit einem <hr /> abgesetzt ... das war nur eine Bemerkung zu den Branding-Verzeichnissen, den "remove patches" und dem erzielbaren Platzgewinn, die mir durch die Ansicht der "for"-Schleife (und dem zusätzlichen "all", auch wenn das über "test -d" und "test ! -L" abgefangen wird) in dem Shell-Skript zum Patchen durch den Kopf ging - das sehe ich gar nicht als Ursache für das hier aufgetretene Problem. Ich werde den "Ruler" einfach noch einfügen ...

    Wobei mir die Erklärung mit der mehrfachen Anwendung der Patch-Datei auch nicht einleuchtet. Ich habe zwar tatsächlich nur sehr wenige "Ankerzeilen" benutzt (nur eine davor und eine danach): https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/patch_system_reboot_lua.patch - aber trotzdem sollte bei der zweiten Anwendung eigentlich keine passende Kombination der zwei "vorher"-Zeilen mehr zu finden sein und zwar für keinen der beiden Hunks im Patch-File. Und Freetz nutzt ja das Patch-File und nicht das Shell-Skript mit dem "sed" (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/change_system_reboot_lua.sh) und sollte damit eigentlich auch "safe" sein, was doppeltes Patchen anbelangt - selbst wenn bei der zweiten Verwendung dann "reversed" vorgeschlagen werden sollte vom Patch-Programm, würden die Zeilen ja nur wieder entfernt.

    Wenn die Ankerzeilen tatsächlich unzureichend wären, würde ich sie entsprechend erweitern ... die Absicht war ja nur, den Patch so universell wie möglich zu halten und nicht bei jeder AVM-Änderung nachbessern zu müssen und das sollte nicht dafür sorgen, daß mehrfache Anwendung des Patches möglich ist ohne entsprechende Fehlermeldungen.
     
  5. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    960
    Zustimmungen:
    14
    Punkte für Erfolge:
    18
    #5 er13, 5 Okt. 2018
    Zuletzt bearbeitet: 6 Okt. 2018
    Ich habe es jetzt nachgestellt. Beim ersten Durchlauf sieht die Ausgabe so aus:
    Code:
      adding modfs boot-manager
        adding boot-manager front end to branding "1und1"
        applying patch file /tmp/bootmanager_system_reboot_lua-RRDTog.patch
        patching file usr/www/1und1/system/reboot.lua
        ----------------------------------------------------------------------
        adding boot-manager front end to branding "avm"
        applying patch file /tmp/bootmanager_system_reboot_lua-RRDTog.patch
        patching file usr/www/avm/system/reboot.lua
        ----------------------------------------------------------------------
        adding boot-manager back end script
    
    Beim zweiten dann so:
    Code:
      adding modfs boot-manager
        adding boot-manager front end to branding "1und1"
        applying patch file /tmp/bootmanager_system_reboot_lua-de3yi4.patch
        patching file usr/www/1und1/system/reboot.lua
        Hunk #1 succeeded at 7 with fuzz 1.
        Hunk #2 succeeded at 68 with fuzz 1.
        ----------------------------------------------------------------------
        adding boot-manager front end to branding "avm"
        applying patch file /tmp/bootmanager_system_reboot_lua-de3yi4.patch
        patching file usr/www/avm/system/reboot.lua
        Hunk #1 succeeded at 7 with fuzz 1.
        Hunk #2 succeeded at 68 with fuzz 1.
        ----------------------------------------------------------------------
        adding boot-manager back end script
    
    Edit: was dabei als Anker verwendet wird, ist mir ehrlich gesagt nicht klar, scheinbar nur die Zeilennummer (i.e. der gesamte Kontext wird ignoriert), denn die resultierende Datei sieht so aus:
    Code:
    1    <?lua
    2    g_page_type = "all"
    3    g_page_title = ""
    4    g_page_help = "hilfe_system_neustart.html"
    5    dofile("../templates/global_lua.lua")
    6    if next(box.post) and box.post.reboot then
    7    local savecookie = {}
    8    if box.post.linux_fs_start then
    9    local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
    10   local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
    11   os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
    12   end
    13   if box.post.linux_fs_start then
    14   local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
    15   local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
    16   os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
    17   end
    18   webuicookie.set_action_allowed_time()
    19   cmtable.add_var(savecookie, webuicookie.vars())
    20   box.set_config(savecookie)
    21   http.redirect(href.get("/reboot.lua"))
    22   end
    23   function show_act_calls()
    24   local str = ""
    25   if config.FON then
    26   require"foncalls"
    27   local calls = foncalls.get_activecalls()
    28   if #calls > 0 then
    29   str =[[<div id="uiActiveWarning">
    30   <strong>{?txtHinweis?}</strong>
    31   <p>{?6729:637?}]]
    32   str = str..[[</p><table id="uiActiveCall" class="zebra"><tr class="thead"><th></th>]]
    33   str = str..[[<th>{?6729:86?}</th><th>{?6729:309?}</th><th>{?6729:867?}</th></tr>]]
    34   for i, call in ipairs(calls) do
    35   local symbol = foncalls.get_callsymbol(call.call_type)
    36   str = str..[[
    37   <tr><td class="]]..box.tohtml(symbol.class or "")..[["></td>
    38   <td class="]]..box.tohtml(symbol.dirclass or "")..[[">]]..box.tohtml(foncalls.number_shortdisplay(call))..[[</td>
    39   <td>]]..box.tohtml(foncalls.port_display(call))..[[</td>
    40   <td>]]..box.tohtml(call.duration or "")..[[</td>
    41   </tr>]]
    42   end
    43   str = str..[[</table></div>]]
    44   end
    45   end
    46   return str
    47   end
    48   ?>
    49   <?include "templates/html_head.html" ?>
    50   <link rel="stylesheet" type="text/css" href="/css/default/static.css"/>
    51   <link rel="stylesheet" type="text/css" href="/css/default/update.css"/>
    52   <style type="text/css">
    53   #uiActiveWarning table {
    54   white-space: nowrap;
    55   }
    56   <?lua
    57   box.out(general.get_responsive_table_css("#uiActiveCall", "28.125"))
    58   ?>
    59   </style>
    60   <?include "templates/page_head.html" ?>
    61   <?lua
    62   box.out(show_act_calls())
    63   ?>
    64   <p>{?6729:135?}</p>
    65   <h4>{?6729:753?}</h4>
    66   <?lua
    67   if config.RAMDISK and box.query("ctlusb:settings/internalflash_enabled") == "1" then
    68   box.out('<p>'..[[{?6729:203?}]]..'</p>')
    69   <div id="managed_reboot" class="reboot_managed">
    70   <?lua
    71   pipe = io.popen("/usr/bin/gui_bootmanager html_display")
    72   line = pipe:read("*a")
    73   pipe:close()
    74   box.out(line)
    75   ?>
    76   </div>
    77   else
    78   box.out('<p>'..[[{?6729:620?}]]..'</p>')
    79   end
    80   ?>
    81   <form action="/system/reboot.lua" method="POST">
    82   <div id="managed_reboot" class="reboot_managed">
    83   <?lua
    84   pipe = io.popen("/usr/bin/gui_bootmanager html_display")
    85   line = pipe:read("*a")
    86   pipe:close()
    87   box.out(line)
    88   ?>
    89   </div>
    90   <div id="btn_form_foot">
    91   <input type="hidden" name="sid" value="<?lua box.html(box.glob.sid) ?>">
    92   <button type="submit" name="reboot">{?6729:911?}</button>
    93   </div>
    94   </form>
    95   <?include "templates/page_end.html" ?>
    96   <script type="text/javascript">
    97   function initActive() {
    98   jsl.writeDataLabel("uiActiveCall");
    99   }
    100  ready.onReady(initActive);
    101  </script>
    102  <?include "templates/html_end.html" ?>
    
    Man beachte den hinzugefügten Abschnitt innerhalb von "if config.RAMDISK ...", genau da gibt es zwei öffnende "<?lua"'s
     
  6. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,068
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Hmm ... ich finde einfach keine passenden Zeilen für den zweiten Durchlauf in der originalen AVM-Datei und wenn ich das zweimal ausführen lasse (die "reboot.lua" habe ich in das Verzeichnis kopiert), sieht das so aus:
    Code:
    vidar:/home/GitHub/YourFritz/bootmanager $ patch -p4 < patch_system_reboot_lua.patch
    patching file reboot.lua
    vidar:/home/GitHub/YourFritz/bootmanager $ patch -p4 < patch_system_reboot_lua.patch
    patching file reboot.lua
    Reversed (or previously applied) patch detected!  Assume -R? [n] n
    Apply anyway? [n] n
    Skipping patch.
    2 out of 2 hunks ignored -- saving rejects to file reboot.lua.rej
    vidar:/home/GitHub/YourFritz/bootmanager $
    
    Also muß es doch irgendetwas mit der Verarbeitung in "modpatch" zu tun haben, denn das "normale" Patch-Kommando reagiert wie erwartet.
     
  7. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    960
    Zustimmungen:
    14
    Punkte für Erfolge:
    18
    modpatch als Ursache ist durchaus möglich, dieses toleriert mehr Fuzz's als der regulärer patch. Dies wurde meines Wissens (ich habe modpatch nicht geschrieben) damals deswegen gemacht, damit ein und derselbe Patch bei mehreren Boxen verwendet werden könnte, auch wenn es bei manchen nicht ganz genau passt.
     
  8. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,068
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Vielleicht wäre es ja dann eine Idee, da das normale "patch" an dieser Stelle zu verwenden ... das stellt zumindest auch dann sicher, daß die Datei "nicht wächst", wenn der Benutzer das tatsächlich mehrfach aufruft im "no_freetz"-Modus.

    Wobei auch das automatische Löschen des "modified"-Verzeichnisses sicherlich eine Überlegung wert ist, wenn man Freetz im "no_freetz"-Modus verwendet ... durch "fakeroot" funktionieren i.d.R. ohnehin keine zwei Versuche nacheinander, ohne das "modified"-Verzeichnis zwischendrin zu löschen - so war zumindest mal meine Erfahrung, als ich mit "fwmod" eine 7270v3-Firmware modifizieren wollte in "Einzelschritten".

    Auch die Beschreibung (http://freetz.org/wiki/help/howtos/development/repack_fw) gibt das nicht so richtig her, daß der Benutzer selbst für ein Löschen verantwortlich ist ... und zwar nicht nur bei den "Einzelschritten" (-u + -p - da erscheint es notfalls noch logisch), sondern auch bei der (automatischen) Steuerung über "make".