Flashing Oz To Zaurii With Non-original Rom

[jan]

The installation notes clearly state: Ensure that your C7×0 machine has a standard flash partitioning (e.g. as it was originally), flashing may fail if this is not the case

Before I start, can someone please confirm the NAND Flash Back from Maintenance Menu contains really the whole flash inlcuding partitioning.

So, whenever I'm about to install OZ, I'm required to go back to Sharp partitioning style. The only way I'm aware of to do so, is grabbing a NAND Flash backup somewhere. Restore it. Install OZ. Why can't we make it easier to get OZ, like flashing only once. (Nowadays who's using Sharp ROMs?)

First idea: OZ is distributed as model specific images. All data will be erased during upgrade anyways. Then, why can't developers or early adaptors just make a NAND Flash Backup of a fresh installation and distribute this?

Second idea: When updating, we kind of boot from CF/SD, this means we can do about anything while updating. Why can't the installer script just overwrite whatever partition table it finds?

The perfect installer script...
... first examins the old installation, espially check for know distributions, i.e. OZ current version -1 in particular
... checks whether what the user requests is sane
... identifies installed packages
... backs up all user data to RAM or SD/CF
... creates partitions as required by the new distribution
... if the old installation was known / compatible restore basic configuration, especially networking
... boot the new configuration
... if the old installation was known / compatible, install all packages that were there before upgrade in a version suitable for the new ROM
... restore user data

The more than perfect installer script doesn't require anything as risky or cumbersome as flashing, repartitioning, hard resetting, Japanese menus...

ATM I have no idea whether something like this is at all possible but on the other hand I can't see why not. At least I think you can see (and comment) on the goals of my perfect installer script:
Whatever you start with, there is always a working installation in the end.
Provide an upgrade path for OZ users.
Ignore any Sharp software design decissions (In Europe new and used units are sold without a Sharp ROM)

[lardman]

The only way you'll have a different flash partitioning is if you've used pdaXrom (and perhaps cacko..?) and specifically altered the partitioning - in this case, use the same updater.sh and tools.tar files (that would be used to install those distros) to alter the partition back to the 50-50% split and then flash OZ as usual.


Si

[pgas]

use the same updater.sh and tools.tar files (that would be used to install those distros) to alter the partition back to the 50-50% split and then flash OZ as usual.

I had tried that but you cannot return to the exact partition scheme with the partition tool. (something like precision to the MB is not enough)

So the nand restore is the only solution.

First idea: OZ is distributed as model specific images. All data will be erased during upgrade anyways. Then, why can't developers or early adaptors just make a NAND Flash Backup of a fresh installation and distribute this?

It requires to install the distribution the zaurus, create the nand backup with the zaurus
while initrd image are created on the pc with script.

Another problem is that devs can now create image that installs on a 700 without a 700, while to create a nand for the 700 you need a 700

And I'm pretty sure there are other good reason not to do this

besides a nand backup install will not be compatible with your other goals
(doesn't require anything as risky or cumbersome as flashing...., Whatever you start with, there is always a working installation in the end...)


kexec will probaly allow to boot into a new distros  without flashing in a near future

[lardman]

I had tried that but you cannot return to the exact partition scheme with the partition tool. (something like precision to the MB is not enough)

I'd be interested to know more about the partition issues. I tried pdaXrom a long time ago and re-partitioned, I then reflashed OZ and have fiddled with the partitioning scheme using the pdaXrom flasher, etc.

I have had to do a NAND restore, but only because I flashed a kernel that was too large while fiddling with cpufreq support, not because the flash partitioning was wrong.

Does anyone actually know what the issue is with the flash partitioning?


Si

[Hrw]

And one c7x0 image is good for 700/750/760/860 devices - if we would have to distribute NAND images then we will need to supply them for each device - too much space & bandwidth needed.

Second thing is /home/ erasing which happen with NAND backup - I like to keep it when flash new image.

[jan]

Second thing is /home/ erasing which happen with NAND backup - I like to keep it when flash new image.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115419\"][{POST_SNAPBACK}][/a][/div]

I didn't know keeping /home was possible. That's definitely better.

[ant]

...
Second thing is /home/ erasing which happen with NAND backup - I like to keep it when flash new image.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115419\"][{POST_SNAPBACK}][/a][/div]

That's good if you upgrade openzaurus but is a nightmare if you come from sharp or other distros.

I'd like to have an option to clear the whole user data (like pdaxrom installer).

Just my 2 cents

Ant

[jan]

BTW: Does this mean we are waisting a huge part of the flash just because of Sharp's partioning?
OPIE image has 19MB, 50% of 128MB is more

[CoreDump]

The installation notes clearly state: Ensure that your C7×0 machine has a standard flash partitioning (e.g. as it was originally), flashing may fail if this is not the case

Before I start, can someone please confirm the NAND Flash Back from Maintenance Menu contains really the whole flash inlcuding partitioning.

I'm pretty sure this is the case

So, whenever I'm about to install OZ, I'm required to go back to Sharp partitioning style. The only way I'm aware of to do so, is grabbing a NAND Flash backup somewhere. Restore it. Install OZ. Why can't we make it easier to get OZ, like flashing only once. (Nowadays who's using Sharp ROMs?)

That would be possible, yes.

First idea: OZ is distributed as model specific images. All data will be erased during upgrade anyways. Then, why can't developers or early adaptors just make a NAND Flash Backup of a fresh installation and distribute this?

Bad idea, really. A NAND restore is one of the last resorts when you have "bricked" your PDA. If the NAND restore goes wrong, it gets ugly (and possibly expensive) real quick. On the other hand, you can easily recover from a bad flash installation.

Second idea: When updating, we kind of boot from CF/SD, this means we can do about anything while updating. Why can't the installer script just overwrite whatever partition table it finds?

It could, if someone would sit down and hack update.sh

The perfect installer script...
... first examins the old installation, espially check for know distributions, i.e. OZ current version -1 in particular
... checks whether what the user requests is sane
... identifies installed packages
... backs up all user data to RAM or SD/CF

This is already the case with OZ on most devices as /home is not touched
during the installation.

... creates partitions as required by the new distribution
... if the old installation was known / compatible restore basic configuration, especially networking

Easily doable, in fact, Hentges ROMs can do just that since over a year  

... boot the new configuration
... if the old installation was known / compatible, install all packages that were there before upgrade in a version suitable for the new ROM
... restore user data

This could be done, yes. Wouldn't be even too hard to hack up.

The more than perfect installer script doesn't require anything as risky or cumbersome as flashing, repartitioning, hard resetting, Japanese menus...

From a developer point of view, flashing is an excellent way to install a new OS.
Alone for the simple fact that you start in a known state after an upgrade.
I really do not hope that anyone codes up an "ipkg upgrade" kind of OZ installation.
It would be a support nightmare.

ATM I have no idea whether something like this is at all possible but on the other hand I can't see why not. At least I think you can see (and comment) on the goals of my perfect installer script:
Whatever you start with, there is always a working installation in the end.

Then you'll have to either flash a new rootfs or install a rootfs tarball on SD /CF.

Provide an upgrade path for OZ users.

Hmm?

[koen]

From a developer point of view, flashing is an excellent way to install a new OS.
Alone for the simple fact that you start in a known state after an upgrade.
I really do not hope that anyone codes up an "ipkg upgrade" kind of OZ installation.
It would be a support nightmare.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115463\"][{POST_SNAPBACK}][/a][/div]

No it's not, Familiar has been doing that for years now. Having an upgrade path helps you with spotting errors in packages and their prerm scripts.
The zaurus is a bit of a special case since the kernel lives outside the rootfs, but it's entirely possible to ipkg upgrade from oz 3.5.3 to oz 3.5.4, since familiar can do that as well. Ångström has the same goal, so get ready for a nightmare

[jan]

Bad idea, really. A NAND restore is one of the last resorts when you have "bricked" your PDA. If the NAND restore goes wrong, it gets ugly (and possibly expensive) real quick. On the other hand, you can easily recover from a bad flash installation.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115463\"][{POST_SNAPBACK}][/a][/div]

So, what's the big difference between "NAND Restore" and "flash installation"? OK, the first option overwrites everything including partition table, the latter one only root and kernel. But what's the point? Without a working root partition the Z won't do much. You need to reflash. What harm does the Maintenance Menu's "NAND Restore" cause? Could it stop the Maintanence Menu itself from working?

The more important question: I'm on Cacko full, I don't like it for all the Sharp applications I don't use. I'd could go cacko lite or pdaXrom but something tells me I should give OZ/OPIE a try. (I really like KO/PI from Cacko feed). I commented on a better installer just for the sake of it, what I really want to know is a safe way from Cacko 1.23 full to OZ.

I could not find any information about how 'original" the ROM must be to be OK for OZ. Is it only about having a partition big enough for the rootfs image? Then I don't want to do a NAND Restore. IMHO The installation instruction (if not the installer) should be better here? (The only info I found is. "The only way to go back to the correct partitioning is NAND Restore", "NAND Restore is risky", "There could be other ways")

Please can someone tell stupid newbies like me safe and convinient way from Cacko to OZ.

BTW: What do the Back/Restore tools on Sharp/Cacko ROMs backup? I assume /home but I couldn't find anything for sure.

[CoreDump]

From a developer point of view, flashing is an excellent way to install a new OS.
Alone for the simple fact that you start in a known state after an upgrade.
I really do not hope that anyone codes up an "ipkg upgrade" kind of OZ installation.
It would be a support nightmare.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115463\"][{POST_SNAPBACK}][/a][/div]

No it's not, Familiar has been doing that for years now. Having an upgrade path helps you with spotting errors in packages and their prerm scripts.
The zaurus is a bit of a special case since the kernel lives outside the rootfs, but it's entirely possible to ipkg upgrade from oz 3.5.3 to oz 3.5.4, since familiar can do that as well. Ångström has the same goal, so get ready for a nightmare
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115476\"][{POST_SNAPBACK}][/a][/div]

Personal experience shows that ipkg upgrade should beavoided at any cost *cough* BB *cough*.
And this experience is as recent as two days ago...

[CoreDump]

Bad idea, really. A NAND restore is one of the last resorts when you have "bricked" your PDA. If the NAND restore goes wrong, it gets ugly (and possibly expensive) real quick. On the other hand, you can easily recover from a bad flash installation.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115463\"][{POST_SNAPBACK}][/a][/div]

So, what's the big difference between "NAND Restore" and "flash installation"? OK, the first option overwrites everything including partition table, the latter one only root and kernel. But what's the point? Without a working root partition the Z won't do much. You need to reflash. What harm does the Maintenance Menu's "NAND Restore" cause? Could it stop the Maintanence Menu itself from working?

As I understand it, this is indeed the case.

I could not find any information about how 'original" the ROM must be to be OK for OZ. Is it only about having a partition big enough for the rootfs image?

Umm, good question actually. IMO a root partition of >40Mb should do, depending on your device of course.

Then I don't want to do a NAND Restore. IMHO The installation instruction (if not the installer) should be better here? (The only info I found is. "The only way to go back to the correct partitioning is NAND Restore", "NAND Restore is risky", "There could be other ways")

Please can someone tell stupid newbies like me safe and convinient way from Cacko to OZ.

BTW: What do the Back/Restore tools on Sharp/Cacko ROMs backup? I assume /home but I couldn't find anything for sure.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115490\"][{POST_SNAPBACK}][/a][/div]

[Meanie]

what's the reason for picking the name Ã…ngström? it sort of has a negative connotation to it  

but really, shouldn't the installer give the user a choice like:

1. new install, wipe everything and create default partitions
2. advanced install, let user repartition manually
3. upgrade an existing distro, and keep /home

option 2 probably only applies to the C3x00 models, in particular the C3000

just my 5c (since we don't have 2c coins anymore down in oz)

[koen]

Personal experience shows that ipkg upgrade should beavoided at any cost *cough* BB *cough*.
And this experience is as recent as two days ago...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115507\"][{POST_SNAPBACK}][/a][/div]

You have a buggy version of ipkg, use <.154 or >.159, the versions in between run prerm scripts when updating, which remove busybox symlinks.