Hmm...I just realized what the problem probably is.

Try opening a shell using the following (incredibly long) command, then launch the chroot:

opensh -c 'aegis-exec -c -a CAP::chown -a CAP::dac_override -a CAP::dac_read_search -a CAP::fowner -a CAP::fsetid -a CAP::kill -a CAP::setgid -a CAP::setuid -a CAP::setpcap -a CAP::linux_immutable -a CAP::net_bind_service -a CAP::net_broadcast -a CAP::net_admin -a CAP::net_raw -a CAP::ipc_lock -a CAP::ipc_owner -a CAP::sys_module -a CAP::sys_rawio -a CAP::sys_chroot -a CAP::sys_ptrace -a CAP::sys_pacct -a CAP::sys_admin -a CAP::sys_boot -a CAP::sys_nice -a CAP::sys_resource -a CAP::sys_time -a CAP::sys_tty_config -a CAP::mknod -a CAP::lease -a CAP::audit_write -a CAP::audit_control -a CAP::setfcap -a CAP::mac_override -a CAP::mac_admin sh'

Here is the error return

Chroot dir specified: /.debian
/home/user/MyDocs/bt5/bt5.img.ext4 specified in ~/.chroot
Mounting...
using image file: /home/user/MyDocs/bt5/bt5.img.ext4
fs type is ext4
Using ext4 file system
FATAL: Module ext4 not found.
mounting /home/user/MyDocs/bt5/bt5.img.ext4 on loop
.../home/user/MyDocs/bt5/bt5.img.ext4 mounted on loop0
.
..
...
....
/bin/qchroot: line 145: blkid: not found
/bin/qchroot: line 156: blkid: not found
Everything set up, running chroot...
chroot: can't execute '/bin/develsh': No such file or directory


Manually "chroot /.debian/ /bin/sh"
/ # chroot /.debian/ /bin/sh
chroot: can't execute '/bin/sh': Operation not permitted

OK, now do dmesg | tail -50 and post any Aegis error messages you see there.

here you are..

[15542.224365] credp: chroot: credential 0::21 not present in source SRC::9990006
[15542.224395] credp: chroot: credential 0::27 not present in source SRC::9990006
[15542.224456] credp: chroot: credential 0::32 not present in source SRC::9990006
[15542.224487] credp: chroot: credential 0::33 not present in source SRC::9990006
[15542.224517] Aegis: credp_kcheck failed 9990006 bash
[15542.224548] Aegis: bash verification failed (source origin check)
[15546.575714] credp: chroot: credential 0::1 not present in source SRC::9990006
[15546.575775] credp: chroot: credential 0::6 not present in source SRC::9990006
[15546.575805] credp: chroot: credential 0::7 not present in source SRC::9990006
[15546.575836] credp: chroot: credential 0::16 not present in source SRC::9990006
[15546.575866] credp: chroot: credential 0::17 not present in source SRC::9990006
[15546.575897] credp: chroot: credential 0::21 not present in source SRC::9990006
[15546.575927] credp: chroot: credential 0::27 not present in source SRC::9990006
[15546.575958] credp: chroot: credential 0::32 not present in source SRC::9990006
[15546.575988] credp: chroot: credential 0::33 not present in source SRC::9990006
[15546.576019] Aegis: credp_kcheck failed 9990006 bash
[15546.576049] Aegis: bash verification failed (source origin check)
[15553.154815] credp: chroot: credential 0::1 not present in source SRC::9990006
[15553.154876] credp: chroot: credential 0::6 not present in source SRC::9990006
[15553.154907] credp: chroot: credential 0::7 not present in source SRC::9990006
[15553.154937] credp: chroot: credential 0::16 not present in source SRC::9990006
[15553.154968] credp: chroot: credential 0::17 not present in source SRC::9990006
[15553.154998] credp: chroot: credential 0::21 not present in source SRC::9990006
[15553.155029] credp: chroot: credential 0::27 not present in source SRC::9990006
[15553.155059] credp: chroot: credential 0::32 not present in source SRC::9990006
[15553.155090] credp: chroot: credential 0::33 not present in source SRC::9990006
[15553.155120] Aegis: credp_kcheck failed 9990006 bash
[15553.155151] Aegis: bash verification failed (source origin check)
[15556.521179] credp: chroot: credential 0::1 not present in source SRC::9990006
[15556.521209] credp: chroot: credential 0::6 not present in source SRC::9990006
[15556.521240] credp: chroot: credential 0::7 not present in source SRC::9990006
[15556.521270] credp: chroot: credential 0::16 not present in source SRC::9990006
[15556.521331] credp: chroot: credential 0::17 not present in source SRC::9990006
[15556.521362] credp: chroot: credential 0::21 not present in source SRC::9990006
[15556.521392] credp: chroot: credential 0::27 not present in source SRC::9990006
[15556.521423] credp: chroot: credential 0::32 not present in source SRC::9990006
[15556.521453] credp: chroot: credential 0::33 not present in source SRC::9990006
[15556.521484] Aegis: credp_kcheck failed 9990006 bash
[15556.521514] Aegis: bash verification failed (source origin check)
[15558.726684] credp: chroot: credential 0::1 not present in source SRC::9990006
[15558.726745] credp: chroot: credential 0::6 not present in source SRC::9990006
[15558.726776] credp: chroot: credential 0::7 not present in source SRC::9990006
[15558.726806] credp: chroot: credential 0::16 not present in source SRC::9990006
[15558.726837] credp: chroot: credential 0::17 not present in source SRC::9990006
[15558.726867] credp: chroot: credential 0::21 not present in source SRC::9990006
[15558.726898] credp: chroot: credential 0::27 not present in source SRC::9990006
[15558.726928] credp: chroot: credential 0::32 not present in source SRC::9990006
[15558.726989] credp: chroot: credential 0::33 not present in source SRC::9990006
[15558.727020] Aegis: credp_kcheck failed 9990006 bash
[15558.727050] Aegis: bash verification failed (source origin check)

Well that is not true, you don't have to disable aegis entirely by echo 0.

Its enough just to echo 0x25 > /sys/kernel/security/validator/enabled

And then all unsigned binaries run just fine (and it also removes source origin check errors that above post has). Of course you first need to insmod kernel module which removes the seal bit so you can write to that file.

/bin # echo 0x25 > /sys/kernel/security/validator/enabled
sh: write error: Operation not permitted

#manually write to /sys/kernel/security/validator/enabled
/bin # cat /sys/kernel/security/validator/enabled
0x1e7

still seeing
/bin # debian
sh: debian: Operation not permitted

Looks like this is a bit trickier than I'd hoped.

Globally disabling origin checking (as above) ought to do the trick, but if full root access isn't needed inside the chroot, it should suffice to:

a) install the chroot scripts from a package, requesting the needed credentials to set up the bind mounts etc.
b) relinquish those credentials when it comes time to actually start the chroot

Something such as /usr/bin/aegis-exec -c -a CAP::sys_chroot /bin/chroot /path/to/jail /sbin/capsh --caps='' -- -c '/path/to/payload' ought to work (this requires libcap2-bin inside the jail)

Also, @z720 - rainisto's suggestion only works if Aegis is "unsealed", which isn't the case on a fully booted system. It should be possible to change this, but that requires a kernel module that no one has put together yet for current kernel versions.

You should read the whole post, I clearly said that you will get permission denied if you don't disable the seal bit which is protecting that file. If you don't know how to make (or where to get) such a kernel module, then your out of luck.

And yes I have a working module which does that in PR1.2, and no, I will not post it on this forum.

This is because this is an Aegis crack and not open mode; like with the beta cracks, you will need to insmod unseal.ko .
And you will also need to still request permissions manually and so on for all packages.

Personally, I think this is the wrong approach to take (as explained in the original FMC aegis thread), exploring the real open mode is much more promising and future proof.

Well, if you boot to Open Mode with stock kernel, you still need to insmod module in order to make aegis less strict (I've written my module originally for open mode stock kernel). Its only when you boot to open mode with Aegis cracked kernel when things are easier.

Open mode is future proof, yes, most likely it will not get blocked. But Open Mode has a disadvantage in the fact that CAL nand area is always read-only. So unless you rewrite all the system modules that use CAL to not to use it (and as most of the services using cal are not open sourced) then you will never have 100% matching functionality to Closed Mode phone while being Open Mode. You can get near 99.5% by rewriting most common usecases, like reimplementing devicelock, but I have not seen any open mode developers doing that kind of rewrites.

Using exploits in Closed Mode is wrong approach too, since its quite likely that public exploits are going to be fixed if it poses thread of being misused by malware.

In optimal perfect world there would either be
A) com.nokia.maemo signed imei based develsh package that you would buy from ovi store or something, and which needs some manual/visual confirmation (so malware cannot install it without user noticing) before it is installed. That way nobody would need to use any exploits in order to get full access to their hardware and software.
B) Or the other way around if open mode would not trigger CAL to read-only.
C) Closed mode would not have SEAL_BIT enabled (if you enable R&D mode with flasher) and develsh privileges would be able to edit the file.
D) bootloader is changed to trust even unsigned kernels

But we do not live in perfect world... and most likely A, B, C or D will never happen. But you can always hope for the miracle.

Disclaimer: this is only my personal opinion, like all my posts. IMHO Aegis is a good thing and it protects file integrity quite well, and it should not be disabled even on open mode, but in some occasions policies might need do be a bit less strict if your a developer who is doing experimental stuff to their own device.