Withdrawal of UBIT NAND support until further notice

[peaslaker]

The UBIT method of installing Arch Linux ARM to NAND is suffering from some low level issues in the AUFS2/UBIFS stacked filesystem. At the moment this results in fundamental problems where the stacked filesystem is just not playing by the rules and it renders basic, low level functions inoperable (there are problems with permissions).

NAND install has not been documented since UBIT version 0.5. There is no intent to provide support for NAND installs until these issues have been resolved, which may involve a complete refactoring of the filesystem arrangements. This issue has arisen somewhere in the advance of kernel versions since 2.6.36 with the matching AUFS 2.1 versions.

Installing Arch Linux ARM in a writeable NAND partition is still not recommended because the NAND memory eraseblocks are only rated for 1000 erase/write cycles, after which the Plug will become inoperable.

[leshan]

Hi peaslaker,

Thank you for your great job.
Is it ok to install on NAND but boot from external hard drive?
Just consider the land installation as a rescue system?

[peaslaker]

There is some very strange behaviour in the way UBIT has been running the NAND installed version of Arch Linux ARM - some programs just object to the stacked root filesystem and don't function correctly.

My test case is trying to add a new user to the system and then switch to that user. This fails on the standard NAND install, but if you don't include the documentation, it doesn't fail. For me, that behaviour is too flaky to support so I am currently looking for a workaround. The culprit appears to be the AUFS2 stacked union filesystem, which is a rather fundamental part of the UBIT NAND solution.

The current situation is almost impossible to debug. The AUFS stacked filesystem contents is complete and has perfect integrity, verified by checksum and I have even been able to use the UBIT tarball command to transfer the NAND content back to hard disk where it runs perfectly. This appears to be an area where AUFS does not consistently respond to low level calls, depending on the currently configured stack of filesystems.

AUFS is also the only reason I am maintaining and distributing a UBIT kernel. If I stop using AUFS, I can start using the Arch Linux ARM kernel. This is also important as Arch Linux ARM runs a rolling upgrade on its packages, so new packages are compiled against the latest kernel headers, with no guarantee that they will operate correctly with an out of date kernel.

I've got something in the works, but obviously this is quite a radical change for UBIT.

$this->bbcode_second_pass_quote('leshan', 'I')s it ok to install on NAND but boot from external hard drive?
Just consider the land installation as a rescue system?

[kmihelich]

There might be some leftovers on the wiki, I haven't checked for sure. We're also transitioning to a new site layout over the next few weeks, with better partitioning of devices and their appropriate installation instructions.

For the Arch Linux ARM kernel, we keep AUFS available, though only as a module. And it's really only those kernel modules (that I'm aware of) that are impacted by the rolling release. Each new kernel we need to rebuild aufs2, madwifi, and lirc, from what I can recall off the top of my head.

I know some people like the idea of NAND installs because it lets them have a power-tolerant device that is available quickly, a la routers/set top devices. But given the limited number of erase/write cycles that you pointed out, I think an appropriate method would be to maybe create a NAND-specific appliance-like image of PA. Something separately maintained from the standard base install images that contains applications configured in a sensible manner to provide the bulk of functionality that is commonly requested.. auto-mount/umount of drives, linked into samba/apple, even minidlna. Essentially making a system that doesn't need frequent updates, but performs the majority of operations autonomously in such a way that doesn't require modifying and saving config files for separate installations. Updates to this image could be provided on a monthly basis possibly, again applied using a method that just overwrites the instance and they're back running.

These are just some thoughts on how to get the benefits of NAND for those that want it, while eliminating the risk of burning out the flash.

[leshan]

$this->bbcode_second_pass_quote('peaslaker', 'W')here are you getting the NAND install instructions from? I didn't intend there to be any current instructions in circulation because the instructions had fallen behind the v0.6 UBIT functionality.

[leshan]

$this->bbcode_second_pass_quote('peaslaker', 'T')his is OK. The NAND system will work to some extent but have some flaky behaviour. It will probably be good enough for a rescue system.

[leshan]

$this->bbcode_second_pass_quote('kmihelich', 'T')here might be some leftovers on the wiki, I haven't checked for sure. We're also transitioning to a new site layout over the next few weeks, with better partitioning of devices and their appropriate installation instructions.

[kmihelich]

Everything Arch applies to Arch Linux ARM, we only modify upstream packages in order to compile on ARM if necessary. MySQL has worked for everyone so far, including myself.

There are guides under the Applications section in the wiki for common tasks, and they also outline quirks people have found. Use the resources available on the internet, thousands of people have documented the procedures in many different ways.