Hi guys,
I'm a milestone owner, and very happy with this device, I've upgraded it with 1,1ghz ULV module, memhack, busybox and JIT and it's a lighting, but here is a question that I have:
I'm a linux user so I started to "play" with the busybox addon of the terminal (straight on the device), I am also a maemo user where the swap file was usual to create on the sd to make the device more usable;
Now, how about the milestone? Using the swapper app in the market, it seems to not work (using "busybox free"in the terminal doesn't show me any swap) so how to enable a swap file or partition on the milestone? I think it will help a lot for the memory hungry systems, themes, and on developing roms linke the Dexter's froyo and sense mods (which lacks on the ram front)
Have anyone managed to have swap to work on the milestone? or Is out there any guide to do it?
This sounds like an excellent idea. As I am also a linux (Ubuntu 10.04) user too, having a swap "partition" on your Milestone will give "memory hungry" applications exactly what the need.
Will be watching this Thread!
Yeah, my question is about the fact that other phones (i heard about spica,dream,g1) have this feature, but the common command on linux/maemo does not work :/
Hope there is a solution :-(
So guys, the problem is in the kernel I frear...
using busybox, I've managed to create a small 128mb partition, and also a. Swap file (to test), but the function
"Swapon" says it's" not implemented" so where is the origin of the pWow thats strange that nobody tried ;-( ok I will try to find a solution and I will report back what I find. Hope to have skme help lol xD
Edit:
so" not implemented" is in the swapper2 application; doind it in the terminal these are the results:
export PATH=/data/local/bin:$PATH
$ su
# busybox swapon
BusyBox v6905964.73458437589.3945345.RELEASE_FROM_FUTURE (2010-04-10 21:43:08 MSD) multi-call binary.
Usage: swapon [-a] [-p PRI] [DEVICE]
Start swapping on DEVICE
Options:
-a Start swapping on all swap devices
-p PRI Set swap device priority
# busybox swapon -a
swapon: /etc/fstab: No such file or directory
# busybox swapon -a /sdcard
swapon: /etc/fstab: No such file or directory
# sudo gedit /etc/fstab
sudo: not found
# gedit /etc/fstab
gedit: not found
# vi /etc/fsteb
vi: not found
So thats it....what is this fstab file?? I know its about partition table or something like that, but why we lack it? We have to figure how to implement it...maybe in that way the swap can be set via busybox... help :-(
#roblem??? :-( help!
Looks like someone has figured it out!
Please someone try and report back
http://www.droidforums.net/forum/bl...built-source-fast-working-3dlauncher-220.html
kreat1ve said:
Looks like someone has figured it out!
Please someone try and report back
http://www.droidforums.net/forum/bl...built-source-fast-working-3dlauncher-220.html
Click to expand...
Click to collapse
nice find keat1ve ... perhaps i will try out in the evening. if my wife gets me some spare time ... the instructions at droidforums is not really correct for milestone. it has to be adapted a little bit!
Will try right now, I will tell you ^_^
Thx a lot!!
yes it can and has been done. swap adds working memory true, but all those writing/reading to/from a partition/file in your sdcard WILL slow down your phone and shorten your sd card's life. its your choice eventually: either you want more memory, or you want speed. you cant have both.
yantz
@kreat1ve
this guide about the partitioning with adb does not work with milestone, I will try to create a swap partition with partition magic and then use droid swapper to enable it... let's hope xD
I dont wonna sound negative or anything but this is for the droid which is completly open which probably has a customized kernel with swap enabled, while our milestone is locked and does not have swap enabled in its kernel . Anyway i dont think trying this will hurt so i hope it works out
Following the guide, does not gave me results, but I asked to he one that posted it for more info;
meanwhile I've managed to create a .swap file and mkswap it using busybox, these are the results:
export PATH=/data/local/bin:$PATH
$ $ su
# dd if=/dev/zero of=/sdcard/.swap bs=1024 count=262144
262144+0 records in
262144+0 records out
268435456 bytes transferred in 57.985 secs (4629394 bytes/sec)
# mkswap/sdcard/.swap
mkswap/sdcard/.swap: not found
# mkswap /sdcard/.swap
mkswap: not found
# swapon /sdcard/.swap
swapon: not found
# busybox mkswap /sdcard/.swap
Setting up swapspace version 1, size = 268431360 bytes
UUID=16e9c236-61d9-49ec-a023-c529adb3109c
# busybox swapon /sdcard/.swap
swapon: /sdcard/.swap: Function not implemented
# busybox swapon -a
swapon: can't stat '/dev/block/mmcblk0p3': No such file or directory
# busybox free
total used free shared buffers
Mem: 230500 227516 2984 0 32
Swap: 0 0 0
Total: 230500 227516 2984
#
so the problem is that swapon does not recognize the file (but manually puting fstab in /etc and a file 06userinit within /etc/init.d/ containing
Code:
#!/system/bin/sh
swapon -a) but probably a partition of the sdcard may be recognized....now the problem form me...
I use windows 7 64bit...how the hell can I partition my sdcard with a swap partition?? LOL! XD
This is what blocks me...lol
try here
or
here
kassy_ok said:
try here
or
here
Click to expand...
Click to collapse
sadly the problem is in the kernel...."not supported" is the result of every swapon command...have to wait an official support or a custom kernel in 2nd boot...let's hope and wait...
Question: can't it be solved by creating a module supporting swap-filesystem?
TheSSJ said:
Question: can't it be solved by creating a module supporting swap-filesystem?
Click to expand...
Click to collapse
I'm wondering if someone has created such module?
I don`t know~~
alncool said:
I'm wondering if someone has created such module?
Click to expand...
Click to collapse
It seems that creating such a module is very hard. See the page cyanogenmod for milestone here :
http://code.google.com/p/cyanogenmo...ID Type Status Priority Version Owner Summary
I suggest everyone to star the feature. Maybe it will be developped by someone ... who knows !
So my friends... anyone could avance on this thread?
Sounds promising... but i also get stuck when enabling the swapon...
Anyone?
Cya
Hi!
Now, when we have official Froyo for MM with 2.6.32.9 kernel, can anyone create SWAP module for this kernel?
kilabdg said:
Hi!
Now, when we have official Froyo for MM with 2.6.32.9 kernel, can anyone create SWAP module for this kernel?
Click to expand...
Click to collapse
unfortunately no. Swap is not a module in Linux kernel, it changes the kernel's internal behaviour, so you cannot compile as swap=m, it is definitely y or n.
How to install ubuntu on the Droid 4
Note to mods: this thread is a branch off of this thread
Huge thanks to zacthespack for creating the ubuntu installer app and original boot script and to zeroktal for modifying the script to work on the D4 and helping me get it working on my device.
I decided to take my experience in setting this up and put it into a how-to so that others could enjoy the experience of having ubuntu on the Droid 4. If zackthespac or zeroktal have any problems with me making and putting this guide up, please let me know and I will remove it.
Knowledge Required:
working knowledge of command line
working knowledge of vi
OR the ability to learn how to use both
Tools Required:
A rooted Motorola Droid 4
BusyBox (Android Market)
Terminal Emulator (Android Market)
Android VNC Viewer (Android Market)
Ubuntu Installer App (Android Market)
zeroktal's ubuntud4.zip file (attached to this post and mediafire)
Vi Cheat Sheet (lagmonster.org)
Step by Step:
Install BusyBox, Terminal, and Android VNC Viewer
Install and run Ubunutu Installer App
Follow the on-screen instructions and click next
Download either the Small or Large image to your phone, (use zeroktal's ubuntud4.zip file instead of the boot script provided in the guide) after the image downloads (will take a while because the file is HUGE) click next
For this screen, the instructions differ from the app.
1. With your D4 plugged into your PC in USB Mass Storage, create a directory (folder) called ubuntu in the EXTERNAL sdcard's root*
2. Extract the image you downloaded to that directory
3. Download and extract the attached .sh (ununtud4.zip) to that directory
4. Disconnect your phone from your PC
5. Open terminal and run the following commands:
su [ENTER]
mount -o remount,rw,exec,suid /dev/block/vold/179:1 /mnt/sdcard-ext [ENTER]
cd /mnt/sdcard-ext/ubuntu [ENTER]
sh ubuntud4.sh [ENTER]
960x540 [ENTER]**If you get an error message: ubuntud4.sh: 45: syntax error: end of file unexpected (expecting "then") see troubleshooting section below.killall -TERM Xtightvnc [ENTER]
vncserver :1 -geometry 960x540 [ENTER]**6. Open androidVNC app and enter the following settings:
Nickname: Anything you want
Password: ubuntu
Address: localhost
Port: 5901
Color Format: 24-bit color (4 bpp)
7. Hit connect
8. Hit your menu soft button and then set input mode to touchpad
9. You have ubuntu on your Droid 4!
To "shut down" ubuntu:
press the menu button, select disconnect in VNC
In terminal type this command 3 times (terminal will close itself when you are done):
exit [ENTER]
To "start up" ubuntu again:
Follow steps 5-8 above
Troubleshooting:
If you get the error message: ubuntud4.sh: 45: syntax error: end of file unexpected (expecting "then") you are about to have fun with vi at the command line.
Do the following from inside terminal:
su [ENTER]
cd /mnt/sdcard-ext/ubuntu [ENTER]
vi ubuntud4.sh [ENTER]If you see ^M or ^ at the end of any line (remember to scroll all the way to the right to see the end of long lines) remove it. once you do that, everything should work just fine. (See the Vi Cheat Sheet above for help with Vi)
Note: Vol Up + E is [ESC] by default in this terminal emulator
Notes:
* It does not have to be on the external SD, but if you put it on the internal SD you will have to modify things as needed-- if you dont know what needs to be changed, just put it on the external SD.
** Screen size can be whatever you want it to be, but 960x540 is the size of the D4 screen.
*** This is a fairly involved process... especially when it comes to editing the .sh file in vi things can get very frustrating and hard, but just take your time and you will get it. As always, doing anything with root access on your phone, especially on the command line has risks. I am not responsible if anything goes wrong with your phone... proceed at your own risk!
greekchampion04 said:
Notes:
* It does not have to be on the external SD, but if you put it on the internal SD you will have to modify things as needed-- if you dont know what needs to be changed, just put it on the external SD.
** Screen size can be whatever you want it to be, but 960x540 is the size of the D4 screen.
*** This is a fairly involved process... especially when it comes to editing the .sh file in vi things can get very frustrating and hard, but just take your time and you will get it. As always, doing anything with root access on your phone, especially on the command line has risks. I am not responsible if anything goes wrong with your phone... proceed at your own risk!
Click to expand...
Click to collapse
I actually got it up and running on my internal sdcard partition. Pretty much just have to modify the Mount remount command, and a few lines in the script.
Here's the original command
Code:
mount -o remount,rw,exec,suid /dev/block/vold/179:1 /mnt/sdcard-ext
And the modified one
Code:
mount -o remount,rw,exec,suid /dev/block/vold/179:57 /mnt/sdcard
Only things you have to change are the device location(179:57) and mount location(drop the -ext after sdcard)
Now, after that you also have to modify the script a bit. Just go through it, and anywhere that you see sdcard-ext, drop the -ext off the end.
thanks for putting that up for everybody! like i said, if you know what you are doing its not a hard swap to make.
Is anyone else getting just a gray screen when they remote in? What could be causing this?
i had that same problem at first... did you use zeroktal's ubuntud4.zip file? or did you use the ubuntu.sh file included in the app?
I used the sh file included. I did however fix the problem, when mounting at the start i confused vold with void. I did not get the file system mounted properly. This method does work!! however I am currently trying to get bash on my droid to replace sh as the shell. I've checked the forums but have not found anything yet about someone installing bash on the droid 4. With no way for nandroids I feel i should wait before I kill sh.
Sent from my DROID4 using XDA App
If you mod your init.sh in your root directory to the following, your vnc will work on startup without issue. It will also shutdown vnc on exit.
#!/bin/bash
#############################################
# Asks User to screen size and saves as REZ #
#############################################
#echo "Now enter the screen size you want in pixels (e.g. 800x480), followed by [ENTER]:"
#read REZ
##############################################
# Pick which desktop environment to use, this#
# is done by having a xstartup file for each #
# desktop, then renaming the one you want to #
# use to 'xstartup' before boot #
##############################################
echo "Please select which Desktop environment you want to use, type the number to select it then press [ENTER]"
echo "1 - LXDE"
echo "2 - Gnome"
echo "Make your Selection:"
read DESKTOP
if [ $DESKTOP == 1 ]
then
mv /root/.vnc/lxstartup /root/.vnc/xstartup
fi
if [ $DESKTOP == 2 ]
then
mv /root/.vnc/gxstartup /root/.vnc/xstartup
fi
###########################################
# Tidy up previous LXDE and DBUS sessions #
###########################################
rm /tmp/.X* > /dev/null 2>&1
rm /tmp/.X11-unix/X* > /dev/null 2>&1
rm /root/.vnc/localhost* > /dev/null 2>&1
rm /var/run/dbus/pid > /dev/null 2>&1
############################################################
# enable workaround for upstart dependent installs #
# in chroot'd environment. this allows certain packages #
# that use upstart start/stop to not fail on install. #
# this means they will have to be launched manually though #
############################################################
dpkg-divert --local --rename --add /sbin/initctl > /dev/null 2>&1
ln -s /bin/true /sbin/initctl > /dev/null 2>&1
###############################################
# start vnc server with given resolution and #
# DBUS server, (and optionally an SSH server) #
###############################################
dbus-daemon --system --fork > /dev/null 2>&1
/etc/init.d/ssh start
vncserver :1 -geometry 960x540
echo
echo "If you see the message 'New 'X' Desktop is localhost:1' then you are ready to VNC into your ubuntu OS.."
echo
echo "If VNC'ing from a different machine on the same network as the android device use the 1st address below:"
##########################################
# Output IP address of android device #
##########################################
ifconfig | grep "inet addr"
echo
echo "If using androidVNC, change the 'Color Format' setting to 24-bit colour, and once you've VNC'd in, change the 'input mode' to touchpad (in settings)"
echo
echo "To shut down the VNC server and exit the ubuntu environment, just enter 'exit' at this terminal - and WAIT for all shutdown routines to finish!"
echo
###############################################################
# Spawn and interactive shell - this effectively halts script #
# execution until the spawning shell is exited (i.e. you want #
# to shut down vncserver and exit the ubuntu environment) #
###############################################################
/bin/bash -i
#########################################
# Disable upstart workaround and #
# kill VNC server (and optionally SSH) #
# Rename used xstartup to its first file#
#########################################
killall -TERM Xtightvnc
/etc/init.d/ssh stop
Also save the follow lines between ### as remount.sh on your system partition. Then chmod 755 /system/remount.sh. Now you can just run run from a terminal /system/remount.sh and voila it remounts correctly and starts ubuntu(with the above fixes). Im still working on the unmounts.
####### for the internal sd card
mount -o remount,rw,exec,suid /dev/block/vold/179:57 /mnt/sdcard
/mnt/sdcard/ubuntu/ubuntu.sh
######
OR
####### for the external sd card
mount -o remount,rw,exec,suid /dev/block/vold/179:1 /mnt/sdcard-ext
/mnt/sdcard-ext/ubuntu/ubuntu.sh
#######
great stuff!
feel free
Feel free and take, modify, repost or edit anything I touch.
QUESTION:
After I delete all the ^M and ^ what do i do next? I try to hit the command ":x" to exit and save changes but it just creates another line. Also when I press VOL UP + E to escape nothing happens.
PhanTuhC said:
QUESTION:
After I delete all the ^M and ^ what do i do next? I try to hit the command ":x" to exit and save changes but it just creates another line. Also when I press VOL UP + E to escape nothing happens.
Click to expand...
Click to collapse
In vi, the command to save and exit is :wq (probably short for write and quit).
remember, read up on the vi quick-reference guide: http://www.lagmonster.org/docs/vi.html
OK I fixed it but now its not letting me connect with androidVNC. All the settings entered is correct but when I try to connect it says:
"VNC connection failed!" localhost/127.0.0.1:5901 - Connection refused"
ok, i've gone thru this a few times (slowly and deliberately) and must be missing something...the directions seem pretty straightforward! here's what i know...
busy/terminal/vnc are all installed
small 2.5gb image is unzipped in /sdcard-ext/ubuntu directory
the attached .sh file from page 1 is in the same directory
i removed all ^M using vi
but when I try sh ubuntud4.sh i get an error...
"mkdir failed for /data/local/mnt/ubun, No such file or directory"
(plus a few other errors)
should the directory be "ubun" or "ubuntu"? am I typing something incorrectly?
copy and paste new script
Copy and paste the new scripts I posted. They will fix your problem. Remember to use the remount script from /system/ the rest will work perfectly if you are root. I'll check back later on your progress.
Ok, well I started from scratch (deleted both .img and .sh files) and it's still not working.
I have all the apps installed (and yes rooted, SU works just fine)
I used Ubuntu Installer app to download the image zip (tried both the large and small img)
I downloaded the .sh file from the first post
The /sdcard-ext/ubuntu/ folder now has two files: "ubuntu.img" and "ubuntud4.sh"
All ^M characters have been removed from .sh file
Still no joy...
Ideas? What am I missing?
In terminal, I can set SU permissions and the mount/cd commands work just fine...it's the last sh command that spits out a bunch of errors about not being able to create/find the directories.
I'm going to format the sdcard and try again...any help is appreciated.
Update: Even after re-formatting the SD and following the steps exactly, no luck!
Did you remember to remount the sdcard with exec and suid permissions?
Andbuntu will work much better than this method. It works on every single phone with modification to the "environmental variables".
http://code.google.com/p/andbuntu/
Follow the directions in the script to make the process much easier than the first post.
instructions:
generate an image with rootstock on an ubuntu computer.
put it on /sdcard/ubuntu/ubuntu.img
run the script on your phone with "sh /path/to/script"
Here is the script. http://andbuntu.googlecode.com/svn/trunk/uboot
Also, run "firstRun" to make things like terminals work properly.
Adamoutler: That didnt work for me. The permissions were incorrect on the mounted partitions.
Sent from my DROID4 using XDA App
At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series or even S5 / Note 3 etc - feel free to repost but give credits AS THIS METHOD SEEMS TO BE COMPLETELY NEW! ) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file permissive_via_kmem.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/permissive_via_kmem.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/permissive_via_kmem.sh
(give it an access if requested)
4) voila.
Alternative: if u have init.d support just put the file in /system/etc/init.d to make permissive on every boot
Additional info for advanced users:
1) samsung decided to compile kernels for newer 4.4.2 roms with a flag (a kernel variable) forcing selinux enforcing mode
2) as kernel itself cannot be modified after compiled, it was impossible to set permissive mode using shell or even by repacking kernel's ramdisk, at least on Qualcomm LTE devices
3) custom kernel can do the job, but samsung's sources are broken, at least for P905, and it refuses to boot at all...
4) however, there is a workaround...
5) we cannot change kernel binary to run with different flag out of the box BUT we can obtain it's placement (address) directly in kernel memory space on running kernel and write different value DIRECTLY into the memory, hacking the kernel to make it think that the flag was different
6) for this purpose i believe we have to disable restrictions to access kernel pointers (done via sysctl)...
7) ...then read the output of /proc/kallsyms which will provide a list of all kernel variables along with their addresses in kernel memory space...
8) ...filter out a boolean variable selinux_enforcing which is responsible for all the troubles...
9) ...and write raw 00 byte into the address where the variable value is stored, via /dev/kmem.
Download:
http://www12.zippyshare.com/v/89625246/file.html
Noob question
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
cavkic said:
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
Click to expand...
Click to collapse
Check this
Well, if i'd try to express it in a simple way, from the user's point of view permissive mode is equal to selinux turned off at all, except it is logging (and only logging...) all the warnings caused by security violations, which would result in an error in enforcing mode. Permissive mode let you avoid strict security policies defined by manufacturer (and NSA - yeah, the real spies - which is maintaining general selinux rules), but also gives the possibility of establishing possible issues which may appear after switching to "really secure" enforcing mode.
And if you are asking about the exact, disturbing (ofc if security is not your main priority...) effects of enforcing mode that may affect end-users, we may start from: troubles with write-access to some (mostly external, but i have personally fought with with an issue of non-writeable internal sdcard, too) medias (well, to be honest, I do hope that my discover will help in building 100% working custom recovery...), troubles with non-working system mods resulting from bad selinux file labels, troubles with wiping partitions (ie. wiping cache or even swapping modded system lib sometimes has to be followed by triggering restorecon command on that filesystem (restore selinux context), which is leading to ie. losing root access, which may be fixed by flashing supersu again, etc etc, non working apps (especially related to modifying sensitive system parameters or resources), unchangeable system properties, unreachable functionalities, blah blah blah.... This topic had been widely discussed on xda and over the internet.
On the contrary, if you like to use your device as-is and you're not interested in modding/tweaking it, you will probably not need this mod, as you will gain nothing - but lose a little bit of security... For heavy modders, although, it's a must-have.
Btw can anyone confirm if it's working? I assume that I was looking for solution for some time, made some other changes to the environment meanwhile, so I cannot be 100% sure that above script alone is absolutely enough (but in theory it should...), however, even if it is not, it's just a matter of 1-2 days to figure out what additional, previously-well-known steps, such as running "setenforce 0", may be required in addition.
And as a brief summary: YES, my selinux is now really Permissive, both when running getenforce command and in system settings!
Wysłane z mojego SM-P905 przy użyciu Tapatalka
After following all steps getenforce still returns enforcing and in system it also shows enforcing.
If I try running setenforce I get permission denied.
Ok, can you enter:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
into terminal and tell me what's the output and/or the enforcing state??
Wysłane z mojego SM-P905 przy użyciu Tapatalka
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
RaSand said:
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
Click to expand...
Click to collapse
I assume that you have ran the command as root (ie didnt forget about 'su' before the main command)...? Your logs show non-root mode, but ur saying about '#' mode at the end, guess you mean su... Assume that all we do here requires root shell first to be opened, and the output even if similiar, may vary in details between non-root and root mode, so don't forget to get privileges before running anything below...
If so, I guess default policy prevents writing to /dev/kmem in enforcing mode by setting its selinux context to a special one, dedicated only for /dev/kmem and /dev/mem.The working solution is to repack kernel (not same, but, indeed, a lot easier, than recompile - changes won't affect the kernel binary code, but it's ramdisk part, only) with modified policy defaults, which will treat /dev/kmem as a genuine device, not a "sensitive" one. I can provide the one repacked for my own purposes, however, befoure such an intrusion we may want to try other solutions I can think of (again, cannot test it as I ve added many different mods in many different places, I would need to go back to stock to test it, but I need my device 100% steady and configured for my job this week. Hope you'll help me in solving this out, it shouldnt take long...).
Notice: Again, ALL BELOW COMMANDS SHOULD BE RUN IN ROOT MODE. That means you shall enter "su" command alone before trying any of those steps, and the Terminal will switch to a root shell, which is confirmed by switching the last sign in the prompt from '$' to '#'.
Notice 2: if it is written - after some steps - to try switching to permissive mode again, it should be done by running the command from MY PREVIOUS POST only, as it is equal to longer version from the script, just closed within shorter one-liner command... the command should change the mode to permissive itself and no further steps are needed.
1) run following:
Code:
ls -lZ /dev/kmem >/sdcard/info.txt
and paste the exact output (which has been saved at /sdcard/info.txt) here so I can gather further info about issue. Dont make a test of the main script here as nothing has been changed. After that...
2) we can try to set different context (a default one for dev files) manually. Again, it might be impossible as of selinux policy, but worth trying. Enter as root:
Code:
busybox mount -o rw,remount /
chcon u:object_r:device:s0 /dev/kmem
if error, paste it here. If no error, test if permissive mode script is working.
3) we can try to modify selinux policy in temporary ramdisk file to prevent giving /dev/kmem a special context and then restore context of whole /dev to it's "defaults", however, those "defaults" would be our modified ones. Possible issues: not sure if the restoring default context will make use of modified policy or would it use only the policy loaded on-boot (and as the ramdisk is temporary, policy modifications will disappear too within reboot). After getting root, enter:
Code:
busybox mount -o rw,remount /
sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
setprop selinux.reload_policy 1
restorecon -R /dev >/dev/null 2>&1
after that - if no errors - check if the switching works.
4) if none of the above is working, guess we'll need to repack stock kernel with a ramdisk content modified in the same way as in step 3. When embedded in kernel, the changes to the policy rules will be seen every boot and they will affect /dev/kmem in a persistent manner. This will let you write to it for sure. I will provide a ready repacked boot.img, so we can avoid repacking at all. This however is not a very satisfying solution, as my goal was not only to achieve permissive mode, but to achieve it without any changes (even if they are much less disturbing than recompiling kernel from source) to boot partition. But hey, first check out on-the-fly solutions above, as they are much less intrusive to a device, coz won't require reflashing kernel/boot partition.
EDIT: remount command added to step 2, repeat if you had error with changing the context.
Thanks for your effort.
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
RaSand said:
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
Click to expand...
Click to collapse
Your errors are quite strange, as it seems that you don't even have permissions to check the simple content of a directory...
Try to run commands from step 1 - 3 again, but with slight modifications (below), so theyll run in separate, undoubtly-rooted shell... Test also with modded command (you can try it alone before in the very beginning...)
Also: please run 2 and 3 in reversed order, ie. first step 3 and if not working, without rebooting, run step 2...
Btw are you using SuperSu 1.99? If no - after trying all below options, upgrade SuperSu from the Play Store, run it to update the binaries, reboot. check commands again. If still the same, install update to /system using option from its menu (it will do some cleanup and ask to reboot, after that you have to run option again, this time it will perform installation, after which you have to reboot again - after boot run SuperSu and check if the option is greyed out, if yes, everything went fine) and check all steps once again...
Here we go.
Main command:
Code:
su -c printf '\x00' | dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
Step 1 v2:
Code:
su -c ls -lZ /dev | grep kmem >/sdcard/info.txt
Step 2 v2 (formerly step 3 ):
Code:
su -c busybox mount -o rw,remount /
su -c sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
su -c setprop selinux.reload_policy 1
sleep 3
su -c restorecon -R /dev
Notice: I am not sure if setprop selinux.reload_policy 1 is enough to force sammy's android (which is a really giant b***ch to hack when compared to any other android...) to reload the policy, this may really work, but only if the policy is reloaded on-line using new defaults. Later I will look for that information...
Step 3 v2 (formerly step 2 - please run directly after step 2v2, without rebooting...):
Code:
su -c busybox mount -o rw,remount /
su -c chcon u:object_r:device:s0 /dev/kmem
Notice: step 3 - when ran fine - might now print some errors that it cant access some stuff in /dev - this is absolutely ok. But formerly I disabled the output at all (not to confuse you with some strange errors), but it resulted in lack of possibility to find out if the command ran AT ALL or if it escaped because of no permissions on the very beginning.
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
RaSand said:
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
Click to expand...
Click to collapse
Stay cool. I am a (quite) young man, but I have patience, too ;]
No output when running *something* as su = faulty su installation (maybe)...
Please download SuperSu 1.99 (flashable cwm version) from here: http://forum.xda-developers.com/showthread.php?t=1538053 and put it somewhere on internal sdcard
Download my "almost-working" TWRP recovery image: http://www53.zippyshare.com/v/30690424/file.html
Put it in internal mem so its path will be /sdcard/twrp2.img
Run terminal emulator (CAREFULLY WITH THE PARTITION NUMBERS!)
Code:
su
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.backup.img
sleep 1
dd if=/sdcard/twrp2.img of=/dev/block/mmcblk0p15
sleep 1
sync
reboot recovery
In recovery, flash downloaded supersu zip. Reboot.***
Try commands again.
Maybe your busybox is bad? Can you tell me the output of command busybox written alone without further params?
***(btw the recovery may be useful, but it is not-fully-working, however, it is working AT ALL... be aware of issues:
- it cannot write backups to exfat external cards, vfat/fat32 only
- it may mess the selinux context, especially for cache partition after wipe. solution: from twrp run advanced -> console (or terminal? dont remember) and run
restorecon -R /cache
- if u ever have a bootloop after flashing a (even reliable...) zip, you should get back to twrp, click mount menu, mount everything, switch to advanced -> console and run:
restorecon -R /system
restorecon -R /data
restorecon -R /cache
selinux contex will be fixed BUT it will mess context for su binary, so in the end flash supersu again and reboot, everything will be ok.
If you want to revert, just do:
dd if=/sdcard/recovery.backup.img of=/dev/block/mmcblk0p15
).
And last but not least, kernel which I have promised (BUT if you use it, I will lose my only tester heheee):
http://www46.zippyshare.com/v/63874309/file.html
Please be aware that there are some other tweaks included (like unsecure adb, faster filesystem mount options but with higher risk of data loss, etc).
Put b4.img to /sdcard/b4.img
Run:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/sdcard/boot.backup.img
sleep 1
dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
sleep 1
sync
reboot
You can revert to stock by dd if=/sdcard/boot.backup.img of=/dev/block/mmcblk0p14 (or by flashing full stock by odin). Would be glad if you can confirm that mode is permissive using this repacked kernel (HOPE IT WILL!!!!) and after some time you'll flash the backup back, to help me solving the case, as i suppose that there IS possibility of permissive without the kernel flash and I need a tester ;} It would be reeeeeeaaaaaaaally nice...
BE AWARE THAT:
- it's for note pro 12.2 LTE ONLY!!!! also called viennalte or SM-P905... It WON'T work on other devices and it may damage them (for example, coz of different mmcblk numbers...)
- messing the mmcblk0pxx number may cause an unrecoverable harm to your device (especially if you overwrite bootloader partitions or your efs partitions where unique imei is stored), it's 14 for kernel (boot) and 15 for recovery
- your knox WILL be tripped (if it hasnt been tripped yet... but it's not very probable )
- on the very first boot screen, a warning messages may appear in the left-top corner, about some warranty stuff. Ignore them, they'll disappear after reverting boot/recovery to stock.
Regards.
Just done flashing twrp and supersu(now 1.99)
i will not give up that easy, don't worry.
Just to be on the safe side i downloaded b4. Maybe you should remove it for the moment.
Looks like fun being the most important part of the team.lol.
btw. Knox was tripped about 2 hours after i got the device
busybox is v1.22.1 (2014-01-25 17:27:18)
---------- Post added at 10:05 PM ---------- Previous post was at 09:15 PM ----------
This it what happened after the last command in step 2 was executed
Could not label /dev/cpuctl with ubject_r:cpuctl_device:s0: Operation not supported on transport endpoint
Could not access /dev/kmem: Operation not supported on transport endpoint
Could not access /dev/mem: Operation not supported on transport endpoint
Could not label /dev/pts with ubject_r:device:s0: Permission [email protected]:/ #
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
RaSand said:
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
Click to expand...
Click to collapse
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..
The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).
To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).
If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).
After that, there should be no further doubts that you have unlocked /dev/kmem for writing!
On this step you still need to run the command from my post on top of the topic, this one:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...
Then check enforcing status. Now it really should work.
If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
RaSand said:
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
Click to expand...
Click to collapse
good, thank you for testing and hope enforcing linux won't bother you again ;] you're probably a second man on the planet who is running your machine in permissive
and don't worry about anything, it's not a race or something. i am most thankful that you found a time to run all the suggested stuff, and for patience.
please however note that leaving open /dev/kmem shall be considered as a serious security hole! it allows root app to write ANYTHING to ANY part of memory. Well, that's was an obligatory warning, however, I was never scared too much with security issues and until now nothing bad happened so..
Let's summarize:
- now I am sure that my script is working BUT only after giving it possibility of writing to memory via /dev/kmem
- writing to /dev/kmem is possible only after changing the security policy, which lies in kernel's ramdisk
- the final appropach shall also CLOSE the access to /dev/kmem just after changing the selinux mode for security reason
- the aim is to make a complete modification which will make use of only one area of the device ie. system OR kernel, not both, as it is too intrusive:
- find a way to reload policy when device is on-line, so writing to /dev/kmem will be possible (it's a preferred method, no need to flash anything and no need to watch ugly warranty message - but I doubt if it's possible - it would be an equally dangerous security issue, there is no practical difference between letting write to memory and between letting to open the possibility of write to memory and then letting write to memory ... or
- implement the memory write technique straight in the kernel's ramdisk.
I will be back with new stuff, soon.
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
RaSand said:
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
Click to expand...
Click to collapse
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
esgie said:
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
Click to expand...
Click to collapse
Esgie, is there any further developments with this script? I've given it a shot and even after running the script, SELinux remains in Enforcing mode.
I see that you have the modified kernel for SELinux in permissive mode, but I really like the approach of having this script rather than using a modified kernel, so I'm wondering if in your process of getting the kernel to work, there might be something you've discovered that would make this script work as well.
Thanks.