Notices

Doing "strace passwd -S root" would suggest that you need the /etc/nsswitch.conf file (I'd suggest creating a basic one rather than copying the existing one) and /lib/libnss_files.so.2.

I looked in the conf file - It looked pretty plain to me, so I just copied it and the .so over. The passwd command worked, and SSH login works also(!)
It wouldn't CD to /root as that didn't exist though, so I've got to have my script make that dir...
Lets see...
edit:
First attempt gave me an error "PTY allocation request failed on channel 0"
I then mounted /dev/pts on the new filesystem, and also created /dev/pmtx, tried it... and it WORKED!
Tomorrow, look forward to full SSH access to your n900 in BackupMenu. This should allow for custom fixes and such.

Great news! that might save us some reflashing / restoring loops when something got broken.
BTW: did ssh login ever work with backupmenu before? I tried with earlier version (something pre 0.32) but I never succeeded with login and was quite sure it must have been some broken config on my device therefore never complained about that.

It -may- have with v0.32 and -earlier-, but I never used it. After moving to a ramdisk-based system in v0.4x, I thought I got it working several times, but I apparently didn't.

Here's a question for you guys:
SSH mode now works, meaning that when you boot into backupmenu and connect your computer to your n900 over ssh, you will have full root access.

Should I:
1. Copy -your- ssh config & password? This might be slighty more secure, with someone needing your password as well as physical access to the device(though, I suppose, someone could simply back things up and copy it all off..)
2. Use a -default- ssh config and password? This would mean that anyone with physical access to your n900, knows what backupmenu and ssh do, and can connect it to a pc could gain access to it. However, it would also mean that you could fix problems involving broken passwords and the like.

I vote for a default sshd config and passwd.

Security is completely compromised when somebody has physical access to the medium.

That's sort of my thinking also, but if more people want to use it the other way... I'm trying to get as many people to use it as possible, because of the number of people who end up screwing with something they shouldn't, ending up with a non-bootable OS, and not being able to recover, backup, or fix -anything- without reflashing.

hawaii, in general (I agree with you in this context - I'm talking over-all, which is what you seem to be making a claim about), I would say that's starting to not apply. In principle, I still agree with you. However, in practice, better security can mean the difference between somebody bothering to continue trying, and giving up. Up to and including the FBI trying to months and deciding that they can't get in (if you can't find the case I'm talking about, and actually care, feel free to ask for a link).

However, in this case, I side with default config/password - because in this case the SSH really isn't there for security, it's there as a fallback position when you can't boot. As mentioned, if you know how to work with backupmenu, which you'd need to at least partially to figure out how to use the default SSH password/config from option 2, then you can probably figure out in option 1 that you can just back up everything and move the backups elsewhere.

In this case, the SSH really only seems to come in when you're having booting problems. In this case, with the N900 and bootmenu, hawaii is right in so far as security being compromised with physical access. If you can get into bootmenu, if you bother to lookup and understand how bootmenu works, you can probably figure out how to backup and move the backups off device about as easily as you can lookup the default SSH config and how to use it.

Yes, in principle the more layers of security (albeit this is slightly above obscurity) is better to deter an attack. However, given the specific issue at hand, it is almost irrelevant. I dare say, you could go as far as to disable an interactive login and drop the user to a suid shell right off the bat.

A specific set list of events have to occur for any single user to be able to get to that shell - and the risk of that is so low, there's almost no reason to mitigate against it, while increasing the possibility of alienation to regular users.

this app doesnt seem to work for me.............

I backup Opt + RootFS to SD (no compression).
when I go to restore, it says "mmcblk1p1/systemBackups: not a directory".
It says this even straight after doing backup..

edit: also says "systemBackups: not a directory" when I backup to MyDocs..... WTF?

I tried restoring backup last night but it totally ****ed my phone, had to reflash. Still doesnt work with newly flashed phone.

Nice.

Check via usb mode - can you see a "systemBackups" directory after backup? If so, and there are rootfs and optfs images in it, it should be possible to restore using the -next- version, once I figure out what went wrong.

Also, did you get -any- error during the backup process?

Edit:
Oh, and what version did you install? It would say at the top of each BackupMenu screen, or when you installed it.