182 replies to this topic

[Lost in Space]

I'm pretty sure that PLi team is not a profit organisation :-)

 

And without Dreamboxes and the Dreambox users and owners there would be no PLi Team or Images at all.

So annoying your base community where you originate from is not such a good idea on the long run.

 

And without a bootlog I can't tell you what went wrong with your conversion.

 

BUT probably you simply  have the usual problem that you enabled kernel command line and it still includes a mount command for jffs2 - which then ruins ubifs on the first boot and gives lots of error in bootlog.

 

Check Reichi's Wiki on how the corect kernel command line for ubifs should be http://dream.reichho....BCberschreiben

 

But simply disabling is easier, then both ubifs and jffs2 images will work.

 

So in short check bios, disable kernel command line and flash the UBIFS image once more and then it is very likely that it boots without problems.

Edited by gutemine, 15 April 2013 - 09:04.

[gorski]

Last time I checked DMM took a helluva lot from DBox and similar projects that were and still are open source and DMM didn't care one little bit they annoyed the Open Source community (on many an occasion, especially when asking for help from the community, alleging OpenEnigma project, then closing it when it suited them, then having been told by the courts that this is NOT OK, they carried on regardless - so, I would say DMM and their trabants are mindless and thoughtless, no conscience of any sorts, "profits only" type of mindset rules there), so this seems a rather convenient loss of memory and double standards all round, from those alleging "bad behaviour" from Open Source community... Moreover, DMM is at war with the community at large for a while now... Which community they depend on - is sending them on their way down... for many a good reason, obviously...

 

On the flip side, since you like playing dumb when it suits you, I say "dodge this"...

[Lost in Space]

Nobody is at war, and the only law suite that DMM lost was the usage of the enigma2 name by other vendors. All the Licensing part that is repeated all over again ist just interpretation, but simply not true. It is everybodies right to change a license if you like it or not.

 

And I was told that I'm too dumb to understand OpenSource so asking me for advice is not such a good idea.

 

I only wanted to understand the situation and it was now explained, so I'm now accepting it - and take my measures.

Edited by gutemine, 15 April 2013 - 10:17.

[gorski]

Nobody is at war? Well, that tells a story and shows how much DMM is in touch with the community they depend on...

 

You are not too dumb but too disinterested to understand these little things you choose to ignore...

 

Our values obviously differ...

 

Edit: Btw, I suppose many could use your TECHNICAL advice. But that is NOT the same as having to agree with you on other, NON-TECHNICAL matters, where you may not be the "authority" of any sort, since you are seriously biased in oh so many ways...

Edited by gorski, 15 April 2013 - 10:18.

[Lost in Space]

Well, if you don't like my optionion this is simply your opinion, which I accept - but it doesn't mean that I like it or go for it.

 

You have the same freedom on my opinion.

 

I was just technically knowledgeable enought to see that there is and were no technical reason, so I took the freedom to proove this in a way the users could verify themselves instead of arguments they maybe hardly understand.

 

In this case the old war rule applies that only troops on the ground win a war and not the generals in their home bases.

 

But as i already wrote everybody can now try, read and conclude - which applies to my understanding of freedom of information and choice.

 

But this is Off Topic now as it has nothing to do with JTR Plugin and the discussion doesn't bring any added value for the users either.

 

Maybe it is cruel to show candy if daddy says that you will not get it, but this is not my fault in this case.

 

gutemine

Edited by gutemine, 15 April 2013 - 11:00.

[gorski]

No, you misunderstood: I responded to your unqualified bashing of OS community... From which DMM stole lots of stuff suddenly crying their eyes out when other people do it to them and so on and on...

 

Never mind, wherever you feel like getting your butt kicked - I will be here...

[Lost in Space]

My butt is open to kicking from anybody, BUT don't expect me to not kick back.

 

Better getting kicked then crawling into ....

 

I wasn't bashing OS community, I just summarized my findings and understanding of the current situation of OpenPLi on my and others Dreamboxes.

 

And maybe it is impolite to asky why when I hear a no, but this is how gutemine works.

 

And it is simply sad that gutemine has to ask these questions or do plugins like this.

 

gutemine

Edited by gutemine, 15 April 2013 - 11:48.

[gorski]

No one is perfect and we all have to learn.

 

You may have been there first (before OS community), on this occasion, but that doesn't mean the OS community is "in poor state" or some such nonsense, which implication was impolite and a little arrogant, to say the least...

[theparasol]

Its about time that dreambox dies and why the customer has choice to buy a good box. Their boxes are crap and still overpriced (to suggest quality?!) their soft is nowadays closed. Why should an opensource project like openpli support them any longer? They not only chose to do it all by theirselfs but also got some opensource authors of plugins that far that they changed their licenses so their code may not be run any longer on other boxes. You cant call it war but its at least a very childish way to act.

Matter of fact, the good old webif of the boxes has been replaced by openwebif to compensate for the changed license.

 

If you ask me the (minimal) support of openpli is just there coz historically there was always an openpli image for the dreamboxes.

I have had a 7020, a dm600pvr and a dm800hd pvr. And every single one of them was the real deal and every one of them had a big or minor hardware defect.

In those days there was no choice, later on there were "clones" (never bought any myself but serviced a lot for others->total crap)

I for sure wont ever buy a dreambox ever again and hope others sat enthousiasts dont buy them too.

Same goes for VU, they depend on opensource community but still isnt maximizing the support (driver issues they wont fix).

Right now I have a XP1000 and if I needed something more powerfull it would be an ET model.

But this all is my personal opinion / viewpoint.

Edited by theparasol, 15 April 2013 - 12:12.

[WanWizard]

Gentlemen, can we get back on topic, and keep it civilized please?

[Lost in Space]

Well I now already wrote multiply that we are repeating arguments and that I already understood the state of the union and will act accordingly.

 

I only see the discrepancy on what you are preaching and actually doing and it simply took me some time and some testing to understand it.

 

So I'm simply a little bit slow and too navie,  for which I'm even willing to excuse.

 

And if you don't like my feedback and advice you are welcome as I respect everybodies opinion.

 

But as i wrote in my reply to Eriks statement which is the origin of this thread and JTR for OpenPLi:

 

I can open the box - but it is your decision if you are not willing or able to close it.

 

BTW it looks like JTR is now working as it should, or are there any further trouble reports  from your tests ?

 

The only remaining thing I could offer is to add also the driver, ssl and kernel hold option to the Special edition as the original JTR has, which allows you to do Softwareupgrades without overwriting the things that JTR replaced.

 

Based on the feedback we got this might be a needed option which should maybe also added to JTR PLi Special edition, as it looks like there is no catch up of the native PLi images in the neared future.

Edited by gutemine, 15 April 2013 - 13:09.

[metoo]

well, maybe a lack of manpower?

maybe it will be included with openPli 4.0?

time will tell, and its no problem for me, i have chosen for OpenPli with Xtrends after 9? years DMM's 

[luis67]

 

I'm pretty sure that PLi team is not a profit organisation :-)
 
And without Dreamboxes and the Dreambox users and owners there would be no PLi Team or Images at all.
So annoying your base community where you originate from is not such a good idea on the long run.
 
And without a bootlog I can't tell you what went wrong with your conversion.
 
BUT probably you simply  have the usual problem that you enabled kernel command line and it still includes a mount command for jffs2 - which then ruins ubifs on the first boot and gives lots of error in bootlog.
 
Check Reichi's Wiki on how the corect kernel command line for ubifs should be http://dream.reichho....BCberschreiben
 
But simply disabling is easier, then both ubifs and jffs2 images will work.
 
So in short check bios, disable kernel command line and flash the UBIFS image once more and then it is very likely that it boots without problems.

 
This is my log
Jumpin'Jack Flash initramfs with ubifs by gutemine V5.3 Build Mar 16 2013 19:59:29

Kernel commandline: ubi.mtd=root root=ubi0:rootfs rootfstype=ubifs rw console=ttyS0,115200 debug bmem=116M@140M
ubiattach: error!: UBI is not present in the system

.[ 2.615000] hub 3-0:1.0: over-current condition

Jumpin ubifs Flash ubi0:rootfs ...

[ 3.206000] UBIFS: recovery needed
[ 3.216000] UBIFS: recovery completed
[ 3.217000] hub 4-0:1.0: over-current condition
[ 3.217000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 3.218000] UBIFS: file system size: 56908800 bytes (55575 KiB, 54 MiB, 3705 LEBs)
[ 3.219000] UBIFS: journal size: 8017920 bytes (7830 KiB, 7 MiB, 522 LEBs)
[ 3.220000] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 3.221000] UBIFS: default compressor: zlib
[ 3.221000] UBIFS: reserved for root: 0 bytes (0 KiB)
Continue booting...

Continue booting failed :-(

[ 3.225000] Kernel panic - not syncing: Attempted to kill init!
[ 3.226000] Rebooting in 180 seconds..

[Lost in Space]

Thanks, so at least the kernel command line looks OK.

 

Could you try to flash the image with recover bad sectors once more and report if this changes the situation?

 

Ubifs has its own bad block handling, but if there are not Yet marked bad blocks in flash this could cause such situations where is resists to boot to prevent further damage. As soon as all bad block arte marked also in ubifs this is not a problem but ubifs tries to avoid re-writing them to overcome the double write problem, which means it is dependant on correctly marked bad blocks as from then on any newly detected ones will be marked by ubifs.

Edited by gutemine, 15 April 2013 - 13:35.

[luis67]

 

Thanks, so at least the kernel command line looks OK.
 
Could you try to flash the image with recover bad sectors once more and report if this changes the situation?
 
Ubifs has its own bad block handling, but if there are not Yet marked bad blocks in flash this could cause such situations where is resists to boot to prevent further damage. As soon as all bad block arte marked also in ubifs this is not a problem but ubifs tries to avoid re-writing them to overcome the double write problem, which means it is dependant on correctly marked bad blocks as from then on any newly detected ones will be marked by ubifs.

 
Same result,booting screen logo and nothing
FIRST STAGE 1.0/400 {BO23456}
[m

2ND STAGE OK, build #84 (2011-09-01)

....
0.031 - BCM board setup
0.032 - fp init
0.032 - ca init
0.524 - load config
0.550 - config loaded.
* woke up from power
* press [S] to enter setup
lcd: BOOT #84
- read config file: /boot/secondstage.conf
detected jffs2 blocksize: 16kb
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++UUUUUUUUUUUUUUUUUUUUUUUUU
dreamupd initialized
Scanning JFFS2 FS: . | / - \ | / - \ | / - \ | done.

find_inode failed for name=secondstage.conf

load: Failed to find inode

- failed to open /boot/secondstage.conf
- failed to open /cf/autorun.bat
lcd: /boot/bootlogo-dm500hd.elf.gz
Jumpin'Jack Flash initramfs with ubifs by gutemine V5.3 Build Mar 16 2013 19:59:29

Kernel commandline: ubi.mtd=root root=ubi0:rootfs rootfstype=ubifs rw console=ttyS0,115200 debug bmem=116M@140M
ubiattach: error!: UBI is not present in the system

.[ 2.615000] hub 3-0:1.0: over-current condition

Jumpin ubifs Flash ubi0:rootfs ...

[ 3.209000] UBIFS: recovery needed
[ 3.217000] hub 4-0:1.0: over-current condition
[ 3.219000] UBIFS: recovery completed
[ 3.219000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 3.220000] UBIFS: file system size: 56908800 bytes (55575 KiB, 54 MiB, 3705 LEBs)
[ 3.221000] UBIFS: journal size: 8017920 bytes (7830 KiB, 7 MiB, 522 LEBs)
[ 3.222000] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 3.222000] UBIFS: default compressor: zlib
[ 3.223000] UBIFS: reserved for root: 0 bytes (0 KiB)
Continue booting...

Continue booting failed :-(

[ 3.228000] Kernel panic - not syncing: Attempted to kill init!
[ 3.229000] Rebooting in 180 seconds..

[Lost in Space]

Strange, did you try already with an OE 2.0 from DMM as donator for kernel and drivers ?

 

Because now the ++++UUUU show that Bad blocks are clean, so this cann't be the reason.

Edited by gutemine, 15 April 2013 - 14:20.

[luis67]

Strange, did you try already with an OE 2.0 from DMM as donator for kernel and drivers ?
 
Because now the ++++UUUU show that Bad blocks are clean, so this cann't be the reason.

I will try.

[Lost in Space]

Thanks, because that's the only thing we can try for the moment.

 

The created backup image you are flashing is NOT > 60MB - because then flashing on a 500hd is likely to fail.

 

With standard images this can't happen, but with backups it is possible, if the base images is too big (eg more then 55MB used, then due to the 10% ubifs overhead you are reaching the flash limit).

Edited by gutemine, 15 April 2013 - 14:26.

[malakudi]

@gutemine: I don't speak for OpenPLI, but if you have read other topics for other boxes (VU+, Gigablue and others), it is the policy of OpenPLI that it only supports boxes that the manufacturer delivers patches and updates, compatible to OpenPLI source tree. Because of this policy and failure to comply by some box manufacturers, box like VU+ Solo2 has some issues with OpenPLI. The same issue should exist with boxes from DMM. Since nobody from DMM provides OpenPLI with those patches, it is not a priority to get them implemented. OpenPLI focuses on development on the enigma2, with features that the closed source enigma2 from DMM still lacks - have they (DMM developers) ever made teletext subtitles work reasonably?

 

An exception would be if some of the core developers was really motivated to upgrade the DMM kernel recipes for his own preference. But since DMM hardware is considered either obsolete (DM800) or overpriced for its features (DM800SE, DM7020HD), then nobody really cares ...

Edited by malakudi, 15 April 2013 - 14:39.

[Lost in Space]

I'm reading the commits in the OpenPLi repository, and belive me - for the last 12 months of enigma2 open source enhancements this is pretty poor, escpecially in the C++ part, no matter how motivated they might be and no matter which hardware they use.

 

If their PLi centric thinking is good or bad - simply the future will show.

 

On the other side if I read the DMM check-ins of the last year and extrapolate the closed source work too, the total workload is only 1-2 man years, which is not something to be proud either.

 

BUT this is not critics, this is my personal opinion and justification and as long as I'm not prooven totally wrong I'll stay with it.

 

But this has nothing to do with JTR, it is only the root cause of it. If i would have liked to open a 'why don't you upgrade the Dreamboxes' thread I would have opened it.

 

I have now written multiply that i understod the situation, accept it an are sad about it, but life is the way it is, it is that simple.

 

For me actually it is a relief, because then soon my tools will not even inofficially support PLi images anymore as they become to old for the extra testing effort needed.