Active Topics
-
Nokia Booklet 3G (RX-75) Drivers (60)
to Alternatives by Maemish - 14 hrs, 26 mins ago -
Is there a section to talk about Java ME? Apps, etc. (7)
to General by teroyk - 3 days, 10 hrs ago - more...
seanmcken |
2013-12-15
, 05:07
|
|
Posts: 863 |
Thanked: 213 times |
Joined on Feb 2012
@ Goa
|
#1291
|
Originally Posted by Estel
Hii, Any of yours custom mod's available in backupmenu, so we could use it, please'd you like to share? please?
 |
|
2013-12-15
, 14:44
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#1292
|
Erm, sure, but it wouldn't be much usable for anyopne except me - those are things like making ext4 instead of ext3 during partition recreation, mounting as ext4 instead of ext3 while doing backup, (both because I was too lazy to modify backupmenu a way that would make it detect filesystem used and ask which one to create while restoring) charging via kernel-power module bq2415x_charger instead of i2c scripts, etc. Ah, and while using compressed backup, lzma'ing it instead of .tar.gz (smaller filesize).
Frankly, I don't even completely remember what I've modified, and did everything to custom, so it wouldn't be too wise to throw it at anyone. For sure all my changes are kernel-power-only compatible.
Also, I've sent one of my first changes (in regular backupmenu form, not dependent on kernel-power) to robbiethe1st, ages ago - it was the lzma thing. He never included it, so I wasn't much motivated to keep compatibility with "upstream" backupmenu
---
In list of things that I would like to do One Day When I Got Free Time(tm), (which is, probably, something about 40 years in future... Maybe.) is to rewrite Backupmenu entirely dropping text2screen, using framebuffer output only - loaded even earlier than current Backupmenu (as The Very First Thing[tm] in /sbin/preinit, like Mentalist Traceur's recovery console, which I'm using, too), with CL interface.
Until that, I'm anyway using only backup, restore, and recovery shell functions from backupmenu (issuing fsck's from recovery terminal, as I was too lazy to modify backupmenu's fsck scripts, too), and in case of something broken earlier, a preinit recovery console, mentioned earlier.
/Estel
Frankly, I don't even completely remember what I've modified, and did everything to custom, so it wouldn't be too wise to throw it at anyone. For sure all my changes are kernel-power-only compatible.
Also, I've sent one of my first changes (in regular backupmenu form, not dependent on kernel-power) to robbiethe1st, ages ago - it was the lzma thing. He never included it, so I wasn't much motivated to keep compatibility with "upstream" backupmenu
---
In list of things that I would like to do One Day When I Got Free Time(tm), (which is, probably, something about 40 years in future... Maybe.) is to rewrite Backupmenu entirely dropping text2screen, using framebuffer output only - loaded even earlier than current Backupmenu (as The Very First Thing[tm] in /sbin/preinit, like Mentalist Traceur's recovery console, which I'm using, too), with CL interface.
Until that, I'm anyway using only backup, restore, and recovery shell functions from backupmenu (issuing fsck's from recovery terminal, as I was too lazy to modify backupmenu's fsck scripts, too), and in case of something broken earlier, a preinit recovery console, mentioned earlier.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2013-12-15
, 16:17
|
|
Posts: 863 |
Thanked: 213 times |
Joined on Feb 2012
@ Goa
|
#1293
|
Originally Posted by Estel
thankk you, actually is ext4 perfect for everyone??? cuz i heard its fast than ext3, the way said ur mod's i think ur phone works like an jet plane, my god ur phone'd b real fast.
Erm, sure, but it wouldn't be much usable for anyopne except me - those are things like making ext4 instead of ext3 during partition recreation, mounting as ext4 instead of ext3 while doing backup, (both because I was too lazy to modify backupmenu a way that would make it detect filesystem used and ask which one to create while restoring) charging via kernel-power module bq2415x_charger instead of i2c scripts, etc. Ah, and while using compressed backup, lzma'ing it instead of .tar.gz (smaller filesize).
Frankly, I don't even completely remember what I've modified, and did everything to custom, so it wouldn't be too wise to throw it at anyone. For sure all my changes are kernel-power-only compatible.
Also, I've sent one of my first changes (in regular backupmenu form, not dependent on kernel-power) to robbiethe1st, ages ago - it was the lzma thing. He never included it, so I wasn't much motivated to keep compatibility with "upstream" backupmenu
---
In list of things that I would like to do One Day When I Got Free Time(tm), (which is, probably, something about 40 years in future... Maybe.) is to rewrite Backupmenu entirely dropping text2screen, using framebuffer output only - loaded even earlier than current Backupmenu (as The Very First Thing[tm] in /sbin/preinit, like Mentalist Traceur's recovery console, which I'm using, too), with CL interface.
Until that, I'm anyway using only backup, restore, and recovery shell functions from backupmenu (issuing fsck's from recovery terminal, as I was too lazy to modify backupmenu's fsck scripts, too), and in case of something broken earlier, a preinit recovery console, mentioned earlier.
/Estel
 |
|
2013-12-15
, 20:46
|
|
Posts: 6,445 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#1294
|
Once upon a time, I posted a suggestion how to update BackupMenu to format to the current file system on restore as opposed to the hardcoded ext3. It requires a small change to one of the scripts but also updating the tar file with all the binaries and as such should not be attempted by noobs.
I've made a bunch of other changes as well but have since reflashed my phone at least three times and it was a hassle to retrace my steps every time so eventually I ended up with the default, vanilla, unaltered BackupMenu from the repos.
I've made a bunch of other changes as well but have since reflashed my phone at least three times and it was a hassle to retrace my steps every time so eventually I ended up with the default, vanilla, unaltered BackupMenu from the repos.
| The Following 3 Users Say Thank You to pichlo For This Useful Post: | ||
 |
|
2014-01-25
, 04:16
|
|
Posts: 283 |
Thanked: 276 times |
Joined on Aug 2011
@ uk or @Pai,Mae Hong Son, Thailand
|
#1295
|
I have two N900's
Number 2, no problems whatsoever, backup regularly with BackupMenu without errors.
Number 1, for some time when attempting backup I get the following error:-
Errors: 1 Last gtar ./var/lib/dpkg/info/mafw-tracker-source.postinst: Warning: Cannot stat: Structure needs cleaning.
BackupMenu just sits there then counting up the time with no Size increase. I have to abort with the 'hold' switch..
Incidentally, fsck runs clean.
Also, if I run a 'find' from a terminal I get:-
sudo find / -name fred
find: /var/lib/dpkg/info/mafw-tracker-source.postinst: Structure needs cleaning
I have reflashed number 1 (a number of times) and restored from a backup created from number 2 but I still get the same problem!
Can anyone explain this? The problem still exists AFTER A REFLASH of both COMBINED and VANILLA!
I would dearly like to fix this.
Mystified
Last edited by macey; 2014-01-25 at 04:45.
Number 2, no problems whatsoever, backup regularly with BackupMenu without errors.
Number 1, for some time when attempting backup I get the following error:-
Errors: 1 Last gtar ./var/lib/dpkg/info/mafw-tracker-source.postinst: Warning: Cannot stat: Structure needs cleaning.
BackupMenu just sits there then counting up the time with no Size increase. I have to abort with the 'hold' switch..
Incidentally, fsck runs clean.
Also, if I run a 'find' from a terminal I get:-
sudo find / -name fred
find: /var/lib/dpkg/info/mafw-tracker-source.postinst: Structure needs cleaning
I have reflashed number 1 (a number of times) and restored from a backup created from number 2 but I still get the same problem!
Can anyone explain this? The problem still exists AFTER A REFLASH of both COMBINED and VANILLA!
I would dearly like to fix this.
Mystified
Last edited by macey; 2014-01-25 at 04:45.
| The Following User Says Thank You to macey For This Useful Post: | ||
|
|
2014-01-25
, 13:13
|
|
Posts: 2,102 |
Thanked: 1,937 times |
Joined on Sep 2008
@ Berlin, Germany
|
#1296
|
Couple of things come to my mind to test:
Did you try the file system check from a PC running Linux, either installed or Live-CD?
The version of fsck built into backupmenu and also Maemo are ancient, you will get better results from a PC.
Did you try to move the file, thereby not erasing the file completely but testing the read/write abilities of the rootfs.
You could also check the location of the real file
Good luck!
Did you try the file system check from a PC running Linux, either installed or Live-CD?
The version of fsck built into backupmenu and also Maemo are ancient, you will get better results from a PC.
Did you try to move the file, thereby not erasing the file completely but testing the read/write abilities of the rootfs.
You could also check the location of the real file
Code:
ls -al /var/lib/dpkg/info/mafw-tracker-source.postinst
| The Following User Says Thank You to michaaa62 For This Useful Post: | ||
|
|
2014-01-25
, 15:11
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#1297
|
Originally Posted by michaaa62
While absolutely true, it is worth to mention, that latest cssu-testing fixed it (backporting upstream e2fsprogs & friends). Also, backupmenu doesn't have any "built-in" fsck - AFAIK - it just copies one found in Maemo. So, having working fsck from cssu-testing means, that it will work in backupmenu too.
The version of fsck built into backupmenu and also Maemo are ancient, you will get better results from a PC.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following 3 Users Say Thank You to Estel For This Useful Post: | ||
|
|
2014-01-25
, 18:09
|
|
Posts: 2,102 |
Thanked: 1,937 times |
Joined on Sep 2008
@ Berlin, Germany
|
#1298
|
that latest cssu-testing fixed it (backporting upstream e2fsprogs & friends)
Thanks! And..You are right about backupmenu using rootfs and therefore /bin and /sbin binaries.
To my rescue, may be: There is no mention of CSSU in @macey's post
| The Following User Says Thank You to michaaa62 For This Useful Post: | ||
|
|
2014-01-26
, 03:05
|
|
Posts: 283 |
Thanked: 276 times |
Joined on Aug 2011
@ uk or @Pai,Mae Hong Son, Thailand
|
#1299
|
Originally Posted by michaaa62
I have a linux PC, just how do I do a (complete) file system check? Presumably using one of the usb options on BackupMenu? Which option? I thought that these facilities leave some of the file systems mounted to the N900 & hence not fsck checkable?
Couple of things come to my mind to test:
Did you try the file system check from a PC running Linux, either installed or Live-CD?
The version of fsck built into backupmenu and also Maemo are ancient, you will get better results from a PC.
Did you try to move the file, thereby not erasing the file completely but testing the read/write abilities of the rootfs.
You could also check the location of the real fileGood luck!Code:ls -al /var/lib/dpkg/info/mafw-tracker-source.postinst
Tried to move the file, got the same error.
ls -al also gives the same error..
|
|
2014-01-26
, 03:33
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#1300
|
Frankly, I have never, ever, heard of anything like that in N900 - especially that, as you claim, full reflash of vanilla+combined doesn't fix it.
I would suggest to check for bad blocks via fsck, but, considering that eMMC have transparent hardware wear leveling, no bad block should manifest itself on the same file twice, after reflash.
But, isn't /var/lib/dpkg/info/mafw-tracker-source.postinst on rootfs? It would explain why fsck turns out clean, as it's fsck'ing only /dev/mmcblk0p2. Also, storage used for rootfs *doesn't* have hardware leveling (thankfully), wear control is implemented via ubifs on filesystem level.
Thus, it is possible that during every reflash, the same bit of information (file in question) land on exactly same block. It the block is damaged, file ends corrupted. I'm not aware of any fsck-like tools for ubifs (fixme?), as it's completely resistant to logical filesystem corruption. Probably, it have some tools to handle physically damaged blocks, but it would require digging into ubifs documents.
No matter what, take all of the above with a grain of salt - it's just theory that popped up in my head, while writing this very post. I may be wrong totally (as I don't have possibility to check this file physical location right now), or in any of mentioned things.
Nevertheless, you may workaround your problem by editing backupmenu code (the line where it tar's your files into backup), using tar option to exclude given path from backup (see tar --help). This will produce valid backup lacking this one problematic file - for .postinst in question, it shouldn't be problem. at all. Unless my theory about bad rootfs block is valid, and, after recovering backup, you will end with another file (from backup) jumping into corrupted position of mafw-tracker-source.posints... But, there is a good chance, that as bad block it wouldn't be removable too, during rootfs nuking phase of recovering backup.
/Estel
I would suggest to check for bad blocks via fsck, but, considering that eMMC have transparent hardware wear leveling, no bad block should manifest itself on the same file twice, after reflash.
But, isn't /var/lib/dpkg/info/mafw-tracker-source.postinst on rootfs? It would explain why fsck turns out clean, as it's fsck'ing only /dev/mmcblk0p2. Also, storage used for rootfs *doesn't* have hardware leveling (thankfully), wear control is implemented via ubifs on filesystem level.
Thus, it is possible that during every reflash, the same bit of information (file in question) land on exactly same block. It the block is damaged, file ends corrupted. I'm not aware of any fsck-like tools for ubifs (fixme?), as it's completely resistant to logical filesystem corruption. Probably, it have some tools to handle physically damaged blocks, but it would require digging into ubifs documents.
No matter what, take all of the above with a grain of salt - it's just theory that popped up in my head, while writing this very post. I may be wrong totally (as I don't have possibility to check this file physical location right now), or in any of mentioned things.
Nevertheless, you may workaround your problem by editing backupmenu code (the line where it tar's your files into backup), using tar option to exclude given path from backup (see tar --help). This will produce valid backup lacking this one problematic file - for .postinst in question, it shouldn't be problem. at all. Unless my theory about bad rootfs block is valid, and, after recovering backup, you will end with another file (from backup) jumping into corrupted position of mafw-tracker-source.posints... But, there is a good chance, that as bad block it wouldn't be removable too, during rootfs nuking phase of recovering backup.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 |
| Tags |
| backup, backupmenu, cssusupplement, max(useful), rescue-console, restore, system |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 23:18.