Active Topics
-
The N900 is now 15 years old! (8)
to Nokia N900 by whayong - 11 hrs, 27 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 7 hrs ago - more...
| The Following User Says Thank You to x-lette For This Useful Post: | ||
|
2010-12-03
, 15:47
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#422
|
Another idea about the password.
Why not even enable user to set backupmenu such a way, if one wants, that it will ask password always wether keyboard was open or closed during the boot? As the default security code in N900 is DES-based, having some other <safe> encryption used as a "BIOS password" would be nice.
Have I understood correctly, backupmenu is located in a /dev/mtd0 in the bootloader area (this could be mentioned in the wiki page)? Flashing kernel, rootfs and eMMC will not override backupmenu? Is it possible to flash bootloader separately when the device is in flash-mode connected with USB?
Last edited by zimon; 2010-12-03 at 15:50.
Why not even enable user to set backupmenu such a way, if one wants, that it will ask password always wether keyboard was open or closed during the boot? As the default security code in N900 is DES-based, having some other <safe> encryption used as a "BIOS password" would be nice.
Have I understood correctly, backupmenu is located in a /dev/mtd0 in the bootloader area (this could be mentioned in the wiki page)? Flashing kernel, rootfs and eMMC will not override backupmenu? Is it possible to flash bootloader separately when the device is in flash-mode connected with USB?
Last edited by zimon; 2010-12-03 at 15:50.
|
|
2010-12-03
, 16:01
|
|
Posts: 3,617 |
Thanked: 2,412 times |
Joined on Nov 2009
@ Cambridge, UK
|
#423
|
Originally Posted by zimon
No, backupmenu is a simple script installed on the rootfs. Bootmenu/multiboot handle the early stages, but I'm pretty sure they don't replace the bootloader either (again, I think they're just scripts that replace the default init process) - uboot probably does though.
Have I understood correctly, backupmenu is located in a /dev/mtd0 in the bootloader area (this could be mentioned in the wiki page)? Flashing kernel, rootfs and eMMC will not override backupmenu? Is it possible to flash bootloader separately when the device is in flash-mode connected with USB?
|
|
2010-12-04
, 09:42
|
|
Posts: 842 |
Thanked: 1,197 times |
Joined on May 2010
|
#424
|
Originally Posted by zimon
I'm slightly lost here - I thought that everyone who is not able to get their code via the mtd1 method was -also- not able to login with -any- code?
There are few others who have this "problem" also, that there is not coming anything looking like DES encryption after the string "lock_code" in /dev/mtd1
I wonder, if this is a patent thing, and in some parts of the world Nokia has indeed used other encryption than DES.
Or if it indeed is some kind of fortunate seldom triggered bug, that makes the device harder to crack.
And forgot to mention, I have in settings, that in 10 minutes of idle usage, the device will lock itself with the security code. I think that is why it asks the security code every time it boots up, also after full rootfs+rMMC reflash. I guess people normally do not have that auto security lock enabled and haven't noticed it does survive over reflash also. (which seems to be a good thing).
Now, one thing I -did- notice was that when I was testing out that /dev/mtd1 grabber script, the -first- time I tested it with root console, I got my encrypted code. The -second- and all following times, I got a blank string back.
However, when I ran that command via SSH inside BackupMenu, I was able to get the code -every- time I tried, with several different codes.
This may just be an issue of luck, or perhaps something ends up locking it up -sometimes-.
Either way, would you mind trying to grab it by installing BackupMenu and SSH server, then logging in and running "getlockcode" from the console? I'd like to see if it's an OS thing, or there -is- something different here.
@zimon: Rob1n is correct. It's just a script that relies on bootmenu-n900 for all the actual boot stuff. In fact, I'm not entirely sure quite how bootmenu-n900 actually works; I'm sure I was told at one point or another, but I've forgotten.
What I do know, though, is that if I put an ash-script file inside /etc/bootmenu.d/ with the extension .item, it will run that code during boot with the keyboard open.
Now, what's -supposed- to happen is that bootmenu-n900 will read all files and get menu items out of them as encoded variables. What -actually- happens is that it tries to read my script, which "hijacks" it, keeping control. This is why, when BackupMenu fails, it drops to the default bootmenu-n900 prompt.
Now, I'd like to figure out how to get a proper bootmenu-n900 compatible file there, so they can be run side-by-side, but I can't figure it out quite.
__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
| The Following User Says Thank You to RobbieThe1st For This Useful Post: | ||
 |
|
2010-12-05
, 19:23
|
|
Posts: 1,396 |
Thanked: 2,796 times |
Joined on Sep 2010
@ Caracas, Venezuela
|
#425
|
Can BackupMenu be NOT dependable of bootmenu? Because I have it installed using multiboot. I had to force install the deb package, and then tar the result, uninstall the package, untar the result.
That's the only way I don't get the failed dependences everytime I want to use apt-get for another package.
I guess there are others around here using multiboot instead of bootmenu as well...
That's the only way I don't get the failed dependences everytime I want to use apt-get for another package.
I guess there are others around here using multiboot instead of bootmenu as well...
|
|
2010-12-05
, 20:52
|
|
Posts: 284 |
Thanked: 320 times |
Joined on May 2010
@ Peterborough, UK
|
#426
|
Originally Posted by debernardis
Well, I finally got around to testing this tonight - in the process figuring out that mkfs.ubifs actually works with the real rootfs partition when Maemo is running, as long as you create a chrooted environment first - and was very surprised with the results. Not only does zlib compression create a smaller image file (both pre- and post- ubinize) than lzo, but it's also much faster and yes, results in a lot more free space once that image is then written to simulated NAND (via nandwrite, with a flash_eraseall prior to that) - it rose from around 66Mb to 84Mb. I'm now going to try to add it to the backupmenu script - it should be doable as the setup-chroot script that I wrote was based on BackupMenuLauncher.item; not tonight, though
I have tested alternative compression types on my rootfs.tar.
Using no parameter in the mkfs.ubifs command, as above, gives a finale img file 192,806,912 bytes large.
Using zlib compression like that:or a mixed compression like that:Code:mkfs.ubifs -x zlib -m 2048 -e 129024 -c 2047 -R 4MiB -r ./rootfs/ -v ./base.ubi.imggives a much smaller img file to flash: 168,951,808 bytes.Code:mkfs.ubifs -x favor_lzo -X 5 -m 2048 -e 129024 -c 2047 -R 4MiB -r ./rootfs/ -v ./base.ubi.img
The difference is quite large: 23,855,104 bytes.
Maybe this is the key to the problem of disappearing space when restoring.
I am not in the mood of trying a restore - I need my N900 working... but someone more inclined to experiments could try and see if flashing images with different compression types results in different free space in the rootfs.
| The Following User Says Thank You to Tigerite For This Useful Post: | ||
 |
|
2010-12-05
, 21:29
|
|
Posts: 1,030 |
Thanked: 792 times |
Joined on Jun 2009
|
#427
|
Originally Posted by Scorpius
You can edit the control file and remove that dependency. Or grab the binary package, remove the gzipped tarball and extract it manually.
Can BackupMenu be NOT dependable of bootmenu? Because I have it installed using multiboot. I had to force install the deb package, and then tar the result, uninstall the package, untar the result.
That's the only way I don't get the failed dependences everytime I want to use apt-get for another package.
I guess there are others around here using multiboot instead of bootmenu as well...
It's fine the way it is, as far as I am concerned - it works for a new user, and anybody else who wants to toy with it and colliding packages - should understand how to fix these problems, in any case.
|
|
2010-12-06
, 06:56
|
|
Posts: 842 |
Thanked: 1,197 times |
Joined on May 2010
|
#428
|
Originally Posted by Tigerite
Even easier than that - BackupMenu.item is all run inside a chroot and the NAND Rootfs is -unmounted-.
Well, I finally got around to testing this tonight - in the process figuring out that mkfs.ubifs actually works with the real rootfs partition when Maemo is running, as long as you create a chrooted environment first - and was very surprised with the results. Not only does zlib compression create a smaller image file (both pre- and post- ubinize) than lzo, but it's also much faster and yes, results in a lot more free space once that image is then written to simulated NAND (via nandwrite, with a flash_eraseall prior to that) - it rose from around 66Mb to 84Mb. I'm now going to try to add it to the backupmenu script - it should be doable as the setup-chroot script that I wrote was based on BackupMenuLauncher.item; not tonight, though
All you've got to do is copy the files you need in the launcher, then inside BackupMenu.item you can mount the rootfs and whatever partition you want to store to, then run your code.
You can easily use existing stuff, too - Just stick your code after "#Put your test code after this comment." and when you press a key(L, I think it is), any code there will be run.
You may need to setup a loop for feedback like I've done with tar, but there's plenty of examples there.
__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
| The Following User Says Thank You to RobbieThe1st For This Useful Post: | ||
|
|
2010-12-06
, 11:06
|
|
Posts: 284 |
Thanked: 320 times |
Joined on May 2010
@ Peterborough, UK
|
#429
|
Yep, I noticed that - it's what pointed me to chrooting on-device to try to use mkfs.ubifs 
By the way, why is the /tmp folder ignored during the tar process? It's empty anyway on the NAND - it's only there as a mount point, so copying it is harmless, surely? I only ask because I can't remove that during the mkfs.ubifs process.
By the way, why is the /tmp folder ignored during the tar process? It's empty anyway on the NAND - it's only there as a mount point, so copying it is harmless, surely? I only ask because I can't remove that during the mkfs.ubifs process.
|
|
2010-12-06
, 12:24
|
|
Posts: 842 |
Thanked: 1,197 times |
Joined on May 2010
|
#430
|
IIRC, for whatever reason -some- application ended up sticking a persistent fifo or device file inside it - something that couldn't be copied for whatever reason, and produced an error when tarring. So, I just excluded everything -inside- of the directory, though the directory itself gets copied.
__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
| The Following User Says Thank You to RobbieThe1st For This Useful Post: | ||
 |
| Tags |
| backup, backupmenu, cssusupplement, max(useful), rescue-console, restore, system |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 12:58.
But to be honest, I don't have a clue what modifications Nokia made to system, kernel, modules and handling of all of them. The 'current' symlink should just be a convenient way to access the current's kernel modules without having first to find out the exact revision number. Kernel internally should always use the full qualified modules path (e.g. /lib/modules/<myrevision>). But there might be chances that some external software relies on such a link, even if i doubt. In the end, all alternate kernels are working troublefree, so you might check whether they are installing such a link.