Notices

I (ab)used what I knew of filesystems to force a check. Once freshly flashed (and known as good), I used the CLI to copy a known correct file form the SD to the rootfs several times, until the rootfs was filled. Then read back the files (copied to nul). This should have triggered any bad block on the surface to be marked as bad.

Once this was done, I installed diff and did it again, copied file from the card to rootfs in several instances, then used diff to make sure it's all good, and finally removed.

It all went well, no errors, so I'm going to assume that either this wasn't a bad block issue (though it certainly seems so) or it was correctly marked as such. So far, so good, I have most of my must-haves installed and no glitch.

Any way to know if I have bad blocks?

Also, fsck seems to not work in the latest version? Maybe it does, but my version spits some errors and fills the screen with what seems like UINT32 values in bright green. I'm afraid to keep trying.

Hm... I'd probably better add a way to copy the fsckstatus file to your eMMC in case you want to look at it... I assume it's working -correctly-, but I don't know what the output means from your description.

Also, as I said before, you do have bad blocks. It's inevitable. The -filesystem- marks them as bad; this means that if you re-flash, the new FS has to re-mark them. Also, copying a file to it will - at the FS level - automatically mark all bad blocks as bad and work around them. Thus, you won't see any problems(aside from a momentary "pause" as it re-writes the content to a different block).

However, as I've been trying to tell you, if you use the old 0.3x version BAD BLOCKS ARE INCLUDED IN YOUR BACKUP! They then get written over the current filesystem, IGNORING ANY (new) BAD BLOCKS IT FINDS.

If you want more information, go talk to Stskeeps on the IRC. He knows a lot about the raw nand flash and can explain it to you.

Solution: USE THIS VERSION OF BACKUPMENU. Not the one available in the repositories.

I'll test.

So reflashing doesn't do anything for bad blocks? I'm thinking the controller for the NAND should, after all, if the block is under the system image it's bricked. I'll take your advice and bother Stskeeps.

Anyway, after further investigation is seems I may have the cause of the errors. I don't want to throw stones just yet, I want to do several tests before I make a firm affirmation, but it seems it wasn't bad blocks that were the root of my problem, but a file system problem.

I am. And, I have made a backup and restored it successfully. Additionally, I have again triggered the error in my phone and BackupMenu v43 has successfully repaired the problem.

I am doing almost hourly backups as I diagnose the issue, so I'm giving the script a thorough check.

That's the whole point - there -is- no controller. This is what screwed me up with my previous version - I'm used to SD cards and HDs where you can go ahead and copy the entire partition or disk using dd, and everything works fine. In this case, I learn(way after the fact) that the OneNAND used on the N900(part of the CPU/SoC, btw) has no controller, and as such requires a special filesystem to handle it - This is the reason for Jffs2 and Ubifs.
When you write an image, it has to be a special "ubinized" version of the UbiFS. I'm betting that between that and the flasher utility, it works around bad-blocks, at least on the first write.
This would explain why, for some people, BackupMenu v.3x rootfs images would flash via the flasher, but not work if written back via dd.


Huh - Not sure how that'd work. My system's supposed to copy each file using "tar -cfp destination.tar /inputfolder" - There's only two "active" lines in the entire backup section!
I'd check that you don't have a missing or "corrupt" file in your input - When I used my own old version, I ended up with a couple of corrupt files, which weren't able to be read when backing it up with the new version, so they were missing in all subsequent backups. Fortunately, in my case, they were unused files(other languages).

Ah, good. I was worried about you using the old version because you were talking about checksums, which aren't used in the new version.

Also(just curious), did you restore your rootfs via BackupMenu, or did you make an image and flash it?

And, of course, feel free to edit/fix it - It's GPL after all. I would like to see any changes you think would improve it, however - I'd like some outside additions.

Robbie, the file in http://pastebin.org/287361 needed for producing a flashable rootfs isn't available any more. Would you please attach it in the forum or elsewhere for us to get? Thanks

Is this V2 you're talking about or the old version? Both SSH and USB networking worked on the older version and has saved me from doing a restore (from an out of date backup) on more than one occasion. If it doesn't work on V2, please, please get it working since terminal mode doesn't really work being able to use SSH is a lifesaver.

@debernardis:
Fixed the missing file.

@kureyon:
Huh, that's cool then. I'll see what I can do...

@debernardis:
Fixed the missing file.

@kureyon:
Huh, that's cool then. I'll see what I can do...

Thanks Robbie, but now there is another issue.
Since I had some problems in upgrading to pr1.3, I restored my backup done with your version 0.47. Everything went fine in restoring, but in the end I had some 10 megs free less in rootfs, i.e. about 27 megs. I reminded it was much more!
Thankfully, I had also a backup of the same rootfs done with your version 0.32 - the one saving in img format. So I restored with the old version, after having turned to the old backupmenu. In the end, I had 37 megs free.

How comes? Is it possible that untarring makes everything bigger?

Thanks for your patience

Did you reboot after checking? It might be the reclaim thing on UBI - IIRC it only releases or repacks or whatever in a reboot. The reboot just after restore wouldn't have cut it, because it's done on shutdown, not on power up.

Anyway, I take it it works fine in 1.3. Good to know.

Also, RobbieThe1st, when I said I may have isolated the problem in software I didn't mean yours. It seems that my troubles almost always begin when installing a package, or rather when a package I install pulls some dependencies.

E.g., installing Alarmed pulls several Python libs and in my last attempt doing that crashed it. I had Alarmed installed a long while with no issues, but at some point it went crazy because of an issue in Python - the list of alarms didn't update unless I restarted the app.

I've had problems ever since I started using Alarmed with the optified Python. I'm guessing that it nukes the cron or whatever it's called and some service fails to start.

Bootup takes way longer than usual and the error was this. Also, randomly, email takes huge gaps in updating. For example it sometimes doesn't update for hours until I start the email app then it resumes as normal.

Perhaps installing it and it finding some jobs in /opt convinces the application to re-insert the corrupt jobs in crond's list.

Still digging. But first, PR 1.3.

ETA: Doesn't work in 1.3 as far as I can tell. After "Mb reaches 254.8 it stops advancing. Time is around 30 or so. After that, time advances but no end in sight. By second 300, the Size: becomes empty, time still counts. No power button or keyboard controls. Needs a battery pull AFAICT.

ETA2: Reinstalling it seems to have fixed the issue.