28 replies to this topic

[pieterg]

For UBIFS Migration without fresh Install you have to do the Softwareupdate FIRST to get the latest drivers and kernel which are able to run ubifs and THEN backup with mkfs.ubifs in dFlash settings and restore your own UBIFS backuped image.

But because the online update did not succeed, this wasn't an option.
That's why we still have the update warning / skulls on the dm8000/dm7020hd.

But it seems last nights fix finally made it work, I received one report today of a betatester who successfully managed to update his dm8000.
(I cannot test this myself, that's part of the reason why it takes so long for these things to get fixed, having to interpret error reports from users who ignored the update warning, and 'bricked' their box)

So most likely the skulls will be removed soon.

Edited by pieterg, 24 April 2013 - 09:16.

[Lost in Space]

I already reported 2 days ago that on my 8000 since the SSL postinst bug was fixed it worked to upgrade an image from 16.04, then do backup/restore with dFlash to get ubifs. So your skull on  the 8k could haven been removed already 2 days ago. Anyway, better late then not at all.

 

And I also already reported 2 days ago that you should hceck if the broadcom nand driver contains the patch that in case of ubifs the bad block handling is left to ubifs to be sure that it works on 7020hd without a timebomb when a new bad block occures.

Edited by gutemine, 24 April 2013 - 22:01.

[amigo]

just did a online update on dm8000, no problem

[pieterg]

I already reported 2 days ago that on my 8000 since the SSL postinst bug was fixed it worked to upgrade an image from 16.04, then do backup/restore with dFlash to get ubifs. So your skull on  the 8k could haven been removed already 2 days ago. Anyway, better late then not at all.

no, it could not, because of the mtd partition name change, the update would not succeed to modify the 'autoexec.bat' arguments, so after update+reboot, the rootfs might not be mounted.

So please do your research before you make such statements.

And I also already reported 2 days ago that you should hceck if the broadcom nand driver contains the patch that in case of ubifs the bad block handling is left to ubifs to be sure that it works on 7020hd without a timebomb when a new bad block occures.

you should not report issues if you can see those issues are not present in our environment.

[Lost in Space]

I wrote about the tests on the 8000, there the Flashlayout didn't change. And dFlash writes the autoexec.bat correctly himself depending on what root filesystem you specify.  I wrote update, dFlash backup and restore = no reboot needed after upgrade.

 

PS: I don't use PLi build environment at all, and hardly the DMM OE 2.0 environment (only when I'm forced to do so like when building my own kernel oder driver patches). If you confirm that the broadcom nand drivers you are building into your kernels are OK then thanks for checking, because that was what I asked as I could not do myself. The 8000 doesn't use the broadcom nand drivers so there was never such a potential problem.

 

And thanks for removing the warning now!

Edited by gutemine, 25 April 2013 - 14:40.

[pieterg]

No prob
BTW, the flashlayout did not change, but the name of the /boot mtd partition changed from 'boot partition' to 'boot'.
So in case of an update, we have to try and mount both devices.
Because of that, updates went wrong, if a user was still on a pre-18th of april version.

[Lost in Space]

Thankfs for explaining, but doesn't PLi not mount /boot at all

 

On the dm7020hd the root partition got bigger, all other boxes were the same.

 

Having such a big /dev/mtdblock with jffs2 would have been a shot into your own knee, while with ubifs it is not a problem.

Edited by gutemine, 25 April 2013 - 16:10.

[pieterg]

Thankfs for explaining, but doesn't PLi not mount /boot at all

we only mount it to update the kernel-image and bootlogo packages, during an opkg image.

On the dm7020hd the root partition got bigger, all other boxes were the same.

The size is not an issue, the partition name is.

Having such a big /dev/mtdblock with jffs2 would have been a shot into your own knee, while with ubifs it is not a problem.

I see no difference in that respect, both jffs2 and ubifs resize themselves to the partition size.

[Lost in Space]

Thanks for explaining and your patience with me.

 

Try to mount a 1GB big Flashpartition with jffs2 and then you know that the resize time is not the problem. Even with the summary enhancement jffs2 is significantly slower to mount such big partitions. Anyway as the issue is now solved we can now enjoy ubifs, and for the 800se and 500hd anybody who wants ubifs will have to live with JTR as the kernel still needs to be replaced.

 

And as you were so friendly to check in also the necessary block2mtd patches nfidump now works also on PLi images to extract ubifs images - Thanks as this makes live easier for me.

Edited by gutemine, 25 April 2013 - 16:54.