232 replies to this topic

[MiLo]

Ik heb joan's bijdrage - iets aangepast - ingevoerd, nu is het maken van de autoinstall door de gebruiker zelf in te stellen.

[ni_hao]

djaivnt schreef:

Maakt een lijst van plug-ins die geïnstalleerd zijn op de box en plaatst deze in /etc/installed

Ik heb hier eens gekeken en in /etc/installed staan lang niet alle plugins welke geïnstalleerd zijn....

Overigens denk ik v.w.b. een restore dat de volgorde waarin e.e.a. wordt uitgevoerd van belang is. Het zou nl. zo moeten zijn dat eerst de plugins worden geinstalleerd, inclusief die door de gebruiker zijn aangegeven en pas daarna de door de gebruiker aangegeven bestanden worden teruggezet. Het kan nl. zijn dat iemand andere bestanden in een plugin plaatst NADAT deze is geïnstalleerd. Vandaar dus eerst de plugins installen.

[dzjaivnt]

djaivnt schreef:

Maakt een lijst van plug-ins die geïnstalleerd zijn op de box en plaatst deze in /etc/installed

Ik heb hier eens gekeken en in /etc/installed staan lang niet alle plugins welke geïnstalleerd zijn....

Bij de firstboot mag dit bestand alleen aangemaakt worden.
Daarna is het zinloos want dan "vergeet" hij user installed ipkgs.

[ni_hao]

Bij de firstboot mag dit bestand alleen aangemaakt worden.
Daarna is het zinloos want dan "vergeet" hij user installed ipkgs.

Is daar een bepaalde reden voor?

[MiLo]

...Het kan nl. zijn dat iemand andere bestanden in een plugin plaatst NADAT deze is geïnstalleerd...

Dat mag niet. Van bestanden die uit ipk's komen moet je afblijven.

[delagroov]

Nee: MQB is een lastige. Het is (bij mijn weten) de enige plugin waarvan de instellingen niet in "settings" staan, zodat je na installatie de eigen backup van de instellingen van MQB weer moet inlezen (ik exporteer die altijd naar de backup map op de HDD, dan staat alles bij elkaar).

ja ik ook ,alleen als je die backup uitpakt is het ook /etc/Multiquickbutton. (dm8000 aangepaste plugin)
Ik wil het wel even proberen na een flash.

Meega

Ik heb ook de MQB map in de backup.cfg staan, maar bij een schone flash moet ik toch weer zelf de MultiQuickButton_settings.tar.gz handmatig herstellen.

Krijg het vermoeden dat bij de autoinstall van MQB de bewaarde instellingen worden overschreven door de standaard.

[ni_hao]

MQB doet niets met de bewaarde instellingen tenzij je daar handmatig opdracht voor geeft. Na een install worden de default waarden weer teruggezet, dus zul je de backup van MQB zelf terug moeten zetten. Desgewenst kun je een script schrijven die de MQB backup terugschijft of je schrijft de backup bestanden (niet de .gz maar .xml bestanden) danwel de hele MQB map in /etc/backup.cfg zodat ze via settings-restore weer terug gezet worden. De MQB map vind je onder /etc. Maar ja dan blijft de volgorde, waar ik al eerder over schreef, waarin e.e.a. gerestored wordt van belang.

[MiLo]

Maar ja dan blijft de volgorde, waar ik al eerder over schreef, waarin e.e.a. gerestored wordt van belang.

Natuurlijk, eerst de settings terug zetten, en dan pas de plugins en dergelijke. Dan starten ze meteen met de goede configuratie op. Dat doet de automatische settings restore dan ook keurig, zelfs je fstab is er op tijd zodat je niet extra hoeft te rebooten.

[ni_hao]

@MiLo: dat is bekend maar het gaat er om eerst de plugins en dan de inhoud van /etc/backup.cfg terugzetten anders loop je tegen problemen aan zoals met MQB.
Overigens als je fstab later terug zou zetten hoef je echt niet opnieuw te booten hoor. En fstab terugzetten via die plugin gaat echt niet goed.

[delagroov]

MQB doet niets met de bewaarde instellingen tenzij je daar handmatig opdracht voor geeft. Na een install worden de default waarden weer teruggezet, dus zul je de backup van MQB zelf terug moeten zetten. Desgewenst kun je een script schrijven die de MQB backup terugschijft of je schrijft de backup bestanden (niet de .gz maar .xml bestanden) danwel de hele MQB map in /etc/backup.cfg zodat ze via settings-restore weer terug gezet worden. De MQB map vind je onder /etc. Maar ja dan blijft de volgorde, waar ik al eerder over schreef, waarin e.e.a. gerestored wordt van belang.

Ja dat laatste is nou net het probleem en heb ik dus zo gedaan,maar werkt dus niet.(drie maal getest).
Lijkt me dan iets wat gebeurt door de volgorde. In etc/backup.cfg heb ik staan /etc/MultiQuickButton.

Deze MQB map met xml bestanden worden ook netjes gebackupped door autobackup en zijn ook terug te vinden in de PLi-AutoBackup.tar.gz

Maarbij een schone flash worden blijkbaar eerst de gebruikersinstellingen terug gezet en later de MQB plugin geïnstalled, die mijn bewaarde MQB xml files uit de PLi-AutoBackup.tar.gz weer teniet doen.

Anders kan ik het niet verklaren.

[MiLo]

Da's dan een bug in MQB, meld het maar bij de auteur (met name degene die de IPK heeft gemaakt, want daarin zit de fout).

[MiLo]

@MiLo: dat is bekend maar het gaat er om eerst de plugins en dan de inhoud van /etc/backup.cfg terugzetten anders loop je tegen problemen aan zoals met MQB.

Ik zie het niet als taak voor autorestore om de bugs in MQB op te lossen.

En fstab terugzetten via die plugin gaat echt niet goed.

Wat gaat er bij jou mis dan?

[ni_hao]

Het is geen bug in MQB daar is bewust voor gekozen.
Wat er mis gaat met fstab is dat alleen mounts, die eigenlijk helemaal niet in fstab meer thuis horen (zoals cifs, nfs) worden teruggezet en juist niet de mounts die wél in fstab horen zoals by-uuid of by-label

[delagroov]

...Het kan nl. zijn dat iemand andere bestanden in een plugin plaatst NADAT deze is geïnstalleerd...

Dat mag niet. Van bestanden die uit ipk's komen moet je afblijven.

In Pli zijn toch ook wat aanpassingen gemaakt aan plugins, die officieel als ipk ook anders werken.
Ik denk daarbij bv aan shoutcast. Normaal worden de favorieten in de officiële shoutcast in de plugin-locatie gezet.
In PLi vind je de favorieten terug als ShoutcastFavorites.xml file in etc/enigma2

[delagroov]

Als ik de PLi-AutoBackup.tar.gz via softweerbeheer/geavanceerd herstellen nogmaals terug zet, worden de MQB.xml files wel alsnog overschreven.

Het zij zo...

Al met al is de nieuwe backup/restore methode na wat goed inlezen wel een mooie ontwikkeling.

[MiLo]

Het is geen bug in MQB daar is bewust voor gekozen.

Als MQB bewust ervoor gekozen heeft om de configuratie van de gebruiker te verwijderen tijdens een upgrade, dan is dat geen bug. Mooi zo, dan hoeft die ook niet opgelost te worden.

Wat er mis gaat met fstab is dat alleen mounts, die eigenlijk helemaal niet in fstab meer thuis horen (zoals cifs, nfs) worden teruggezet en juist niet de mounts die wél in fstab horen zoals by-uuid of by-label

Dat gaat niet mis, hij doet gewoon wat iemand een paar jaar geleden voor een 7025 (met devfs) heeft bedacht. Misschien moet je een leuk voorstel indienen, liefst in de vorm van een patch, want mounts managen met UUIDs klinkt wel al een nuttige feature.

[ni_hao]

Als MQB bewust ervoor gekozen heeft om de configuratie van de gebruiker te verwijderen tijdens een upgrade

Wat voor upgrade bedoel je. Tijdens een upgrade van de MQB plugin wordt de configuratie van de gebruiker niet aangetast. De configuratie van de gebruiker staat immers in de MQB map onder /etc, terwijl de ipk van MQB alleen maar effect heeft op bepaalde mappen onder /usr. Als je een image opnieuw flasht zul je inderdaad MQB opnieuw moeten configureren daar is die herstel en backup-functie voor in MQB.

Wat er mis gaat met fstab is dat alleen mounts, die eigenlijk helemaal niet in fstab meer thuis horen (zoals cifs, nfs) worden teruggezet en juist niet de mounts die wél in fstab horen zoals by-uuid of by-label

Dat gaat niet mis, hij doet gewoon wat iemand een paar jaar geleden voor een 7025 (met devfs) heeft bedacht. Misschien moet je een leuk voorstel indienen, liefst in de vorm van een patch, want mounts managen met UUIDs klinkt wel al een nuttige feature.

Er wordt vastgehouden aan iets wat een paar jaar geleden actueel was en al een behoorlijke tijd is achterhaald en wat volgens mij bovendien niet erg slim is (gelet op de optie en de uitwerking van verbindingsbeheer via het menu). Als je het niet weet dan is het nog tot daar aan toe, maar ik heb hier in dit draadje al eerder geschreven over mounten via o.a. uuid, fstab en automounts.xml maar als niemand reageert dan is er kennelijk geen interesse (zelfs niet informatief). Bovendien is er genoeg te vinden over mounten by-uuid en by-label. En een patch hoeft er niet geschreven te worden, gewoon hetgeen nu is vermeld over fstab uit de batch file halen en het hele bestand fstab als backup terugzetten of anders in de batch file de woorden "nfs cifs swap" te vervangen door "UUID LABEL" (eventueel swap er aan toevoegen als dat zou moeten maar met de huidge enigma2 OE is het echt niet meer noodzakelijk een swapfile te hebben).

[VU+NL]

Er wordt vastgehouden aan iets wat een paar jaar geleden actueel was en al een behoorlijke tijd is achterhaald en wat volgens mij bovendien niet erg slim is (gelet op de optie en de uitwerking van verbindingsbeheer via het menu).

Ik heb het al een paar maal eerder geschreven: mounten via het menu gaat absoluut niet; via fstab lukt dat wel prima (ik heb het over de DUO).

[ni_hao]

Wellicht beter om een apart draadje te maken over mounten e.d. Ik zal eens kijken of ik in de loop v.d. dag daar een begin mee kan maken.

[MiLo]

... maar als niemand reageert dan is er kennelijk geen interesse...

Misschien moet je je voorstel wat beter aankleden. Stukjes code, een voorbeeld van je fstab, wat je wil bereiken, enzovoorts.