OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: jan on February 19, 2006, 03:05:54 pm
-
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)
-
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
-
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
-
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
-
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.
-
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.
-
...
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
-
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
-
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?
-
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
-
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.
-
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...
-
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]
-
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)
-
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.
-
Umm, good question actually. IMO a root partition of >40Mb should do, depending on your device of course.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115508\"][{POST_SNAPBACK}][/a][/div]
Thanks for your help. I made a NAND Backup. Then used Cacko's Partitioning tool and resized root partition to 50MB. Made CF card with initrd.bin (opie_c7x0...), zImage.bin and update.sh from OZ 3.5.3. went through installation instructions. The image got flashed and OZ boot logo was shown but instead of booting a got:
INIT: No inittab file found
Enter runlevel:
Entering 2 RET yields
INIT: Entering runlevel: 2
INIT: no more processes left in this runleveland nothing more.
What was my mistake? The opie image (which I renamed to initrd.bin) is only 19MB big. Did I pick the right file? Is init looking for files under /etc which are normally outside the root partition and therefore not there?
-
Interesting result. I have no idea what went wrong there.
/sbin/init is found but /etc/* is MIA heh. Maybe the kernel uses certain parameters which sort-of force you into the standard partitioning, can't check that ATM. It might also be a problem with updater.sh, who knows?
It was worth a try tho.
-
/sbin/init is found but /etc/* is MIA heh.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=115636\")
I got a step further by going back to Cacko temporarly. Now I get passed init and then a screen full of tar errors related to 'read-only' filesystem.
edit: First line is
mount: Mounting /dev/ram1 on /dev failed: No such device
What did I do wrong here?
[a href=\"http://www.spacezone.de/zaurus/articles/OZ_OPIE.html]complete install log[/url]
jan
-
From the linked webpage:
INIT: Id "1n" respawning too fast: disabled for 5 minutes
I've seen this when the rootfs doesn't flash. You've got a C860, does this actually have 100MB of flash? (as you've set root to 50MB) Try setting it to half of the total amount (64MB I think).
Si
P.S. If this fixes things, then we need to look at the updater.sh source and work out why it's so damn picky about the partition sizes. I've attached the source (may be a bit old now, but I think it's still the current one)
-
The content of that script in one word: ouch
Whoever wrote that has one hell of a talent to write unreadable code
-
From packages/zaurus-updater/c7x0/
Si
-
I've seen this when the rootfs doesn't flash.
I think you are right. I says "flashing the kernel" and reboots quickly. I don't think the rootfs got acutally flashed.
You've got a C860, does this actually have 100MB of flash? (as you've set root to 50MB) Try setting it to half of the total amount (64MB I think).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115746\"][{POST_SNAPBACK}][/a][/div]
Been there, done that. I just didn't post it because I didn't improve things. Same error.
Someone pointed out that the Cacko/padXrom installer can't set the root partition size to exactly (to the byte) the size it was originally. Maybe that's the point.
-
the original partition size are 53 (root) /68 (user)
But as I said I'm not sure if resizing to 53 with the cacko/pdaxrom installer is enough.
I would restore from an original nand backup, this will restore the original partitions and then flash Oz
-
Someone pointed out that the Cacko/padXrom installer can't set the root partition size to exactly (to the byte) the size it was originally. Maybe that's the point.
No, probably not as I'd used the pdaXrom updater.sh to resize and then return the partitions to about 50-50% and then was able to install OZ without problems.
I would restore from an original nand backup, this will restore the original partitions and then flash Oz
Some are available from here: http://pocketworkstation.org/files/recover/ (http://pocketworkstation.org/files/recover/)
But the c860 one says that it probably doesn't work... Is there another place to download these, like in ZUG downloads?
Si
-
Is there another place to download these, like in ZUG downloads?
http://www.trisoft.de/download/ (http://www.trisoft.de/download/)
http://downloads.conics.net/pda/zaurus-sl-...iginal-backups/ (http://downloads.conics.net/pda/zaurus-sl-c700/service-menus/original-backups/)
-
P.S. If this fixes things, then we need to look at the updater.sh source and work out why it's so damn picky about the partition sizes. I've attached the source (may be a bit old now, but I think it's still the current one)
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=115746\")
I tried to understand update.sh and failed. The first part seems to check where the root filesystem is in terms of /dev/mtd... The second should flash it whenever it finds initrd.bin. No clue about the details and why things don't work. [a href=\"http://www.spacezone.de/zaurus/articles/update.sh.txt]commented version of update.sh[/url]
Did anyone try the installer from pdaXrom/cacko with OZ images? They do work after all.
jan
-
I just try, and I was wrong about the nand backup, resizing to 53 with the cack/pdaxrom installer, then reboot and flashing OZ with the openzaurus installer is enough