Re: [OpenWrt-Devel] Help with SysupgradeNAND
On Wed, 2014-07-09 at 16:27 +0200, Daniel Golle wrote: On Wed, Jul 09, 2014 at 04:10:52PM +0200, Ben Mulvihill wrote: JFFS2 works on bare MTD devices (originally NOR only, hackish NAND support exists in the wild though YAFFS2 is more commonly used). UBIFS is the only read-write filesystem which works on top of UBI, thus the only possible choice for overlay support. Not the only possibility surely? Currently we generate two images for the BTHOMEHUBV2B. Both use ubi. One has pure ubifs on top. The other has a squashfs/jffs2 overlay making use of gluebi. Everything works apart from sysupgrade but the only reason for doing things that way was that it was a natural progression from the pre-ubi arrangement and it worked out of the box. A squashfs/ubifs overlay is certainly cleaner. I'll see what I need to do to get it working. Ah, ok, now I understand the question :) And yes, you should use squashfs/ubifs for overlay and disable gluebi alltogether. gluebi is deprectated and was meant only for transition. ubiblock offers a much cleaner way for read-only filesystems and UBIFS makes much more sense than jffs2-on-gluebi. The penny has finally dropped! When I first made images using the new ubi support a few weeks ago the squashfs/jffs2 gluebi overlay worked out of the box, and the squashfs/ubifs overlay did not. I assumed I would have to generate the squashfs images for the latter case in some special way, preformatting an empty ubifs partition perhaps, or adding some magic to tell the kernel to mount rootfs_data as ubifs. I have just realised that the images work fine as they are, as long as the gluebi/mtd code doesn't get there first and attempt a jffs2 mount. So all that needs to be done to move over to a squashfs/ubifs overlay is to disable gluebi in the kernel configuration. I should like to ask John whether he would be happy for me to submit a patch to do that, on xway at least, not on xrx200 to avoid affecting the other lantiq nand boards? Or would it be better to find some way of enabling the volume_identify code in procd to distinguish a jffs2 rootfs_data from a ubifs rootfs_data. just in case in the future someone needs gluebi in the kernel for some other reason? Thank you Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 10/07/2014 08:27, Ben Mulvihill wrote: On Wed, 2014-07-09 at 16:27 +0200, Daniel Golle wrote: On Wed, Jul 09, 2014 at 04:10:52PM +0200, Ben Mulvihill wrote: JFFS2 works on bare MTD devices (originally NOR only, hackish NAND support exists in the wild though YAFFS2 is more commonly used). UBIFS is the only read-write filesystem which works on top of UBI, thus the only possible choice for overlay support. Not the only possibility surely? Currently we generate two images for the BTHOMEHUBV2B. Both use ubi. One has pure ubifs on top. The other has a squashfs/jffs2 overlay making use of gluebi. Everything works apart from sysupgrade but the only reason for doing things that way was that it was a natural progression from the pre-ubi arrangement and it worked out of the box. A squashfs/ubifs overlay is certainly cleaner. I'll see what I need to do to get it working. Ah, ok, now I understand the question :) And yes, you should use squashfs/ubifs for overlay and disable gluebi alltogether. gluebi is deprectated and was meant only for transition. ubiblock offers a much cleaner way for read-only filesystems and UBIFS makes much more sense than jffs2-on-gluebi. The penny has finally dropped! When I first made images using the new ubi support a few weeks ago the squashfs/jffs2 gluebi overlay worked out of the box, and the squashfs/ubifs overlay did not. I assumed I would have to generate the squashfs images for the latter case in some special way, preformatting an empty ubifs partition perhaps, or adding some magic to tell the kernel to mount rootfs_data as ubifs. I have just realised that the images work fine as they are, as long as the gluebi/mtd code doesn't get there first and attempt a jffs2 mount. So all that needs to be done to move over to a squashfs/ubifs overlay is to disable gluebi in the kernel configuration. I should like to ask John whether he would be happy for me to submit a patch to do that, on xway at least, not on xrx200 to avoid affecting the other lantiq nand boards? sorry i should have mentioned this. gluebi is dead, long life ubiblock !!! we backported ubiblock from 3.15, it allows raw r/o access to the squash. ubifs runs without intermediate gluebi/mtd layer, thus making the whole setup much simpler. from what i understand, ubiblock will obsolete gluebi in upstream so we decided to switch early. this should be done for xway and xrx200. John Or would it be better to find some way of enabling the volume_identify code in procd to distinguish a jffs2 rootfs_data from a ubifs rootfs_data. just in case in the future someone needs gluebi in the kernel for some other reason? Thank you Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Help with SysupgradeNAND
Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! I noticed a second issue. hostapd (running in some kind of dfs loop) was not killed by sysupgrade nand. That resulted in breaking the upgrade. System rebooted with old image. I personnaly added a check in sysupgrade if it runs below upgraded and if that's true, I kill _all_ processes. If interested I could publish the patch. A third point is the upgrade itself. I the rootfs image grows, and rootfs_data has all the remaining space aligned, it will not work because rootfs cannot grow. Perhaps rootfs_data should always be recreated in the update process. If interested I could also supply a patch. Kind regards, André On 09.07.2014 09:02, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Mit freundlichen Grüßen, André Valentin Projektkoordination / Systemadministration MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld Fon: +49 (521) 95945-0 | Fax -18 URL: http://www.marcant.net | http://www.global-m2m.com Geschäftsführer: Thorsten Hojas Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238 ___ CONFIDENTIALITY NOTICE The contents of this email are confidential to the ordinary user of the email address to which it was addressed and may also be privileged. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this email in error please email the sender by replying to this message. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09/07/2014 09:14, Andre Valentin wrote: Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. I noticed a second issue. hostapd (running in some kind of dfs loop) was not killed by sysupgrade nand. That resulted in breaking the upgrade. System rebooted with old image. I personnaly added a check in sysupgrade if it runs below upgraded and if that's true, I kill _all_ processes. If interested I could publish the patch. please send a patch A third point is the upgrade itself. I the rootfs image grows, and rootfs_data has all the remaining space aligned, it will not work because rootfs cannot grow. Perhaps rootfs_data should always be recreated in the update process. If interested I could also supply a patch. please send a patch John Kind regards, André On 09.07.2014 09:02, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On Wed, 2014-07-09 at 09:02 +0200, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... At the moment, SysupgradeNAND recreates rootfs_data as ubifs, then after reboot, the system tries to mount it as jffs2 and generates errors. But as you said in your reply to André, there is no particular benefit to using jffs2 instead of ubifs for rootfs_data. jffs2 just happens to be what is used currently. I'll have a look at moving over to squashfs + ubifs. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09.07.2014 09:48, John Crispin wrote: i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. No, not from me. I want it simple and not another layer. I think this is the best solution. I will send the proposed patches for sysupgrade today, perhaps the rootfs_data part later. Kind regards, André ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On Wed, Jul 9, 2014 at 12:48 AM, John Crispin j...@phrozen.org wrote: On 09/07/2014 09:14, Andre Valentin wrote: Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. One of the reasons why I didn't even consider jffs2 for IMX6 is that the IMX6 NAND controller with hardware ECC support uses the entire OOB area which was needed by jffs2. Their might be support in jffs2 now for not using OOB data but ubi/ubifs does seem to be the popular choice these days for NAND based filesystems. Tim ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
