19 replies to this topic

[Pedro_Newbie]

Ik zit met een vreemd probleem. In de BackupSuite wordt er een kerneldump gemaakt met het commando

/usr/sbin/nanddump /dev/mtd1 > /tmp/vmlinux.gz

Nu werkt dit ook in 99,9% van de gevallen maar er zijn enige (2) gebruikers op een ET waarbij de dump wel op de juiste wijze wordt gemaakt maar het programma niet afsluit maar blijft hangen en daardoor de back-up ook mislukt/niet verder gaat.
Wordt handmatig in telnet het commando op die machine gestart is er geen vuiltje aan de lucht maar vanuit een script blijft het steevast hangen.
Ook in een simpel testscriptje waarbij alleen het betreffende commando wordt gegeven blijft het geheel hangen na de output op het scherm.

De versie van nanddump is 1.49 en het geheel vindt plaats op een bijgewerkte Openpli 3.0 versie.

Ik weet het, er zijn niet veel aanknopingspunten maar heeft iemand enig idee wat het probleem zou kunnen zijn?

[Sjaaky]

Geheugen, dus /tmp, vol?

[Erik Slagter]

Ook in een simpel testscriptje waarbij alleen het betreffende commando wordt gegeven blijft het geheel hangen na de output op het scherm.

Dan is het in ieder geval reproduceerbaar.

In een aparte telnet-sessie eens ps doen en dmesg?

[Pedro_Newbie]

Dat is een beetje het probleem, het zijn geen ervaren gebruikers dus dat wordt een beetje moeilijk. De gebruiker heeft nu weer een vastloper, ik denk dat opnieuw flashen misschien de enige oplossing is.
Een andere gebruiker met datzelfde probleem had ook opnieuw geflasht maar dat verhielp het probleem niet.

Blijft lastig om op afstand iets te kunnen doen. Ik zal even afwachten of hij weer leven in zijn ET krijgt.

[Rob van der Does]

Geheugen, dus /tmp, vol?

Dat zou heel goed kunnen: het maken van een backup kost veel geheugen. Het gebruik van de cache-flush plugin en/of het (tijdelijke) gebruik van een swap-file zouden het proberen waard kunnen zijn.

[Pedro_Newbie]

Het vreemde is dat hij 2 nagenoeg identieke machines heeft, bij de een werkt het wel en bij de ander niet. Als hij een back-up terugzet van de werkende machine op de niet werkende en dan daarvan dan weer een back-up wil maken loopt het ook weer vast.
IK zal hem de cache-flush plugin eens aanraden om te testen

[Rob van der Does]

Het vreemde is dat hij 2 nagenoeg identieke machines heeft, bij de een werkt het wel en bij de ander niet. Als hij een back-up terugzet van de werkende machine op de niet werkende en dan daarvan dan weer een back-up wil maken loopt het ook weer vast.
IK zal hem de cache-flush plugin eens aanraden om te testen

Inderdaad vreemd.
Cache flush is natuurlijk wel heel simpel om te proberen: beschikbaar via de feeds. Wel het slachtoffer even vertellen een flush uit te voeren direct voor de backup.

[Sjaaky]

Werkt het als de dump naar USB gemaakt wordt ipv /tmp?

[Pedro_Newbie]

Nee dat werkt ook niet, standaard wordt die dump in de backupsuite gemaakt naar het medium waarop de backup gemaakt wordt, dus op HDD of USB. Het dumpen naar /tmp/ was even om te testen aangezien die toch weer leeg is na een reboot.
Maar die kerneldump is maar 6 MB groot dus dat lijkt mij toch niet zo'n probleem, het vreemde is die dump wordt wel gemaakt maar op de een of andere manier wordt nanddump niet juist afgesloten / helemaal niet afgesloten.

[Erik Slagter]

Dat is een beetje het probleem, het zijn geen ervaren gebruikers dus dat wordt een beetje moeilijk. De gebruiker heeft nu weer een vastloper,

Hmm dat is jammer, want een strace zit er dan ook niet in

[MiLo]

Hoe start je het script? Met os.system, popen of een eConsole? De eerste twee hebben vaak rare memory problemen, alleen de eConsole is betrouwbaar.

[Pedro_Newbie]

De normale backupsuite wordt gestart vanuit de plugin met

def runbackup(session, result):
	if result:
		session.open(Console, title = _("Full back-up on HDD"),cmdlist = [_("sh '/usr/lib/enigma2/python/Plugins/Extensions/BackupSuite-HDD/backup.sh' en_EN")])

en vanuit de backup.sh wordt backupsuite.sh aangeroepen/gestart.

Het testscriptje is een een simpel script met de volgende inhoud

#
#  TEST
#!/bin/sh

echo "Version 2" > /tmp/test.log
/usr/sbin/nanddump /dev/mtd1 > /tmp/test1.gz
if [ -f /tmp/test1.gz ] ; then
	echo "test1.gz made" >> /tmp/test.log
	ls -e1 /tmp/test1.gz >> /tmp/test.log
else
	echo "/tmp/test1.gz NOT FOUND"  >> /tmp/test.log
fi

en gestart vanuit telnet.
De dump wordt gemaakt en is ook compleet maar dan houdt het op, het script komt niet toe aan het testen of het bestand bestaat.

Ook na een verse flash met niets anders geïnstalleerd dan de BackupSuite loopt het dumpen van de kernel ook vast terwijl het voorheen geen enkel probleem was.
Het is geen uitgebreid probleem maar enige gebruikers hebben hier last van, ik heb alleen geen gemeenschappelijke dingen kunnen vinden die het zouden kunnen verklaren.

[cobus]

Misschien een rare opmerking maar is er niet iets mis met die ontvangers want er zijn er vele wie jou backup plugin gebruiken en 2 daarvan hebben deze problemen dat is toch te weinig om van een fout uit te gaan omtrent jou plugin ?

[Pedro_Newbie]

Het zou best kunnen dat er iets mis mee is en ik geloof ook dat er aan de plugin niet veel zal mankeren, buiten een wat houtje touwtje "programmeerwerk" geheel tot stand gekomen door niet gehinderd te worden door enige kennis , maar ik zou wel graag de oorzaak willen achterhalen voor het geval het zich weer eens voordoet.
Maar gezien het gegeven dat ook in een heel klein scriptje het programma ook niet tot een goed einde komt vrees ik dat er er toch iets meer aan de hand is dan alleen geheugengebrek.
Dit kreeg ik net door over de box, afkomstig uit de webif:

Brand: Xtrend
Model: et9000
Chipset: bcm7405
Frontprocessor Version: None
Total Memory: 290984 kB
Free Memory: 191196 kB
Box Uptime: 2:12

[pieterg]

wellicht geeft nanddump een melding over een bad block wat geskipped wordt, waardoor het script gaat hangen?

(een paar procent van de flash blocks mogen 'bad' zijn, dus er kunnen er altijd een paar toevallig in de kernel partitie zitten)

[Pedro_Newbie]

Nee geen meldingen over bad blocks zoals je op deze screenshot kunt zien

[nakah47]

hoi pedro,


Heb je ook backup script for DM800se and DM500 HD for OE2 softwares ( zogenoemde Open PLI 3.0), ik kan nergens vinden ook niet eens voor Open pli 2.1 , maar die had ik opgelost van TS panel daar stond wel in tools een backupscript en werkte prima, maar Open PLI 3.0 softwares zijn OE2,0 = Python 2.7 , dus zou die backup script niet werken, ik kan niet een TS panel toevoegen Open PLI 3.0 softwares, dus aub hulp ik wil graag volledige back up maken van beide boxen

Grtjes

[nakah47]

cables.xml moet je negeren, die wordt niet gebruikt.

Gewoon cablescan gebruiken, die vind je in het tuners (service searching?) menu als je een dvb-c tuner hebt.

Nee geen meldingen over bad blocks zoals je op deze screenshot kunt zien





hoi pedro,


Heb je ook backup script for DM800se and DM500 HD for OE2 softwares ( zogenoemde Open PLI 3.0), ik kan nergens vinden ook niet eens voor Open pli 2.1 , maar die had ik opgelost van TS panel daar stond wel in tools een backupscript en werkte prima, maar Open PLI 3.0 softwares zijn OE2,0 = Python 2.7 , dus zou die backup script niet werken, ik kan niet een TS panel toevoegen Open PLI 3.0 softwares, dus aub hulp ik wil graag volledige back up maken van beide boxen

Grtjes

Edited by nakah47, 26 January 2013 - 01:54.

[Pedro_Newbie]

Kijk eens in deze POSTdaar vind je de plugin dflash voor de dreamboxen, misschien dat het dan wel lukt.

[nakah47]

Hallo Kerel,


Ga ik zeker proberen en laat ik je weten ,


Grtjes,

Heb je ook enige idee over die kabel scan probleem? Als ik kabel scan in Ziggo gebied doet

deze opties

Offiecel lijst: Nee
HD lijst : Ja

Dan maakt die mooei boueqet met HD zenders boven op,

Nederland 1 HD
Nederland 2 HD
Nederland 3 HD

maar als ik met zelftde opties in UPC gebied kabel scan doet dan maakt ie ook een mooei bouqet maar dan boven op eerst SD zenders

BIjvoorbeeld

Nederland 1
Nederland 2
Nederland 3

enige ideaa , ik ben even plug in kabel scan ingekeken maar ik zag niks bijzonder behalve die sysmbol rate van UPC 6900 stond niet erin