Just some quick feedback until the weekend starts:

Kernel module doesn't load - Device or resource busy error (-1) - But I have to try with a current CSV image first.

ipk file contains autoumoun finary too - but this seems to be still compiled for Intel - typical Synatx error ( expected

So we need some more work here ...

Ciao
thowi

Zitat

Original von noggie
If getting a copy of automount keeps you from boredom during the week-end, then I feel it's almost a duty to keep up your supply of new toys...

Although it kinda makes me feel like a drug-pusher

Please find attached autofs (I assume this is the automounter you wanted?) and the kernel module that you will also need. Not tested at all. autofs4.ko comes from enabling CONFIG_AUTOFS4_FS as a module in kernel .config, while the user-land daemon is straight out of OpenEmbedded (bitbake autofs).

That's going too far, I think. The autofs daemon has it's own config file, it's not using /etc/fstab, and you would need a proper mount command (not the poor excuse that busybox provides, although even busybox is gradually improving) for the fstab file to be correctly interpreted.

P.S. Why don't you install Linux and OpenEmbedded on your PC? OpenEmbedded would give you literally thousands of packages to play with, just by "bitbake <package_name>" and installing the resulting ipk file.... You'd never be bored again

Alles anzeigen

Thanks noggie - and regarding your worries- drug dealers give you only the first shot for free.

Yes, autofs ist the binary I was looking for - let's see how far I can get with it.

And regarding the auto in fstab - I know that autofs has it's own config file and everything - this is why I think a plugin would be needed so that people can easily place their (PC) mountpoints into it.

The meaning for auto in fstab was actually a joke, because it is more try once and then forget it at the moment.

And regarding the OpenEmbedded - well I know that it is not so difficult, but It is a little bit like when you are a child - if papa brings a present home in the evening it is MUCH more fun then if you grow up and have to buy it yourself

PS: I added some comments about the maxdevice problem I found with my USB stick - see the vmlinux.gz with USB topic for details - any idea if I could be right ?
Ciao
thowi

one more question:

could it be that the USB device driver doesn't allow more then 15 partitions per device, or that it has a bug ?

Standard multiboot layout on USB is to have 1 primary partition for /media/usb at the beginning (part1) and 1 primary Partition for /media/mbX at the end (part3) and the second partition (part2) contains up to 12 logical partitions. Strange thing ist that with fdisk I can create all 12 logical paritions, but in the /dev/scsi directory only the device file up to part15 shows up, part 16 is always missing. But fdisk doesn't give an error.

ls in /dev/scsi... directory:

disc
part1
part10
part11
part12
part13
part14
part15
part2
part3
part5
part6
part7
part8
part9

fidisk output:

Disk disc: 1030 MB, 1030750208 bytes
16 heads, 32 sectors/track, 3932 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

Device Boot Start End Blocks Id System
part1 * 1 58 14832 83 Linux
part2 59 3809 960256 5 Extended
part3 3810 3932 31488 83 Linux
part5 59 364 78320 83 Linux
part6 365 670 78320 83 Linux
part7 671 976 78320 83 Linux
part8 977 1282 78320 83 Linux
part9 1283 1588 78320 83 Linux
part10 1589 1894 78320 83 Linux
part11 1895 2200 78320 83 Linux
part12 2201 2506 78320 83 Linux
part13 2507 2812 78320 83 Linux
part14 2813 3118 78320 83 Linux
part15 3119 3424 78320 83 Linux
part16 3425 3730 78320 83 Linux

This is a standard image with USB drivers loaded (not with USB linked kerne yet)

Strange, isn't it ?

Input is welcome

----- EDIT

I also medidated on this problem - could it be that the driver is OK (hence fdisk works), but the kernel simply runs out of devices
(16 for CF + 16 for USB + standard Devices) - eg could it be that there is a kernel parameter maxedv or something with is set to something like 64 and hence the device file cann't be created anymore because running out of device kernel slots ?

Probabyl nobody created so many disk devices before so it could be taht I simply run into such a limitation) - then would it be possible to inclrease this kernel parameter for the Kernel built with USB drivers included to 96 or 128.

----------- EDIT

Ciao
thowi

Hallo Leute !

nachdem ich es geschafft habe vom USB stick zu booten ist mir ein bischen fad (nur das multiboot zu debuggen ist nicht wirklich seligmachend) und das Wochenende naht ...

Nach kurzer medidation über die verschiedenen Wünsche nach einen USB/PC/NFS mount plugin habe ich mir gedacht anstatt das Rad neu zu erfinden wäre es doch gescheiter den automaount daemon auf der DM 7025 zum Laufen zu bringen.

Dann hätte wenigstens das auto feld in der fstab einen Bedeutung

Habt Ihr Feedback zu dieser idee - und wie üblich kann jemand den automount daemon für mich aus dem CSV bauen?

Ich melde mich freiwillig es dann zum laufen zu bringen und evt ein Plugin draus zu machen, bzw. es beim cronmanager plugin dazuzutun.

Ansonsten muss ich mich wieder mit dem lirc daemon spielen, auch interessant, aber neues Spielzeug das die Leute glücklicher macht ist immer hübscher.

Gruss & Danke im voraus
thowi
------------------------------------------------------------------------------
Hello folks !

After I managed to get the USB Stick booting I'm a little bit bored (just debugging multiboot is not really a way to happiness), and the weekend is close ...

So after some medidation on the various wishes for USB/PC/NFS Mount Plugins I think instead of re-inventing the wheel for manual mounts it would be better to try to make the automount dameon running on the DM 7025.

Then the auto field in fstab would have a real meaning

Any feedback on this idea, and as usually, could somebody compile it for me from the CSV - I'm volunteering to make a plugin out of it and/or to add it to the cronmanager plugin if I can get it work.

Otherwise I have to play with the lirc dameon again - exiting, but I prefere new toys which would make more users happy.

Thanx in advance
thowi

knapp 4000 codezeilen (shell + python plugin) aber ich denke mal meine Fehlerrate ist 10x so hoch, sonst würden meine tester oft nicht so viel spass haben.

aber nächstes wochenende habe ich zeit zum testen und mir fällt derzeit eh nichts neues ein, also das wird schon werden.

von 6.2 auf 6.2* sollte das update wieder anstandslos funktionieren (werden ja nur die binaries aktualisiert).

Du mußt verstehen das die Multiboot entwicklung entwas anders läuft, es gibt in diesem sinne keine Releases, die user müssen meine bugs selber finden und dann zählt halt die nummer hinten wieder rauf. Wenn ich ein neues feature machen zählt die vorletztte nummer rauf und wenn wir was ganz neues anfangen - wie Partitionlayout für 12 Partitionen dann die erste nummer).

Daher kann es manchmals auch schnell gehen - ich glaube rekord sind 4 versionen and einem tag - aber jedesmal ein bug weniger, also den spass wert.

Solange ich allein progge wird es aber wohl auch nicht ander gehen, ich finden sonst einfach nicht alle fehler, bzw. das testen interessiert mich nicht so wie das proggen.

gruss
thowi

hast du die media/mbX auch gross genug gemacht, bei 6 images auf einer 512 MB karte ist die viel zu klein für umages (nur ca. 10mb),
mann kann sie dann aber immer noch benutzen um 'gewisse' sachen zwischen den images zu sharen (timers, keymaps, und auch interessanteres wie plugins,...)

In diesem falle mußt du das directory auf die Harddisk umlegen

einfache name auswählen, dann L für Link und dann /media/hdd/MB_Images eingeben, dann hast du platz genug.

6.0 hatte neues partitionslayout daher upgrade nur begrenzt möglich (obwohl der bug mit dem enigma crash ist in 6.22 gefixed).

Sobald du genug platz auf MB_Images hat ist auch das runterladen von CSV images aus dem menu, oder 'anderen' images per FTP dort hin kein problem mehr, und dann geht auch das copy targetnummer N

gruss
thowi

Zitat

Original von NightwoLF
Wenn ich dich richtig verstanden habe geht das Booten von USB Stick noch nicht

Wenn du willst kann ich mich auch gerne als Beta Tester dir zur verfügung stellen.

Ich sag aber gleich mal dazu von Linux hab ich kein plan

Ich kann nur testen ob es läuft, fehler bringt oder solche dinge.

Wäre echt supper wenn Booten von USB Stick auch noch gehen würde.

Dann kann ich CF + USB benutzen.

Ob du mir den Link mal per PN schicken kannst den du ein paar beitrage weiter oben angesprochen hast.

Gruss
NightwoLF

Alles anzeigen

So, Multiboot 6.22 kann jetzt als Beta auch vom USB stick booten, aber ich denke wenn du von linux keine Ahnung hast warte noch bis zum Wochenende, dann sollten die Mutigeren meiner User die meisten bugs schon gefunden haben und es halbwegs stabil laufen, und vieleicht gibts bis dahin dann auch images die schon von haus aus USB support im Kernel haben, oder wo die imagebauer entsprechende kernel als option zum testen anbieten.

Gruss
thowi

habe grade wieder damit gespielt und war erfolgreich - Multiboot 6.22 kann jetzt als (holpriges) Beta auch von USB stick booten.

Aber nicht zu viel erwarten, du mußt die images im moment noch mit einen mit den USB drivern gelinkten Kernel dazu vergewaltingen das sie beim booten bereits das root auf der USB Partition erkennen, aber es wird schon - und mit SatButTrues CSVs Images kriegt man es damit auch zum Laufen - auch wenn er mich vieleicht deswegen nicht lieb hat - duck und weg

Gruss
thowi

with a little help of my friends ...

IT IS DONE !

Multiboot BETA 6.22 now allows to have multiboot with USB stick only.

It is a little bit buggy, and I had to rape the flash bootpartition to serve the kernel for the USB Partitons, but it WORKS !

I hope the people will have fun testing it so that we soon have a stable version for all the people who are fond of USB sticks - don't aks me why - probably notstalgia from the old boxes !

Thanx again for your help and support - now it is on the image developers to build their kernels with these options and fix the mounting problems ...

But I think as soon as it is prooven that this way works to get USB boot support there will be lots of testing and developing to iron out these remaining hick-ups.

Ciao
thowi

Well, it was just a long medidation on the problem during my vacation which led me to the conclusion that there must be another way to overcome the problem, and actually you gave me the final missing piece yourself by suggesting another way of building the kernel (even when you had something else in mind), which remembered me of my own kernel builds 10 years ago.

And there it was very important to have all the needed drivers in the makefile, because dynamically loadable drivers where still speculation of some weird programmers or only available in commercial unix (well there were pinguins at that time but they were living in the antarktis)

And yes, it is often not the inventor, it is the guy who makes a usable and sellable product that everybod can use who gets the flowers.

Regarding the timeout and mount problems - well I think booting with debugging otions should give the right clue why and what happens, so this is something clever programmers can find out, and there is always the possibility to run a mount script later in the boot again until this is fixed.

And this are small problem which can be solved on the way by all the volunteering multiboot testers and their inputs.

At the moment I'll simply place the multiboot binaries needed at the moment on the harddisk (and not first USB partition) to overcome this problem for the moment, because as this example prooves if you cann't solve a problem then try to avoid it or go another way.

Ciao
thowi

just a funny effect that I forgot to report in the meantime.

If I boot normally from CF card with your USB linked kernel it doesn't mount the USB devices during boot that I added to fstab (eg. kernel is to slow in loading USB drivers/devices), but after booting I can mount them manually, so it seems to try to early.

BUT if I add a rootdelay=30 the boot is as fast as usally BUT the USB is properly mounted from fstab.

Strange, isn't it ...

But because this is a positive effect without any harm I'll leave it in autorun.bat also if the root is a non-USB device

----------------------------------------------------------------------------------------------------
And I think it is not fair to let you wait any longer on my testresults
---------------------------------------------------------------------------------------------------

YES, with rootdelay=30 it boots also from USB as long as the CF card is present to serve the vmlinux kernel. So with a small CF card (down to 8MB) we already have an USB boot !

It works quite straightforward - it simply takes the 30 sec until the bootbar in LCD start to move and then it goes ...

Why did it take so long to report back - well I tested it not only with the latest DMM standard image but also with some others - showing blue screens on booting And yes, it seems to work there also, as long as the image is not to old and the secondstage bootloader is from the latest CSV (I already added to multiboot how to update seconstage.gz)

The only problem is that even when moving rootdelay to 60 or higher I cann't make these USB bootet images mount the USB from /etc/fstab

But mounting them manually with multiboot info works, so this is not a real problem.

So version 6.2 of Multiboot coming out today as Beta will contain USB Boot support with CF card GREAAAAAAAAAAAAAAAAAAT !

Version 6.3 then will be able to do this also without CF and just USB device, but thiis is painfull to devleop and debug because I have to modify the autoexec.bat in flash and copy there the USB enabled vmlinux.gz. It is not TOO dificult and I'm sure that it will work, because I used the same approach for enableing multiboot on harddisk only installations (but making it run there was also a pain, because it needs serial flash when I do something wrong)

So this version of multiboot will have to wait until next weekend.

Again thanks for your help, and I hope it is OK to package the vmlinux.gz into the Multiboot 6.2 BETA kit, so that others can try and enjoy it also until the image buildes will start to build their vmlinux.gz this way - as a temporary workaround I implemented a copy V in multiboot to update only vmlinux.gz with the USB extended one, but this is not a perfect solution, because all patches adaption of the kernel
the imagebuilders might have done is lost due to this.

Ciao
thowi

Kein problem, auf 512MB CF karte gehen bis zu 6 Images (6x80=480)

multiboot.sh enable c 6

Geht natürlich auch im Menu interface

Und du kriegst als bonus am Ende der CF Karte noch eine ca. 20MB große Multiboot Exchange Partition wo man "sachen" hinlegen kann, wenn du nur 5 Images verwendetst kannst du dort dann auch /MB_Images hinlegen.

Gruss
thowi

ja multiboot seit 6.0 kann bis zu 12 Parttiitonen/Images auf CF Karte (wenn genügend groß), seit 6.1 kann es auch in nfi images exportieren
und mit 6.19 kahm eben der Grundsupport für USB sticks dazu
(damit man Ihn enablen kann und images drauf kopieren, nur was das booten angeht bin ich mit noggies hilfe noch beim testen und probieren)

Mit irgendwas muss ich an meinen Wochenenden ja das Einschlafen verhindern

In der zwischenzeit sollte es auch schon ähnlich stabil wie 5.0 laufen, also ausprobieren wäre sicher wert, allerdingst musst du die CF karte neu disablen/enablen wenn du das neue layout mit bis zu 12 images willst, aber dafür gibt es ein copy A um alle Images die man auf CF Karte hat in ein großes MBA_*tar.bz2 auf /media/hdd zu sichern und nachher zu restoren

Wenn du nur 256MB CF Karte hast bringst aber auch neue features wie nfi export,...

Die aktuellen kits gibts aber nicht hier, sondern in einem anderen board wo man auch dreamboxen hat ...

Gruss
thowi

na ja mit meinem Cronmanager Dameon kann man schon zu fixen Zeiten ein shutdown -h now oder ein init 0 im telnet einplanenen (ist sogar als Beispielscript beim cronmanager dabei, nur mit den Aufnahmen wird es dann nichts weil das ist dann kein Deep Standby)

Und im Prinzip könntest Du das schon auch über mein gehacktes WebIF (der Notaufnahme - such nach er60.zip) ausführen (weil shell/python Befehle kann man damit remote ausführen, du müßtest aber dann trotzdem den cronmanager laufen lassen damit es als root ausgeführt wird) Das ist aber nur was für Bastler, und ich habs eigentlich nur gemacht um die Leute zu ärgern die sagten das geht nicht (so einfach)also wirst Du dich wohl gedulden müssen

Gruss
thowi

na ja, ich habe es damals mit TVbrowser 2.2 unter windows XP mit Java 1.5 (.0_06 bin nicht so sicher ob es seitdem ein update gab ?) getestet und es gab kein Problem.

Der Webserver schickt einfach nur einen leerstring zurück (nichtmal success medlung), also das kann Ihn auch nicht verwirren.

Hast Du auch so wie im readme.txt steht den Mediaserver in Telnet unter root mit /etc/rc3/S22* restart neugestartet, weil sonst läuft er unter nobody und kann das nötige erdo.sh nicht ausführen ?

Mach mal den restart auf der Dreambox und führe im TVbrowser ein einplanen aus, du solltest dann im Telnet die Fehlermedlungen dies Mediaservers kriegen (und bitte nicht einen anderen Wenserver auf der Dream anwerfen wie den aus der busybox oder das Little Apache, die TVBrowser Integration geht nur mit dem gehackten Meidaserver aus dem er60.zip)

Und hast du beim Geräte Einstellungen URL ausgewählt (denke shcon weil dort gehört das http*...* .py hin, aber auch dann im 2. Tab Parameter für aufnehmen und löschen die 2 strings reinkopiert wie im Wiki beschrieben ?

Aufnehmen:

command=add&syear={start_year}&smonth={start_month}&sday={start_day}&shour={start_hour}&smin={start_minute}&eyear={end_year}&emonth={end_month}&eday={end_day}&ehour={end_hour}&emin={end_minute}&channel={urlencode(isset(channel_name_external, channel_name), "utf8")}&descr={urlencode(title, "utf8")}

Löschen:

command=delete&syear={start_year}&smonth={start_month}&sday={start_day}&shour={start_hour}&smin={start_minute}&eyear={end_year}&emonth={end_month}&eday={end_day}&ehour={end_hour}&emin={end_minute}&channel={urlencode(isset(channel_name_external, channel_name), "utf8")}&descr={urlencode(title, "utf8")}

Nur dann wird der Webrequest richtig formatiert losgeschickt und es ist alles drinnen damit der Mediaserver (bz. eigentlich das erdo.sh) was anfangen kann.

Java Probleme sind auf dem PC (weil damit ist TVBrwoser geschrieben), übers web gehen nur normale requests wo im anfragestring alle parameter drinnen sind udn genau den string packt erdo.sh dann aus und editiert damit die timers.xml, mehr steckt da als Hacxk nicht dahinter.

PS: und ein *.tcf file finde ich auf meiner Harddisk nicht, sorry

gruss
thowi

kein Problem, aber das script ist nichts aufregenes, wirklich hübsch wäre es wenn es auf das directory in /dev/scsi warten würde mit fdisk nachsehen ob schon eine Partition drauf angelegt ist, und diese ggf erstellen und mit mkfs.ext3 formatieren.

All diese Funktionalität habe ich (bis auf das warten aufs device) im Multiboot 6.19 eingebaut, also wenn Du Multiboot hast mit CF karten und auf die letzte Version updatest probiere mal ein enable cu

Ausserdem trägt es den USB stick in /etc/fstab ein, was zwar beim booten oft zu früh ist, aber ab dann kannst du den stick mit mount /media/usb aus dem shell script mounten weil der device namen aus dem fstab geholt wird.

Gruss
thowi

I have a small USB hub from Conrad on my Dreambox where I have Joystick (for Dreamboy,...) and the USB sitck attached, and I could add also an USB Keyboard/mouse and DVD or Floppy Device.

All this was tried out with a G*i image (where it is easier to load the appropiate kernel drivers)

So I think I can test even the worst case

But it looks like like the Hub and Joystick are not really slowing down the device recognition in a standard kernel when I do the mod* commands (maybe a few seconds more) ONLY for USB Storage drivers, it slows down significantly (+15-25 secs) only if all drivers are loaded and devices are present (this I already tested some weeks ago).

And this would be a good sign for the bootable kerne with USB support - unless somebody wants to boot root from a CD and includes also these drivers

I think this evening I should have some harder results, but at the moment I'm still suffering and watching console logs via the com port - but this is why I asked for this new toy so I'm not complaining.

Ciao
thowi

OK, I tried it and it is correctly initialized from the secondstage bootloader, but then it hangs on booting, so it looks like we really have the problem that the drivers are not fast enough bringing the device online so that /dev/sda5 is available.

But if you try this kernel on a normal Multiboot image partiton residing on CF (and probably in flash too) you already get nice effects on the USB devices, so it is really an improvement for USB support !

The 110k size increase of the kernel is not a big thing (4MB Flash have leave plenty of freespace)

So we have to think for a moment on how to proceede from here and I'll play with the rootdelay parameter in the meantime asuming that this patch is built into the kernel ...

But this IS promising, so let's see where this journey brings us.

Ciao
thowi