Beta 6.3 ist jetzt verfügbar und da sollten die meisten bugs wieder draussen sein, es ist also eine Version die auch wieder für normaluser geeignet ist.

gruss
thowi

Multiboot kann dir auch eine gross genuge ganze Imagepartition auf der Harddisk machen, aber das ist nicht wirklich die beste Lösung meines Erachtens nach wie schon in der vorherigen reply ausgeführt.

Aber jetzt freuen wir uns erstmals das es überhaupt geht !

Gruss
thowi

na ja das aktuellste Multiboot 6.3 findest Du im I*D Board (wo man auch Träume hat und Images herkommen die mit Blue screen booten über die hier nicht gesprochen wird) oder in fast jedem Dreamboard gibts in der 7025er section entsprechende Downloads dafür bis uns musicbob erlöst (?!)

Vorteil ist relativ einfach:

Wenn das Image auf der Cf Karte liegt braucht die Harddisk nicht ständig laufen, schneller ist es dadurch auch, und wenn mans am laufen hat kann mans entsprechen sichern durch wegkopieren des ganzen images, sprich wenn man neue Versionen, plugins, settings, skinns ausprobiert kann man schnell wieder zurück ohne neu zu flashen.

Und das Limit vom Flash ist dann natürlich auch weg, und weil du dadurch memory sparst (kein jffs2 vom Flash) hast du auch mehr zum Complieren zur verfügung (wirs sehen was passiert wenn du was großes compilierst - willkommen swapfile !)

Und mehrere Images ausprobieren und booten kann man dann natürlich auch.

PS: Und den link zu deinen ipk files solltest du auch dort im Board gleich posten (z.B. e2 plugin section), ich denke da hätten auch andere viel Freude damit.

Gruss
thowi

Oder du machst mit Multiboot 6.3 eine bis zu 512MB grosse Imagepartition in der Du es installierst und hast dann genug (!) Platz auf /usr/local

PS: Ich wußte doch das das Feature zu was gut sein würde Image Partitionen für Multiboot in fast beliebiger Größe zu machen

PPS: Jetzt muss ich auch noch meine alten c Programme rauskrammen um zu testen, aber neue Spielzeuge sind immer wilkommen, also nochmals DANKE !

Gruss
thowi

Zitat

Original von murks
@thowl

as i can see, the colo is very cobalt specific.. hardware support is for example only for tulip based network devices, the same for filesystems, only ext2 is supported.

Yes I've seen this, but for an Image partition typically only 50-60MB big ext2 is not a real limitation or problem.

And off course it is Cobalt speficif, but on this old MIPS box they had to overcome exactly the same problems - limits of existing bootloader and no chance to get a better one !

Hence it had to be done in a way which would be also usable for the dreambox - fake vmlinux.gz which then daisy chaines to the real one.

And at least it supported a MIPS architecturye (meaning that the cross compiler would not run away screaming if we feed him the source code)

I would also need only a minimal build without any network drivers (which would be hardware specific), etc. so this should be calculatable effort. And the IDE driver (which would then support harddisk and CF card already) very likely to work without any real changes on a dreambox !

And I didn't say that it is the solution, I just wanted to point in directions which maybe were not investigated yet (and belive me, sometimes I have really strange ideas - I'm not sharing half of them, but as long as there are a few working ones who cares)

And a clever person once said 'there are no dumb ideas'

And the process to solve a problem is quite simple - try to find ALL possible/thinkable solutions and then eleminate the ones that are NOT working until you find one that IS working.

Sitting together and complaining that it doesn't work ist not part of this process (unless you wanna be sure to fail)

PS: Feedback is welcome, so don't think that I'm upset - and belive me most of my good ideas I stole from other people who didn't realize what nuggets they had in their hands.

Ciao
thowi

and one more thing I forgot to mention:

when I asked the grub question I also did an extensive search on bootloaders for mips plattforms and found this, which might also look promising:

CoLo Bootloader for mips - looks like it is a simple vmlinux.gz replacement, hence standard bootloader should be able to work with it.

http://www.linux-mips.org/wiki/CoLo

http://www.colonel-panic.org/cobalt-mips/

Unfortunately in German:

http://www.gentoo.org/doc/de/h…ml?full=1&style=printable

Setting up colo for NFS looks promising:

# tar -xzvf colo-1.XX.tar.gz
# cd colo-1.XX/binaries

(Für Qube 2800, RaQ2, etc)
# gzip -9vc colo-chain.elf > /nfsroot/vmlinux_raq-2800.gz

(Für RaQ1, Qube 2700)
# gzip -9vc colo-chain.elf > /nfsroot/vmlinux.gz
# cd /nfsroot
# ln . boot

And i liked the scripting capabilities for boot menus and chainloading from existing firmware feature ...

Ciao
thowi

well you are thinking too complicated - I just want to save the 4 different configs (boot from flash, and alternate 1,2,3) with the standard bootloader as it offers already now and then just dump the saved konfigs. By writing it back (even without knowing/decrypting the content) I could then choose which bootpaths are taken and prevent the telnet session.

So there is not really a need to write access routines which do read/write and decryption (I would have assumed that bootloader config is protected, because if you screw it up you are in deep problems).

The whole thing would be easier if we could only extend the bootloader a little bit (probably half a page of code - so that it switches the alternate bootsource by pressing the up and down buttons - not as nice as doing it with remote controll, but sufficient, and perfect if LCD would show booting X...). It is a little bit like your request for extending it to USB support - would be great, but lots of effort, just use the kernel in Flash and ignore the root in flash and use the root on USB stick does the job too - I like workarounds you know

But if I'm able to manipulate the loader's config then I'm already pretty close, because if I switch it to load a dummy kernel (miniroot ?) which does then the manipulation I would get more or less the wanted result.

So thanks for your input, I'll do some medidation on it.

Ciao
thowi

PS: And that you get an idea what crazy approaches are possible, here are 2 more:

I just thought about a PC programm which allows you to script Terminal character sequenzes (such programms are alreay available) - whith this you would be able to make a PC Bootloader raping the standard one which just manipulates as you would do in Telnet already now, but this needs still pressing of the up button - hence not really usable for normal usage.

Or another one - why not specifing a device list in /autoexec.bat or autorun.bat and then patch the linux kernel that before it mounts the root filesystem so that it waits 30secs (like it does for USB with the rootdelay parameter). Finding the place where this USB boot rootdelay patch is built into the kernel would be relatively easy (should be in changelog), and exactly there you could add code to the kernel to choose an alternate root from the list ! Actually this one would be nice, because when having a full kernel running you have all the drivers needed for LCD, button events,... and then you simply continue boot as normal. I even already tried if an entry in autorun.bat like this works and the kernle still boots (with the first device of the list):

root=/dev/hdc2,/dev/hdc3,/dev/hdc4

And I have some more ideas on how to solve this problem, but I need an easy one (because I'm not willing to code something in the kernel - even when this would be c code which I could probably handle)

English is below

Hallo Leute !

Erinnert Ihr Euch an meinen grub für DM 7025 Frage thread ?

Na ja, ich habe immer noch nicht aufgegeben einen booloader für meherere Images zum auswählen währen dem booten zu machen
(und bis jetzt habe ich IMMER einen weg gefunden wenn ich etwas wirklich wollte). Und weils FEZ immer noch nicht gibt ist es noch auf meiner To-Do Liste.

Eine der Meditationen in meinem Urlaub war ja über USB boot support - na ja und jetzt geht es (mit ein bischen Hilfe ...)

Und der Stadnard bootloader is gar nicht so schlecht nur das menu interface in telnet wenn man den boot stopped (mit Up taste beim Einschalten) um zu flashen ist für normaluser nicht geeignet.

Andererseits kann erschon bis zu 3 Images booten, also warum nicht versuchen dieses feature zu verwenden - nur halt auf meine weise ?

Könnte mir daher jemand eine Hinweis geben wo er seine Konfig speichert ?

Wenn man diesen Bereich manipulieren könnte wäre es mit einem kleinen Programm (wenn gebootet oder halb gebootet) möglich Ihm zu sagen was und wo er booten soll (so wie multiboot es mahct wenn es autorun.bat ändert, nur eben 1 ebene weiter unten).

Wahrscheinlich ist es eh nur 1 block oder sector im flash (der letzte von /dev/mtdblock/1 ?) weil secondstage.gz füllt den nicht ganz, und wenn man es mit dd zero padded drüberkopiert hat man wieder die defaulteinstellungen selbst wenn man vorher andere gespeicher hat.

Also tipps, ideen und Vorschläge sind willkommen !

Gruss
thowi

Hello Folks !

Remember my grub for DM7025 - question ?

Well, I still have not given up to implement a bootloader for choosing multiple images during boot on the DM7025 (and so far I always found a way to do something if i really wanted to do it). And because FWZ is still not there it is still on my to-do list.

One of the meditations I had during my vacation was on the USB boot - and well we now have it don't we (with a little help ...)

And the standard bootloader isn't that bad either, only the menu interface working only in telnet if Stopped (with up button during turn on) is not acceptable for the normal user.

But it offers already the possibility to specify and boot up to 3 Images, so why not raping it to do this - only the thowi way

Could therefore somebody give me a hint where and how it actually stores its config when you do a save and reboot within the bootloader ?

By manipulating this flash section we could achieve what we want with a VERY small programm or from the booted or halfbooted box (like multiboot does by manipulating the autorun.bat, only 1 level deeper).

Probably it s only a single block or sector, but it must be reserved in /dev/mtdblock/1 as would be my assumption (last block ?) because secondstage.gz isn't filling it completely, and if I copy it with dd to the /dev/mtdblock zero padded it comes up with the default values, even when I saved others before.

So any hint or ideas are welcome !

Ciao
thowi

Zitat

Original von sharky1000
Hi freaks,

irgendwie komme ich mit den Anleitungen nicht klar.

Mein Ziel: Programmierung der Timereinträge mittels tvbrowser.org.

Ich habe ER60 und vorsichtshalber den crownmanger über bluepanel installiert (obwohl ich den mit der neuen Version nicht brauche.)

Anschließend habe ich ER aufgerufen und festgestellt, dass der Mediaserver läuft.

Bei System Time, cron daemon is using habe ich fesgestellt, dass hier die aktuelle Zeit - 2 Stunden eingetragen ist.

Deshalb habe ich bei UTC die Zahl 2 eingegeben. Muss man hier 2h, wie in der Anleitung erwähnt eingeben?

Die install options habe ich auf enable ER and Mediaserver daemon gestellt.

Bei den Manual komme ich an verschiedenen Stellen nicht klar.

Was z.B. sind Standard Favorites? Ist damit der Ordner Favoriten gemeint? oder der Ordner Favourites (TV) ?
Versuchsweise habe ich über telnet /etc/rc3.d/S22mediaserver restart
eingegeben und bekam ich die Antwort: Restarting Mediaserver done, was soweit positiv verlief.

Leider finde ich die Datei /etc/enigma2/record.sh nicht.

Sie wurde bei mir nicht angelegt.

Leider bekomme ich, wenn ich mit http://myDreamIP/ bzw. http://myDreamIP/TVBrowserTimerEvent.py auf die Box gehe, nur eine leere Initernetseite im IE und Firefox angezeigt

Den gehackten Webserver von 3c5x9 habe ich im Pluginbrowser nicht gefunden. Daher konnte ich mir auch nichts damit ansehen.

Mit der wiki von tvbrowser.org kam ich leider auch nicht klar.

Wäre cool, wenn mir jemand helfen könnte.

Have fun
Sharky1000

Edit:
Zwischenzeitlich komme ich mit http://myDreamIP/ auf meine Box.

Wo bekomme, bzw. finde ich auf den Wiki die Anleitung für das Enigma2 CapturePlugin?

Alles anzeigen

Du bist eh schon werit gekommen.

1) mit dem browser einfach die IP der Dreambox eingeben, DANN komsmt du auf das WebIF, nicht die TvBrowserTimers.py, die wird NUR vom TVbrowser mit allen nötigen Parametern aufgerufen wenn du einen Timer erstellst oder löscht, sonst kann der Mediasever damit nicht annfagen da die parameter fehlen (start/endzeit,...)

2) Du mußt wissen wie man mit der Filmklappe einen Timer im TVbrowser für das Gerät DM 7025 anlegt, sonst wird sich gar nichts tun, nur dann wird der Mediaserver aktiv.

3) Mediaserver wird bei ER60 mitinstalliert und dessen start/stop ist dort in den menus dabei, also KEIn eigenes Plugin.

4) Liest nochmals das Wiki vom tvbrowser wie man für die alten boxen aus der Liste mit Knälen und sendungen eine Aufnahme programmiert und wenn du das machst schau im Telnet was dein Mediaserver tut !
Und nicht vergessen die richtige IP deiner box eintragen sonst geht der Webrequest vom tvbrowser in den Wald.

5) die record.sh ist ein fehler im readme,txt es gibt nur mehr das *Timers*.py und das file gibst schon im /usr/lib/enigma2/python/Plugins/Extensions/Mediaserver*....

Es wird schon werden, du bist eh schon ziemlich weit. Nur den cronmanager brauchst du nichtmehr (ausser du willst dir das restart asl root im Telnet ersparen, aber zuerst muss es mal ohne cron gehen !)

Ausserdem probier ecvt. mal zuerst das timerprogrammieren übers WebIF aus, und wenn du verstanden hast wie das geht und es auch funktioniert, dann erst den tvbrowser anwerfen, der hat nur ein hübscheres gui greift aber auf die selben scripts zu weil das *timers*.py ist nur ein leeres dummy um kompatible zum alten enigma1 webif zu sein.

Gruss
thowi

na ja einen compile Befehl über dei FB abzusetzen wäre schon etwas pervers.

Ich hatte eher dran gedacht das man mit dem Plugin das ganze runterlädt, auspackt wo man möchte (harddisk, Multiboot Exchange Partion,...) entsprechend verlinked (oder vermountet wenn es Dir lieber ist). Die ganzen Pfad und environmentvariablen anpasst,...).

Dann muss wohl wer ein ipkg draus bauen,... (was ich mir eh schon länger anschauen wollte, und bei einer Entwicklungsumgebung wären die Dependencies schon recht heftig,...)

Aber mir ist schon klar das ein Entwickler der weis was er tut das alles gar nicht braucht

Aber eines habe ich aus so Sachen wie dem Cronmanager plugin gelernt - solange du es nicht hübsch verpackst benützt es keiner, und deswegen habe ich ja auch z.B. begonnen das automount plugin zu entwicklen (und blöde mount Befehle müßte doch wirklich jeder hinkriegen, oder ?).

Gruss
thowi

Im Multiboot 6* gibt es jetzt ein Multiboot Exchange directory das auf Harddisk, USB oder per default auf CF Karte liegen kann und je nach vorhandenem Platz auch beliebig gross sein kann. Die Idee ist das man dort auch schön Plugins, sowie Sachen die aus der Ornithologie stammen hinlegen kann und diese dann entsprechend verlinken - also für die plugins ein /media/mbX/Extensions das dann von /usr/lib/python/Plugins/Extensions verlinked wird.

Man sollte das aber nur für sachen machen die wenn sie dann im Image fehlen (z.B. CF Karte draussen) keine negativen auswirkungen haben.

Eine ganze Entwicklungsumgebung (Compiler, Libraries, *.h files,...) die man dann mit einem Link von dort ins Image einbinden könnte hätte dann schon seinen Reiz. Und ich würde auch gerne ein kleines Compiler Plugin basteln damit man es komfortabler beim installieren und verwenden des Ganzen hat.

Also bastle mal schön weiter, ich hätte auch gute Verwendung dafür
....

PS: Sachen auf die Festplatte legen ist zwar immer der kleinste gemeinsame Nenner und auch OK, aber es geht eben auch hübscher.

Gruss
thowi

Haue Multiboot auf die box, entpacke das image auf die CF karte und dann kopierst von hand zurück (cp /media/mb1/...filename /.../filename wenn es in Partition 1 ist)

Ich mach das ständig um "Sachen" zwischen Images hin und herzukopieren.

Und wenn du nachher multiboto disable ist ists wieder weg.

Nur eine CF Karte und USB stick wirst du halt benötigen.

Ansonsten gibts die scripts und tools von tmbinc und noggie die das können (in der OpenEmbedded section), die gibts auch in einer PC Linux Variante.

Gruss
thowi

wie im anderen thread schon gesagt multiboot kann das !

wenn Du multiboot installierst kannst Du neue .nfi images auf die box schieben (auch in den Flash wenn nicht davon gebootet) nur vom telnet aus (ich entwickle und teste das Ganze Multiboot ja auch so, das GUI kommt imemr erst ganz am Schluß dran)

Sonst gibts auser den scripts von noggie und tmbinc keine andere Möglichkeit (wobei multiboot im prinzip das selbe macht, nur eben in jede Richtung für bis zu 12 Images und nicht nur 1 Image auf CF Karte)

Gruss
thowi

du musst schon die suchfunktion bemühen und den originalthread finden (und ich bin nicht mal 100% sicher obs in diesem Board war), aber es war für privatgebrauch und kein downloadlink dabei, du müßtest also in den bettelmodus gehen ...

Probiers mal mit compiling on dreambox suchen, oder ähnlichem.

Thanks for finding this explaination, at the moment I use Partition 1 and 3 as primary (for normale /media/usb and my exchange Partition created for multiboot things to be shared between images) and an extended with theup to 12 logical partitions bin between.

So I'll simply reduce for USB the maximum Multiboot Partitions to 10 so that I have a spare one - you never know what it is good for

BTW, the whole USB drivers stuff still is a little bit wild in my understanding and test results so far.

I have an USB stick not working at all (but can be formated on PC with windows and linux without problems), another one works only on an USB hub but not really when attached to the box directly,...

So some testers are really suffering to see what is working and at the moment I'm stil holding out my hat (again) so that somebody builds a complete CSV Image with a kernel linked with the USB drivers, so that it is easier and more stable to begin multibooting on USB.

But this is what I volunteered for when I asked for it, let's see where this journey brings us.

Thanks a lot so far, and as a small thank You I created the first versions of the promised automount plugin already.

Ciao
thowi

genau deswegen sollst du ja im telnet den Mediaserver restarten mit

/etc/rc3.d/S*Mediaserver restart

dann siehst du die webrequests (falls sie ankommen) !

Gruss
thowi

so, here's you girl back noggie !

Sorry that the readme ist German only at the moment, but 80% is a
short description of automount and autofs which you can easily find with Google in English too or by reading the man pages.

At the moment the kit is just including the basic stuff, and if you enable it in the menu interface or with the automount.sh script
then it will install the needed stuff on your box, patch the startup script so that it runs on the Dreambox and then you can start/stop/restart/reload the dameon with the menu interface similar to my cronmanager plugin.

Adding a single samba and cifs mountpoint to auto.misc is included in the plugin, but untested.

But the /misc and /net examples seem to work (well at least they are shown if you enter mount as autofs).

So I now would need inputs from people using samba and/or nfs or CD/DVD devices which are willing to play with the plugin and create appropiate config files for it, so that I then can use these as templates
for adding appropiate menu interfaces to create them interactively
(cifs and samba is hence untested).

So I hope this is usefull stuff for people who are used to work with automount/autofs and are willing now to contribute their know-how.

Was not too difficult, so let's see what people can do with this on their Dreambox !

Ciao
thowi

Keine echte Hilfe, ich weis aber ...

Jemand hat sich schon eine komplette Entwicklungsumegbung auf der Dream gebaut zum Compilieren und Linken, du müßtest also nicht das Rad neu erfinden.

Das Ganze würde mich zwar auch interessieren, aber ohne die ganzen libraries zum linken wird das nicht viel bringen und dann wird das image wohl so gross das du es nur mehr auf einer Multiboot Partition auf CF Karte auspacken kannst (na ja die gehen jetzt zwar schon bis zu 500MB groß), oder du mußt die libs wieder über NFS mounten,...

Gruss
thowi

yes, now automount in the ipk package is correctly compiled, Thanks

Regarding kernel module - well I tested also quickly remote (from work) with a non-standard Kernel, so I'll try again over the weekend.

So thank you for the new toy, and I promise to bring it home before midnight

PS: Multiboot 6.26 ist now out where most of the bugs with the USB support were fixed, looking forward what now will happen on the kernel question (to USB or not to USB Shakespeare would say)

Ciao
thowi