Related
SGS2 has changed a lot from SGS1 with filesystems, since there is no RFS anymore. The PIT file looks pretty different now too.
Code:
GANG : emmc.img
BOOT : boot.bin
EFS : efs.img
SBL1 : Sbl.bin
SBL2 : bl.bin (?)
PARAM : param.lfs
KERNEL : zImage
RECOVERY : (blank, unlike SGS1 which was a copy of zImage)
CACHE : cache.img
MODEM : modem.bin
FACTORYFS : factoryfs.img
DATAFS : data.img
HIDDEN : hidden.img
Preliminary notes:
Recovery is blank instead of zImage. Not sure what this could mean - it's possible that this is now unflashable? It's also possible that this is no longer used, and the kernel is used directly.
Something called GANG is at the top of the file. No idea what this is. Stuff at the top is usually lower level. It does have the image file name emmc though, http://en.wikipedia.org/wiki/MultiMediaCard#eMMC
eMMC describes an architecture consisting of an embedded storage solution with MMC interface, flash memory and controller, all in a small ball grid array (BGA) package.[4]
Embedded MultiMediaCard (e-MMC) e-MMC/Card Product Standard, High Capacity, including Reliable Write, Boot, Sleep Modes, Dual Data Rate, Multiple Partitions Supports and Security Enhancement
Click to expand...
Click to collapse
Sounds interesting, anyway.
FactoryFS and Data are now seperate, when in the SGS1 they were the same thing. (SGS1 copied over /data from inside factoryfs when it was not found - this means that factory reset might work differently here.)
hidden.img is part of the CSC, not sure what this could be, or even why it's here. Will have to look inside the img file to find out, I guess. CSC is usually just extra files placed in /system
SBL2 is bl.bin instead of Sbl.bin - typo by Samsung?
Since this is all EXT4 now, we might actually be able to re-size things properly now, as in the SGS1 with it's RFS stuff the /system partition couldn't actually be resized.
EDIT: Adding some reference stuff from the device.
All partitions appear to be directly off mmcblk0 - there are 12 of them. Output follows:
Code:
brw------- root root 179, 12 2011-05-08 10:35 mmcblk0p12
brw------- root root 179, 11 2011-05-08 10:35 mmcblk0p11
brw------- root root 179, 10 2011-05-08 10:35 mmcblk0p10
brw------- root root 179, 9 2011-05-08 10:35 mmcblk0p9
brw------- root root 179, 8 2011-05-08 10:35 mmcblk0p8
brw------- root root 179, 7 2011-05-08 10:35 mmcblk0p7
brw------- root root 179, 6 2011-05-08 10:35 mmcblk0p6
brw------- root root 179, 5 2011-05-08 10:35 mmcblk0p5
brw------- root root 179, 4 2011-05-08 10:35 mmcblk0p4
brw------- root root 179, 3 2011-05-08 10:35 mmcblk0p3
brw------- root root 179, 2 2011-05-08 10:35 mmcblk0p2
brw------- root root 179, 1 2011-05-08 10:35 mmcblk0p1
Partitions map as follows:
Code:
/dev/block/mmcblk0p9 /system ext4 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p7 /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p1 /efs ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p10 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered,noauto_da_alloc,discard 0 0
/dev/block/mmcblk0p4 /mnt/.lfs j4fs rw,relatime 0 0
Not sure what the unmapped partitions are for yet.
Nice, i had a look at the partitions table to, and can verify your find. Lets see if we can make some useful of this.
Doc! I hope you got your SGS2 as SGS2 definitely need you
RyanZA! I hope you also got your SGS2, as Dev forums cannot live without you
DocRambone said:
Nice, i had a look at the partitions table to, and can verify your find. Lets see if we can make some useful of this.
Click to expand...
Click to collapse
nasgilani said:
Doc! I hope you got your SGS2 as SGS2 definitely need you
RyanZA! I hope you also got your SGS2, as Dev forums cannot live without you
Click to expand...
Click to collapse
Hahah, I've got one. To be honest though, I'm having a hard time finding anything I actually want to mod. Samsung has actually done a very good job this time around.
i can think of a few..
1. sound is not as good as my sgs with voodoo sound.
2. 2e recovery right on the phone would be nice
3. lower minimim brightness level
4. transparent status bar...
5. correctly working vpn and wpa_supplicant with adhoc mode working.
6. extra batteris i can charge with a wall charger so i can always have a spare in my pocket (they appear to be not out yet.. the idiots on ebay are selling the wrong battery and chargers for the phone)
7. working sip stack built into gingerbread like it should be.
Nothing to mod? Sounds like a boring phone.
RyanZA why did you leave the SGS scene? I miss you
jaju123 said:
RyanZA why did you leave the SGS scene? I miss you
Click to expand...
Click to collapse
With all the mods/devs for the SGSI, everything on that device already works perfectly (imo anyway). There was nothing left that I wanted to change, and all the cool projects are well in hand by people who don't want help/don't need help.
And the main problem: I got an SII, which makes it hard to look at the SI these days.
sorry for question maybe answer is allready at the forum. But can i RESIZE system ?? Now i want put there somethink (3mb) by xplore but i cant. Its says that temp file cant be writen.... when i delete somthink (3mb) from system its ok. So system is full... can i resize it?
Hi all
This thread is based on what I learned in an HTC One S thread (http://forum.xda-developers.com/showthread.php?t=1674202)
OK so I have found the location where the CID and IMEI are stored in /dev/block/mmcblk0 at offset 00a00000
00a0000 [email protected]H3G__00135304xxxxxxxxxx
However, when I try to dump the file to SCDARD with
dd if=/dev/block/mmcblk0 of=/sdcard/mmcblk0
the command never finishes (I broke out after about 5 minutes with a 4GB file sitting on the SDCARD, which I assume is incomplete.
I also dd most of the part "pxx" files but none of them contained the CID & IMEI. ;(
[email protected]:/dev/block # ls -l
ls -l
brw------- root root 254, 0 2012-06-05 16:14 dm-0
brw------- root root 254, 1 2012-06-05 16:14 dm-1
brw------- root root 254, 2 2012-06-05 16:14 dm-2
brw------- root root 254, 3 2012-06-05 16:14 dm-3
brw------- root root 7, 0 2012-06-05 15:34 loop0
brw------- root root 7, 1 2012-06-05 15:34 loop1
brw------- root root 7, 2 2012-06-05 15:34 loop2
brw------- root root 7, 3 2012-06-05 15:34 loop3
brw------- root root 7, 4 2012-06-05 15:34 loop4
brw------- root root 7, 5 2012-06-05 15:34 loop5
brw------- root root 7, 6 2012-06-05 15:34 loop6
brw------- root root 7, 7 2012-06-05 15:34 loop7
brw------- root root 179, 0 2012-06-05 15:34 mmcblk0
brw------- root root 179, 1 2012-06-05 15:34 mmcblk0p1
brw------- root root 179, 10 2012-06-05 15:34 mmcblk0p10
brw------- root root 179, 11 2012-06-05 15:34 mmcblk0p11
brw------- root root 179, 12 2012-06-05 15:34 mmcblk0p12
brw------- root root 179, 13 2012-06-05 15:34 mmcblk0p13
brw------- root root 179, 14 2012-06-05 15:34 mmcblk0p14
brw------- root root 179, 15 2012-06-05 15:34 mmcblk0p15
brw------- root root 179, 16 2012-06-05 15:34 mmcblk0p16
brw------- root root 179, 17 2012-06-05 15:34 mmcblk0p17
brw------- root root 179, 18 2012-06-05 15:34 mmcblk0p18
brw------- root root 179, 19 2012-06-05 15:34 mmcblk0p19
brw------- root root 179, 2 2012-06-05 15:34 mmcblk0p2
brw------- root root 179, 20 2012-06-05 15:34 mmcblk0p20
brw------- root root 179, 3 2012-06-05 15:34 mmcblk0p3
brw------- root root 179, 4 2012-06-05 15:34 mmcblk0p4
brw------- root root 179, 5 2012-06-05 15:34 mmcblk0p5
brw------- root root 179, 6 2012-06-05 15:34 mmcblk0p6
brw------- root root 179, 7 2012-06-05 15:34 mmcblk0p7
brw------- root root 179, 8 2012-06-05 15:34 mmcblk0p8
brw------- root root 179, 9 2012-06-05 15:34 mmcblk0p9
drwxr-xr-x root root 2012-06-05 15:34 platform
drwxr-xr-x root root 2012-06-05 15:34 vold
Is it possible with dd (or another adb shell / linux commmand) to modify only the 8 bytes of mmcblk0 which contain the CID? If so we could debrand with HTC__001 or even superCID with 11111111
Any ideas?
why dont you post this in the S-OFF discussion?
dezborders said:
Is it possible with dd (or another adb shell / linux commmand) to modify only the 8 bytes of mmcblk0 which contain the CID? If so we could debrand with HTC__001 or even superCID with 11111111
Any ideas?
Click to expand...
Click to collapse
man dd
Looks like skip and seek are what you're looking for.
BenPope said:
man dd
Looks like skip and seek are what you're looking for.
Click to expand...
Click to collapse
Sadly conv=notrunc option is disabled in dd on android so I can't update only the area containing cid. It's not feasible to dump all 32gb of mccblk0, edit cid then write back all 32gb.
Sent from my HTC One X using XDA
Does the android version support the "skip" and "seek" options?
dezborders said:
However, when I try to dump the file to SCDARD with
dd if=/dev/block/mmcblk0 of=/sdcard/mmcblk0
the command never finishes (I broke out after about 5 minutes with a 4GB file sitting on the SDCARD, which I assume is incomplete.
Any ideas?
Click to expand...
Click to collapse
mmcblk0 is the whole 32G flash chip of the phone, while mmcblk0p1 .. mmcblk0p20 are the individual partitions.
I think, it is worth to find specific partition between these 20, which contains CID, and work with it.
k0rner said:
mmcblk0 is the whole 32G flash chip of the phone, while mmcblk0p1 .. mmcblk0p20 are the individual partitions.
I think, it is worth to find specific partition between these 20, which contains CID, and work with it.
Click to expand...
Click to collapse
None of the 20 partitions contain the cid, obviously the area of mmcblk0 containing this data is only accessible to hboot.
Also, it has been suggested writing to the 20 partitions only makes temporary changes which revert to original values at next reboot.
I think this thread should be locked and let the devs in the main S-off thread continue the discussion .)
Sent from my HTC One X using XDA
dezborders said:
None of the 20 partitions contain the cid, obviously the area of mmcblk0 containing this data is only accessible to hboot.
Also, it has been suggested writing to the 20 partitions only makes temporary changes which revert to original values at next reboot.
I think this thread should be locked and let the devs in the main S-off thread continue the discussion .)
Sent from my HTC One X using XDA
Click to expand...
Click to collapse
I think mmcblk0p19 contains CID.
Karel
If I remember correctly p19 is just logs, so its just a text file that happens to contain a copy of your cid code. Sorry
@MOD... If any forum mods are reading, please lock this thread for me, thanks !
Sent from my HTC One X using XDA
mmcblk0p14 contains the cid
no lets keep this discussion outside the S-off section
changing CID is a different and as important as s-off
its really odd that this can be done for the One S and not the X
Hello, I've found 0x00A00000 at /dev/block/mmcblk0 is where the cid and IMEI were stored for some time, but I didn't found a way to change it.
But now that I've got a way to modify it. Use the dd command from Busybox, it can let you use the "conv=notrunc" parameter to write the changed cid into /dev/block/mmcblk0. btw, 0x00A00000 is the offset of DIAG partition, so here is the start of diag partition.
You may use dd command to export the mmcblk0 from 0x00A00000 to a file called "towrite", and modify it using a hex editor, then do the flash just as the following command in the shell:
Code:
busybox dd if=/sdcard/towrite of=/dev/block/mmcblk0 bs=1024 count=1 seek=10240 conv=notrunc
Then you willl get it modified(you can check it by "dd if=/dev/block/mmcblk0 of=/sdcard/dump.txt bs=1024 count=1 skip=10240", and then check "dump.txt" in your sdcard, you will see it has been modified.)
BUT IT WON'T CHANGE THE CID ACTUALLY. If you reboot into bootloader, and execute "fastboot oem readcid" then, the cid remains the original one.
So...I think the CID must be stored in the motherboard, and can't be modified by software methods.
What's about the idea to rip the mmcblk0p4 from an S-OFF device and put it on a S-ON device? As far as I know the hboot is stored within this partition.
It might be that the IMEI will also be the same but I guess with the current eng-hboot there is an option to change it.
Who can offer a backup from an TEGRA S-OFF device?
Don't waste your time, as of now you cannot change your cid, if s_off comes in the future this may change but it might never happen.
Sent from my HTC One X using xda app-developers app
hamdir said:
no lets keep this discussion outside the S-off section
changing CID is a different and as important as s-off
its really odd that this can be done for the One S and not the X
Click to expand...
Click to collapse
i believe its possible for the x if its possible for the s.
but at the same time, i dun think its possible.
remember, the s is a qualcomm and the x is a tegra
shiningarmor said:
i believe its possible for the x if its possible for the s.
but at the same time, i dun think its possible.
remember, the s is a qualcomm and the x is a tegra
Click to expand...
Click to collapse
The one x and the one s do not share the same SoC. What works on the one s doesn't necessarily work on the one x.
Sent from somewhere....if I could only remember where....
Hi @all,
haven't found any definite answer to this unsing the search function.
Is there any image out there supporting the HDD version of the 80G9 tablet? Except the official image of course.
Installed the lastest 4.4.2 developer image, now I know what the H-Model is (No "H" model support)... otherwise working great so far.
Thanks for your answers!
martinwag said:
Hi @all,
haven't found any definite answer to this unsing the search function.
Is there any image out there supporting the HDD version of the 80G9 tablet? Except the official image of course.
Installed the lastest 4.4.2 developer image, now I know what the H-Model is (No "H" model support)... otherwise working great so far.
Thanks for your answers!
Click to expand...
Click to collapse
It's really confusing...
[URL="http://forum.xda-developers.com/showpost.php?p=50137500&postcount=61" @[email protected][/URL] has reported that it works... I really don't know whats going wrong...
@[email protected]: Can you give a statement, if the harddisk storage works for you?
Quallenauge said:
It's really confusing...
[URL="http://forum.xda-developers.com/showpost.php?p=50137500&postcount=61" @[email protected][/URL] has reported that it works... I really don't know whats going wrong...
@[email protected]: Can you give a statement, if the harddisk storage works for you?
Click to expand...
Click to collapse
Yes, but I could only install till version 23_01_2014-21_52_56 yet.
And I need to mount it manually e.g. via 'adb shell':
[email protected]:/ # mount /dev/block/platform/omap/usbhs_omap/sdb1 /storage/sdcard1/
[email protected] said:
Yes, but I could only install till version 23_01_2014-21_52_56 yet.
And I need to mount it manually e.g. via 'adb shell':
[email protected]:/ # mount /dev/block/platform/omap/usbhs_omap/sdb1 /storage/sdcard1/
Click to expand...
Click to collapse
Can you please adapt the fstab file "/fstab.archosa101hboard" to this location?
Code:
[STRIKE]/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.1/1-1.1:1.0/ auto auto defaults voldmanaged=sdcard1:auto[/STRIKE]
[B]/dev/block/platform/omap/usbhs_omap/sdb1 auto auto defaults voldmanaged=sdcard1:auto[/B]
/devices/platform/omap/musb-omap2430/musb-hdrc/usb2/2-1/2-1:1.0 auto auto defaults voldmanaged=usbdisk:auto
/dev/block/zram0
And see if it helps? (Maybe you can play with the old path definition; does it exist? Maybe this is sufficient:
Code:
/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/
)
Hint: Don't forget to unlock the device in order to modify the system file:
Code:
adb shell mount -o remount,rw /
Actually I am not used to writing in those forum systems, so my original try to answer is now blocked
---------- Post added at 01:10 AM ---------- Previous post was at 12:59 AM ----------
I try without any quotes and just a very short version:
Actually I forgot that I had a mini card reader and sdcard in the 3G USB plugged in, without this card it is in fact sda1
---------- Post added at 01:22 AM ---------- Previous post was at 01:10 AM ----------
... Nevertheless it didn't worked, so I searched and found fstab.archosa101hboard is not really in use and I changed init.archosa101hboard.rc first.
---------- Post added at 01:27 AM ---------- Previous post was at 01:22 AM ----------
please try a grep fstab.archosa init* to find that always the sboard fstab files are mounted
---------- Post added at 01:38 AM ---------- Previous post was at 01:27 AM ----------
Don't know if this can be useful information for you in init.archosa.*board.rc files, but I found in init.rc this import line via ${ro.hardware}:
import /init.${ro.hardware}.rc
back to the harddisk:
still not knowing why it didn't work I changed fstab.archosa101hboard to double-check my fix above is okay:
#/devices/platform/omap/omap_hsmmc.0 auto auto defaults voldmanaged=sdcard1:auto
#/dev/block/platform/omap/usbhs_omap/sda1 auto auto defaults voldmanaged=sdcard1:auto
/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2
/devices/platform/omap/musb-omap2430/musb-hdrc/usb2/2-1/2-1:1.0 auto auto defaults voldmanaged=usbdisk:auto
/dev/block/zram0 none swap defaults zramsize=134217728
Okay I got the right file, as after reboot I got it mounted:
[email protected]:/ # df
Filesystem Size Used Free Blksize
...
/storage/sdcard1 231.0G 187.5M 230.9G 4096
...
I do not understand "voldmanaged=sdcard1:auto", so I need to stop here and wait for your further support.
I have already played around a lot also with the information from android source website, which I cannot link here (new user)
[email protected] said:
Actually I am not used to writing in those forum systems, so my original try to answer is now blocked
---------- Post added at 01:10 AM ---------- Previous post was at 12:59 AM ----------
I try without any quotes and just a very short version:
Actually I forgot that I had a mini card reader and sdcard in the 3G USB plugged in, without this card it is in fact sda1
---------- Post added at 01:22 AM ---------- Previous post was at 01:10 AM ----------
... Nevertheless it didn't worked, so I searched and found fstab.archosa101hboard is not really in use and I changed init.archosa101hboard.rc first.
---------- Post added at 01:27 AM ---------- Previous post was at 01:22 AM ----------
please try a grep fstab.archosa init* to find that always the sboard fstab files are mounted
---------- Post added at 01:38 AM ---------- Previous post was at 01:27 AM ----------
Don't know if this can be useful information for you in init.archosa.*board.rc files, but I found in init.rc this import line via ${ro.hardware}:
import /init.${ro.hardware}.rc
Click to expand...
Click to collapse
Thanks for your report ! The fstab is loaded on specific archos model init file.
Code:
on fs
# mount partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
mount_all /fstab.archosa101hboard
swapon_all /fstab.archosa101hboard
This init file is loaded on top at the init.archos_init.rc file. The ${ro.hardware} reflects the model property. You can verify this with
Code:
adb shell getprop ro.hardware
.
Then the correct fstab should loaded.
please try a grep fstab.archosa init* to find that always the s board fstab files are mounted
Click to expand...
Click to collapse
PS: Which version do you use? I had a fix a few weeks ago (Correct fstab file name for non a80s devices.) which is used in newer releases.
back to the harddisk:
still not knowing why it didn't work I changed fstab.archosa101hboard to double-check my fix above is okay:
#/devices/platform/omap/omap_hsmmc.0 auto auto defaults voldmanaged=sdcard1:auto
#/dev/block/platform/omap/usbhs_omap/sda1 auto auto defaults voldmanaged=sdcard1:auto
/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2
/devices/platform/omap/musb-omap2430/musb-hdrc/usb2/2-1/2-1:1.0 auto auto defaults voldmanaged=usbdisk:auto
/dev/block/zram0 none swap defaults zramsize=134217728
Okay I got the right file, as after reboot I got it mounted:
[email protected]:/ # df
Filesystem Size Used Free Blksize
...
/storage/sdcard1 231.0G 187.5M 230.9G 4096
...
I do not understand "voldmanaged=sdcard1:auto", so I need to stop here and wait for your further support.
I have already played around a lot also with the information from android source website, which I cannot link here (new user)
Click to expand...
Click to collapse
The output of the df command is ok. Please check if it is possible to use the following:
Code:
/dev/block/platform/omap/usbhs_omap/sda1 auto auto defaults voldmanaged=sdcard1:auto
. The destination mount point is determined from the vold daemon, which starts the appropriate "sdcard" daemon.
Thank you all for your answers!
Great, the HDD is already avaliable in /dev/block/platform/omap/usbhs_omap/sda1... Why didn't I just do a find * | grep sda ...
I'm at the point where [email protected] is now, only difference is that I'm using the 80h files instead of the 101h ones.
- enable write on /
Code:
busybox mount -o remount,rw /
- edit fstab.archosa80hboard
Code:
#/devices/platform/omap/omap_hsmmc.0 auto auto defaults voldmanaged=sdcard1:auto #original
#/dev/block/platform/omap/usbhs_omap/sda1 auto auto defaults voldmanaged=sdcard1:auto #as suggested, doesn't work
/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2 #works
- edit init.archosa80hboard.rc
Code:
#mount partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs #as is
mount_all /fstab.archosa80hboard #replace s with h
swapon_all /fstab.archosa80hboard #replace s with h
I'm using Image 12_02_2014-20_55_45.7z, which was current last weekend at least
Maybe this has been reported before, but 12_02_2014-20_55_45.7z don't boot on my tab.
I get nothing, but a black screen and the green LED - not even the Archos logo or a logcat
Latest running version is 23_01_2014-21_52_56
[email protected] said:
Maybe this has been reported before, but 12_02_2014-20_55_45.7z don't boot on my tab.
I get nothing, but a black screen and the green LED - not even the Archos logo or a logcat
Latest running version is 23_01_2014-21_52_56
Click to expand...
Click to collapse
That's weird.... I get this behavior in case I'm flash via SDE and when I choose "Flash kernel and initramfs" the USB drive is mounted on my PC.
When I copy the two files to the destination, sometimes I forget to unmount the removable storage drive and choose "continue" (or something like this) on the tablet. Then the incomplete kernel/initramfs files are written to the internal ssd which causes the black screen on start.
Can you please check if this was also the case?
[email protected] said:
Maybe this has been reported before, but 12_02_2014-20_55_45.7z don't boot on my tab.
I get nothing, but a black screen and the green LED - not even the Archos logo or a logcat
Latest running version is 23_01_2014-21_52_56
Click to expand...
Click to collapse
If I don't open a terminal and sudo sync before disconnecting the usb cable it happens most of the time for me.
stevemp said:
If I don't open a terminal and sudo sync before disconnecting the usb cable it happens most of the time for me.
Click to expand...
Click to collapse
Quallenauge said:
That's weird.... I get this behavior in case I'm flash via SDE and when I choose "Flash kernel and initramfs" the USB drive is mounted on my PC.
When I copy the two files to the destination, sometimes I forget to unmount the removable storage drive and choose "continue" (or something like this) on the tablet. Then the incomplete kernel/initramfs files are written to the internal ssd which causes the black screen on start.
Can you please check if this was also the case?
Click to expand...
Click to collapse
Thank you for the suggestions, so I could find out a bit what is actually my problem:
I did in fact not disconnecting the USB cable before rebooting.
This was never a problem for the old versions - may be you could add this to your installation instructions if really necessary:
Quallenauge said:
- reboot into SDE menu and under Developer Edition Mernu , Flash Kernel and Initramfs : copy zImage and initramfs.cpio.lzo on the new driver that appears on desktop/laptop
- Wait for reboot your devices : after reboot you can see Android prepares the system for a while .....be patient !
Click to expand...
Click to collapse
Nevertheless the device immediately stops (freeze) also directly when I later plug in the USB cable and further after a short time it shows again a black screen and the green LED. I have also tested to connect an OTG cable adapter and it also directly stops (with and without a mouse). Sometimes after plugging off the cable the device automatically reboots.
I switched the 3g dongle on to test the other USB port with a mouse, but no lights - it doesn't work either.
I have no time for testing now and for the rest of the week, I'll check next week for requested logs or a new version fixing it. :fingers-crossed:
Cheers!
[email protected] said:
Thank you for the suggestions, so I could find out a bit what is actually my problem:
I did in fact not disconnecting the USB cable before rebooting.
This was never a problem for the old versions - may be you could add this to your installation instructions if really necessary:
Click to expand...
Click to collapse
Sorry, I meant something different :angel: You can leave the USB cable plugged into the device. I mean, you have to eject (sign off,...) the drive removable in windows / linux after you finish the file transfer to the device (both when you copy the kernel+initramfs and also when updating the archos.ext4.update file). This way the data is synced on the device (to avoid corrupted data).
[email protected] said:
Nevertheless the device immediately stops (freeze) also directly when I later plug in the USB cable and further after a short time it shows again a black screen and the green LED. I have also tested to connect an OTG cable adapter and it also directly stops (with and without a mouse). Sometimes after plugging off the cable the device automatically reboots.
I switched the 3g dongle on to test the other USB port with a mouse, but no lights - it doesn't work either.
I have no time for testing now and for the rest of the week, I'll check next week for requested logs or a new version fixing it. :fingers-crossed:
Cheers!
Click to expand...
Click to collapse
Does at least the archos screen appear before the screen goes black?
Quallenauge said:
Sorry, I meant something different :angel: You can leave the USB cable plugged into the device. I mean, you have to eject (sign off,...) the drive removable in windows / linux after you finish the file transfer to the device (both when you copy the kernel+initramfs and also when updating the archos.ext4.update file). This way the data is synced on the device (to avoid corrupted data).
Does at least the archos screen appear before the screen goes black?
Click to expand...
Click to collapse
Actually I am using linux and I follow exactly your process with sync and umount ... and I was used to leaving the USB cable plugged into the device, but starting with CM 11.0 from 11_02_2014-23_03_07 the tablet was not booting and the archos screen did not appear any more.
I saw that you classified the kernel "Important: Highly experimental!" and "No "H" model support", so I thought just "bad luck" and went back to the old version. (and I bought a sony xperia tablet s)
stevemp wrote "before disconnecting the usb cable", so I tried also without the cable and it boots. Later I realized that I cannot use the micro USB plug at all, because the tablet directly freeze when I connect anything to it. (No problem with power, as the H model has a separated power plug)
May be I didn't explained it well: It always freeze: either before booting or/and also during booting or/and also after booting in normal operating: just plug it in -> directly freeze.
I have no idea what happens and how it can be analyzed.
This happens not when I run CM 11.0 version from 23_01_2014-21_52_56, so I do not believe in a hardware bug.
[email protected] said:
Actually I am using linux and I follow exactly your process with sync and umount ... and I was used to leaving the USB cable plugged into the device, but starting with CM 11.0 from 11_02_2014-23_03_07 the tablet was not booting and the archos screen did not appear any more.
I saw that you classified the kernel "Important: Highly experimental!" and "No "H" model support", so I thought just "bad luck" and went back to the old version. (and I bought a sony xperia tablet s)
stevemp wrote "before disconnecting the usb cable", so I tried also without the cable and it boots. Later I realized that I cannot use the micro USB plug at all, because the tablet directly freeze when I connect anything to it. (No problem with power, as the H model has a separated power plug)
May be I didn't explained it well: It always freeze: either before booting or/and also during booting or/and also after booting in normal operating: just plug it in -> directly freeze.
I have no idea what happens and how it can be analyzed.
This happens not when I run CM 11.0 version from 23_01_2014-21_52_56, so I do not believe in a hardware bug.
Click to expand...
Click to collapse
Thanks for your explanation! Now it's clear for me, the update process was done correctly.
Sadly, I updated the kernel since the 23_01_2014-21_52_56, so I think this is a kernel bug, which affects the JMicron USB SATA controller :-/
Sadly only a few people has a serial cable connected to their *H devices, so we don't have an easy way to track down this issue.
I see a light chance to get the boot log. I can send you a archive where you can test the kernel from your existing installation.
If you have time for some experiments, let me know.
Quallenauge said:
Thanks for your explanation! Now it's clear for me, the update process was done correctly.
Sadly, I updated the kernel since the 23_01_2014-21_52_56, so I think this is a kernel bug, which affects the JMicron USB SATA controller :-/
Sadly only a few people has a serial cable connected to their *H devices, so we don't have an easy way to track down this issue.
I see a light chance to get the boot log. I can send you a archive where you can test the kernel from your existing installation.
If you have time for some experiments, let me know.
Click to expand...
Click to collapse
Yeah, I can test it, but I think not before Monday next week.
Quallenauge said:
I had a fix a few weeks ago (Correct fstab file name for non a80s devices.) which is used in newer releases.
Click to expand...
Click to collapse
Sorry your fix does not really correct all:
Code:
localhost / # grep fstab.archosa init*
init.archosa101[B]h[/B]board.rc: mount_all /fstab.archosa101[B]s[/B]board
init.archosa101[B]h[/B]board.rc: swapon_all /fstab.archosa101[B]s[/B]board
...
After fixing this I have also tested a bit changing the fstab.archosa101hboard.rc file, as your described, but I couldn't get the hard disk mounted with the voldmanaged=sdcard1:auto setting.
Only this line automatically mount it:
Code:
/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2
I also wonder about a link (/sys/class/block/sda1) which has no correct target:
Code:
localhost / # find / -name sda1 2>/dev/null
/sys/class/block/sda1
/dev/block/sda1
/dev/block/platform/omap/usbhs_omap/sda1
localhost / # ls -l /sys/class/block/sda1 /dev/block/sda1 /dev/block/platform/omap/usbhs_omap/sda1
lrwxrwxrwx 1 root root 15 Mar 7 00:16 /dev/block/platform/omap/usbhs_omap/sda1 -> /dev/block/sda1
brw------- 1 root root 8, 1 Mar 7 00:16 /dev/block/sda1
lrwxrwxrwx 1 root root 0 Mar 7 00:22 /sys/class/block/sda1 -> ../../devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.1/1-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1
/sys/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.1 does not exist, just
/sys/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1/1-1:1.0
Code:
localhost / # ls -l /sys/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1
drwxr-xr-x 4 root root 0 Mar 7 00:22 1-1:1.0
-rw-r--r-- 1 root root 4096 Mar 7 00:22 authorized
-rw-r--r-- 1 root root 4096 Mar 7 00:22 avoid_reset_quirk
-rw-r--r-- 1 root root 4096 Mar 7 00:22 bConfigurationValue
-r--r--r-- 1 root root 4096 Mar 7 00:22 bDeviceClass
-r--r--r-- 1 root root 4096 Mar 7 00:22 bDeviceProtocol
-r--r--r-- 1 root root 4096 Mar 7 00:22 bDeviceSubClass
-r--r--r-- 1 root root 4096 Mar 7 00:22 bMaxPacketSize0
-r--r--r-- 1 root root 4096 Mar 7 00:22 bMaxPower
-r--r--r-- 1 root root 4096 Mar 7 00:22 bNumConfigurations
-r--r--r-- 1 root root 4096 Mar 7 00:22 bNumInterfaces
-r--r--r-- 1 root root 4096 Mar 7 00:22 bcdDevice
-r--r--r-- 1 root root 4096 Mar 7 00:22 bmAttributes
-r--r--r-- 1 root root 4096 Mar 7 00:22 busnum
-r--r--r-- 1 root root 4096 Mar 7 00:22 configuration
-r--r--r-- 1 root root 65553 Mar 7 00:22 descriptors
-r--r--r-- 1 root root 4096 Mar 7 00:22 dev
-r--r--r-- 1 root root 4096 Mar 7 00:22 devnum
-r--r--r-- 1 root root 4096 Mar 7 00:22 devpath
lrwxrwxrwx 1 root root 0 Mar 7 00:22 driver -> ../../../../../../../bus/usb/drivers/usb
drwxr-xr-x 3 root root 0 Mar 7 00:22 ep_00
-r--r--r-- 1 root root 4096 Mar 7 00:22 idProduct
-r--r--r-- 1 root root 4096 Mar 7 00:22 idVendor
-r--r--r-- 1 root root 4096 Mar 7 00:22 maxchild
drwxr-xr-x 2 root root 0 Mar 7 00:22 power
-r--r--r-- 1 root root 4096 Mar 7 00:22 quirks
--w------- 1 root root 4096 Mar 7 00:22 remove
-r--r--r-- 1 root root 4096 Mar 7 00:22 speed
lrwxrwxrwx 1 root root 0 Mar 7 00:22 subsystem -> ../../../../../../../bus/usb
-rw-r--r-- 1 root root 4096 Mar 7 00:22 uevent
-r--r--r-- 1 root root 4096 Mar 7 00:22 urbnum
drwxr-xr-x 3 root root 0 Mar 7 00:22 usb_device
-r--r--r-- 1 root root 4096 Mar 7 00:22 version
localhost / # ls -l /sys/devices/platform/omap/usbhs_omap/ehci-omap.0/usb1/1-1:1.0
-r--r--r-- 1 root root 4096 Mar 7 00:22 bAlternateSetting
-r--r--r-- 1 root root 4096 Mar 7 00:22 bInterfaceClass
-r--r--r-- 1 root root 4096 Mar 7 00:22 bInterfaceNumber
-r--r--r-- 1 root root 4096 Mar 7 00:22 bInterfaceProtocol
-r--r--r-- 1 root root 4096 Mar 7 00:22 bInterfaceSubClass
-r--r--r-- 1 root root 4096 Mar 7 00:22 bNumEndpoints
lrwxrwxrwx 1 root root 0 Mar 7 00:22 driver -> ../../../../../../../../bus/usb/drivers/hub
drwxr-xr-x 3 root root 0 Mar 7 00:22 ep_81
-r--r--r-- 1 root root 4096 Mar 7 00:22 modalias
drwxr-xr-x 2 root root 0 Mar 7 00:22 power
lrwxrwxrwx 1 root root 0 Mar 7 00:22 subsystem -> ../../../../../../../../bus/usb
-r--r--r-- 1 root root 4096 Mar 7 00:22 supports_autosuspend
-rw-r--r-- 1 root root 4096 Mar 7 00:22 uevent
I've also played around a little bit, but without any further progress...
- tried to just mount hdd over whatever is on /storage/sdcard0 -> doesn't work as sdcard0 is a link to Storage/emulated/legacy which itself is again a link to /mnt/shell/emulated/0 and apps seem to use that. Mounting on top of /mnt/shell/emulated/0 also doesn't work for some reason unknown to me :crying:
- had a look at vold configuration file in /system/etc/vold.A80H.fstab (in the case of my A80), but I don't even know if that file is interpreted at some time. Changing the faulty hdd path in there had no effect whatsoever.
I'm back to one of the rooted Archos Images, as I want to actually use the thing again I don't think there is a way to dual boot to do some further investigations?
Hi @Quallenauge,
(I don't know if I can talk about it here but it has a relation with the latest kernel update you've done) With your last update, I have a little problem : Indeed my Internal storage is recognized as an external SDcard when I use the file explorer and also I don't have access to the contents of my Internal storage in my computer.
Thank you in advance.
Hi again,
I could actually manage to use the HD for apps and data. It was easier than expected, but still a hack and need some tuning. So don't blame me if it doesn't run on your device.
Okay here is what I have done:
(I use Ubuntu and don't know how to do it on Windows or iOS)
a) Reset and format the device and the HD to start with a clean environment. (Don't forget to save your data somewhere outside)
b) Download and extract @Quallenauge 's CM11 ROM 09_03_2014-12_04_52
c) Mount the archos.ext4.update file
d) Fix the init.archosa101hboard.rc (init.archosa80hboard.rc) file to get the correct file loaded fstab.archosa101hboard (fstab.archosa80hboard.rc)
-> Just seach for 101s (80s) and change to 101h (80h)
e) Change fstab.archosa101hboard (fstab.archosa80hboard.rc) to use the HD for /data:
Code:
#/dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS /system ext4 ro,barrier=1 wait
#/dev/block/platform/omap/omap_hsmmc.1/by-name/EFS /efs ext4 nosuid,nodev,barrier=1 wait,check
#/dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data ext4 noatime,nosuid,nodev,barrier=1,discard,noauto_da_alloc,journal_async_commit wait,check,encryptable=footer
#/dev/block/platform/omap/omap_hsmmc.1/by-name/CACHE /cache ext4 noatime,nosuid,nodev,barrier=1,discard,noauto_da_alloc,journal_async_commit wait,check
# mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# mount ext4 /dev/block/mmcblk0p2 /mnt/system noatime nosuid noexec
# mount ext4 /dev/block/mmcblk0p4 /data noatime nosuid
#/dev/block/mmcblk0p1 /mnt/rawfs rawfs
/dev/block/mmcblk0p2 /mnt/system ext4 noatime,nosuid,noexec wait
#/dev/block/mmcblk0p4 /data ext4 noatime,nosuid wait,check,encryptable=footer
/dev/block/platform/omap/usbhs_omap/sda1 /data ext4 defaults 0 2
/devices/platform/omap/omap_hsmmc.0 auto auto defaults voldmanaged=sdcard1:auto
/devices/platform/omap/musb-omap2430/musb-hdrc/usb2/2-1/2-1:1.0 auto auto defaults voldmanaged=usbdisk:auto
#/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2
/dev/block/zram0 none swap defaults zramsize=134217728
f) Unmount the archos.ext4.update file
g) Install as usual
My impressions:
- I could install all (!) my apps :laugh:
- I have still only 512 MB RAM, so e.g. Adblock Plus be stopped when Chrome is running. I have installed Greenify, which helps a bit. Need more investigation. Any thoughts are welcome!
- Booting takes a bit longer
- As the HD is used to falling quick back in sleep mode and it cannot cache all needed files, it takes some extra time to open an app or switch to one of the other screens.
- Don't know what to do with /dev/block/mmcblk0p4 - Can we use it for caching the HD or as swap device?
- After some time sleeping, the device need to reboot by long pressing on/off (I think that is in discussion in the main [ROM] [4.4.2] CyanogenMod 11.0 thread)
- Not tested yet, but activating the 3g dongle for USB memory would change the HD partiion from sda1 to sdb1, so wouldn't run. Maybe copying the HD to a SD card would be nice to have.
- Battery time: Don't know, as it is always plugged in
At the end I think it is the best ROM for this poor device - so thanks again @Quallenauge
[email protected] said:
Hi again,
I could actually manage to use the HD for apps and data. It was easier than expected, but still a hack and need some tuning. So don't blame me if it doesn't run on your device.
Okay here is what I have done:
(I use Ubuntu and don't know how to do it on Windows or iOS)
a) Reset and format the device and the HD to start with a clean environment. (Don't forget to save your data somewhere outside)
b) Download and extract @Quallenauge 's CM11 ROM 09_03_2014-12_04_52
c) Mount the archos.ext4.update file
d) Fix the init.archosa101hboard.rc (init.archosa80hboard.rc) file to get the correct file loaded fstab.archosa101hboard (fstab.archosa80hboard.rc)
-> Just seach for 101s (80s) and change to 101h (80h)
e) Change fstab.archosa101hboard (fstab.archosa80hboard.rc) to use the HD for /data:
Code:
#/dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS /system ext4 ro,barrier=1 wait
#/dev/block/platform/omap/omap_hsmmc.1/by-name/EFS /efs ext4 nosuid,nodev,barrier=1 wait,check
#/dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data ext4 noatime,nosuid,nodev,barrier=1,discard,noauto_da_alloc,journal_async_commit wait,check,encryptable=footer
#/dev/block/platform/omap/omap_hsmmc.1/by-name/CACHE /cache ext4 noatime,nosuid,nodev,barrier=1,discard,noauto_da_alloc,journal_async_commit wait,check
# mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# mount ext4 /dev/block/mmcblk0p2 /mnt/system noatime nosuid noexec
# mount ext4 /dev/block/mmcblk0p4 /data noatime nosuid
#/dev/block/mmcblk0p1 /mnt/rawfs rawfs
/dev/block/mmcblk0p2 /mnt/system ext4 noatime,nosuid,noexec wait
#/dev/block/mmcblk0p4 /data ext4 noatime,nosuid wait,check,encryptable=footer
/dev/block/platform/omap/usbhs_omap/sda1 /data ext4 defaults 0 2
/devices/platform/omap/omap_hsmmc.0 auto auto defaults voldmanaged=sdcard1:auto
/devices/platform/omap/musb-omap2430/musb-hdrc/usb2/2-1/2-1:1.0 auto auto defaults voldmanaged=usbdisk:auto
#/dev/block/platform/omap/usbhs_omap/sda1 /storage/sdcard1 ext4 defaults 0 2
/dev/block/zram0 none swap defaults zramsize=134217728
f) Unmount the archos.ext4.update file
g) Install as usual
My impressions:
- I could install all (!) my apps :laugh:
- I have still only 512 MB RAM, so e.g. Adblock Plus be stopped when Chrome is running. I have installed Greenify, which helps a bit. Need more investigation. Any thoughts are welcome!
- Booting takes a bit longer
- As the HD is used to falling quick back in sleep mode and it cannot cache all needed files, it takes some extra time to open an app or switch to one of the other screens.
- Don't know what to do with /dev/block/mmcblk0p4 - Can we use it for caching the HD or as swap device?
- After some time sleeping, the device need to reboot by long pressing on/off (I think that is in discussion in the main [ROM] [4.4.2] CyanogenMod 11.0 thread)
- Not tested yet, but activating the 3g dongle for USB memory would change the HD partiion from sda1 to sdb1, so wouldn't run. Maybe copying the HD to a SD card would be nice to have.
- Battery time: Don't know, as it is always plugged in
At the end I think it is the best ROM for this poor device - so thanks again @Quallenauge
Click to expand...
Click to collapse
Nice work [email protected] I'm glad someone is still trying to bring this tablet to the present. Let me know if you need a tester. I have a 80 G9 Turbo 250GB.
I was attempting to root my LG-D851 on TMO with PurpleDrake SW version [V10r] and I received this message:
ERROR: Something went wrong. Permaroot doesn't appear to have worked, rebooting phone.
Debug information - 'ls -l /system/xbin/su':
/system/xbin/su: No such file or directory
------------------------
Debug information - 'ls -l /temp/':
-rw-r--r-- root root 2187 1970-03-15 22:45 br_daemon.log
-rw-r--r-- root root 36 1970-03-15 22:44 brd_ready
-rw-r--r-- root root 2 1970-03-15 22:45 error
-rwsr-sr-x root root 157424 2014-07-12 03:54 fakesu
drwx------ root root 1970-03-15 22:45 hidden
-rw-r--r-- root root 28 1970-03-15 22:45 start_restore_complete
------------------------
So, we temprooted your phone, but we weren't able to permaroot it for some reason.
Click to expand...
Click to collapse
Help would be greatly appreciated. If you need more information please let me know.
http://forum.xda-developers.com/showthread.php?t=3004158
[ROOT]How to Root KVT49L.D85110r and Install TWRP. My experience
Sent from my LG-D851 using XDA Free mobile app
I have created this thread in order to have one thread that details just the solution to fixing your persist, identifying whether or not you have an issue with your persist, and how you can restore your IMEI without hacks. This guide is written for Motorola Moto G5 Plus (Potter). The issue also affects other models, e.g. G5, G5S, G5S Plus, but the guide appears to apply consistently to all of these models. Note that links in this thread are of course for potter.
For information on the history of this issue, refer to the following thread:
[dev][info] imei 0
IMPORTANT: There are a number of poor copy/paste jobs of parts of this guide floating around. Please link to this guide rather than posting only select parts of this (i.e. flashable zips, list of commands with no explanation). One of the lessons we all should have learned from this issue is to not just blindly follow guides because of "Hey this really works you should do it too trust me it works". The explanation and understanding is important, which is why I have taken the time to be as detailed as I have.
This thread is broken down into the following sections:
Asking for help
Pre-requisites
How to tell if you have an issue with your persist, and if it is recoverable
How to fix persist
Explanation
Before starting though, there is one thing to keep in mind - for this to work YOU MUST HAVE YOUR OWN PERSIST. If you flashed someone else's persist, or a persist from another device, the fix will not work. Your only hope is to have a backup of your own persist that you can restore.
0) Asking for help
If you need to ask for help in following this guide (specifically about any problems you have trying to restore your persist and/or IMEI), please provide the following information (preferably copy/paste this into your post):
- Which version of STOCK rom are you on?
- Are you rooted, and running the commands under root privileges?
- Have you ever flashed someone else's, or another device's persist?
- What functionality are you missing and trying to restore (e.g. IMEI=0, VolTE, etc)?
- Do you get any error messages when trying to execute the commands?
Please also include the full output of the commands below. Ideally wrap the output in 'code tags' so it is nicely formatted
Update 2018-09-16
Now that stock Oreo is starting to roll out (ever so slowly...), it is an important point to note that you can now simply upgrade to stock Oreo to overcome the issue described in this guide. Stock Oreo changes the ownership of the relevant folders in persist on every boot.
TWRP flashable Oreo builds are available here [Oreo][Stock][Rom] TWRP Flashable Stock Builds. Do also read the first two posts in detail, as they also cover how to revert to stock Nougat, should you ever wish to move to a custom Oreo rom.
1) Pre-requisites
You must currently be on a Stock Nougat ROM. Either the fastboot or TWRP flashable stock roms. You can get the latest TWRP flashable stock roms from this thread: [New][Stock][Rom] TWRP Flashable Stock Builds
You must be using your own persist.
You must have root access within the stock ROM. All scripts below MUST be run with root permissions
2) How to tell if you have an issue with your persist, and if it is recoverable
From a shell (either adb, or a terminal app on your device), type in the following commands:
Code:
su
ls -l /persist
The su command is to get root, and the 'ls' command lists details about the files in persist, including owners and permissions. On a fully operational persist, you will get a listing like this:
Code:
potter_n:/ # ls -l /persist
total 168
drwxrwx--- 2 system system 4096 2018-08-04 16:44 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1970-01-01 12:03 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2018-08-04 16:44 bluetooth
drwx------ 2 root system 4096 1970-01-01 12:03 bms
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1970-01-01 12:03 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 2018-08-04 16:44 camera
drwx------ 6 system system 4096 2018-08-04 16:44 data
drwxrwx--- 2 system system 4096 1970-01-01 12:03 drm
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 2018-08-04 16:44 factory
[COLOR="red"]drwxrwx--- 3 rfs rfs_shared 4096 2018-08-04 16:44 hlos_rfs[/COLOR]
drwxrwx--- 2 root root 4096 2018-08-04 16:44 lost+found
drwxrwx--- 2 radio radio 4096 2018-08-04 16:44 mdm
drwxrwx--- 2 system system 4096 1970-01-01 12:03 misc
drwxrwx--- 2 system system 4096 1970-10-15 07:43 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 2018-08-04 16:44 public
[COLOR="red"]drwx------ 6 rfs rfs 4096 2018-08-04 16:44 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2018-08-04 16:44 security
drwxrwxr-x 2 root root 4096 2018-08-04 16:44 sensors
drwxrwx--- 2 system system 4096 2018-08-04 16:44 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1970-01-01 12:03 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1970-01-01 12:03 wmdrm
The key here, is the rfs folder, and to a lesser degree, the hlos_rfs folder. Notice how the owner is rfs, and in the case of hlos_rfs, the group is rfs_shared.
Important - if you ran these commands from within an Oreo rom, you will see owners such as oem_2903 etc. These owners are valid for Oreo (custom or stock). The point of this guide is so that you know whether or not you have an ownership / permissions issue on Stock Nougat.
Additionally, if you run the following to look for files within persist:
Code:
find /persist -type f
You will see something like this:
Code:
potter_n:/ # find /persist -type f
/persist/sensors/sensors_settings
/persist/data/prov/eyBMMa7Jo5Dwo4LigJCHx3WxPUdQ9y8GJKIBae9bic
/persist/data/prov/prov
/persist/data/prov/prov.bak
/persist/data/prov/eyBMMa7Jo5Dwo4LigJCHx3WxPUdQ9y8GJKIBae9bic.bak
/persist/data/prov/T2pluw0BDr+EpzrrpM4aIMo1xKHY-DMHg3Uk3GF5yq
/persist/data/prov/T2pluw0BDr+EpzrrpM4aIMo1xKHY-DMHg3Uk3GF5yq.bak
/persist/data/widevine/Saljqyb2k7jJt0wZSxpXq0sdCZJH4urJjb-qcgkn7H
/persist/data/widevine/Saljqyb2k7jJt0wZSxpXq0sdCZJH4urJjb-qcgkn7H.bak
/persist/data/widevine/+CdCfjxBGljLnuTN7yCnhuY3WzhxbvHOjc-rac35xw
/persist/data/widevine/+CdCfjxBGljLnuTN7yCnhuY3WzhxbvHOjc-rac35xw.bak
/persist/camera/ledcal/rear
/persist/mdm/oma_dm_update
/persist/factory/regulatory/regulatory_info.png
/persist/factory/fti
/persist/public/hiddenmenu/data/mobile_data_rx
/persist/public/hiddenmenu/data/mobile_data_tx
/persist/public/hiddenmenu/data/wifi_data_rx
/persist/public/hiddenmenu/data/wifi_data_tx
/persist/security/18.bin
/persist/bluetooth/.bt_nv.bin
/persist/alarm/powerOffAlarmSet
/persist/alarm/timezone
/persist/alarm/powerOffAlarmInstance
/persist/time/ats_1
/persist/time/ats_2
/persist/time/ats_15
/persist/time/ats_12
/persist/time/ats_13
/persist/rfs/shared/server_info.txt
/persist/rfs/msm/mpss/datablock/id_00
/persist/rfs/msm/mpss/datablock/id_01
/persist/rfs/msm/mpss/server_check.txt
[COLOR="red"]/persist/rfs/msm/mpss/dhob.bin
/persist/rfs/msm/mpss/shob.bin
/persist/rfs/msm/mpss/dhob.bin.bak
[/COLOR]
The key files here are those in the /persist/rfs folder, mainly the dhob.bin file, which is used in creation of the EFS (i.e. the modemst1 and modemst2 partitions).
If you do not have the files under the /persist/rfs folder, then you will not be able to restore your persist through this method. Also see post #3 for information on when you have a dhob.bin but no dhob.bin.bak.
Now, if you run the ls command on a 'bad persist', you will get the following output from the ls command:
Code:
potter_n:/ # ls -l /persist
total 208
drwxrwx--- 2 system system 4096 2018-08-05 11:48 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1970-01-01 12:03 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2018-08-05 11:48 bluetooth
drwx------ 2 root system 4096 1970-01-01 12:03 bms
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1970-01-01 12:03 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 2018-08-05 11:48 camera
drwxrwx--- 2 system system 4096 2018-08-05 11:48 chargeonly
drwx------ 6 system system 4096 2018-08-05 11:48 data
drwxrwx--- 2 system graphics 4096 1971-01-22 16:48 display
drwxrwx--- 2 system system 4096 1970-01-01 12:03 drm
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 2018-08-05 11:48 factory
[COLOR="Red"]drwxrwx--- 3 2951 2952 4096 2018-08-05 11:48 hlos_rfs[/COLOR]
drwxrwx--- 2 root root 4096 2018-08-05 11:48 lost+found
drwxrwx--- 2 radio radio 4096 2018-08-05 11:48 mdm
drwxrwx--- 2 system system 4096 1970-01-01 12:03 misc
drwxrwx--- 2 system system 4096 1970-10-15 07:43 properties
drwxr-xr-x 11 mot_tcmd mot_tcmd 4096 2018-08-05 11:48 public
[COLOR="Red"]drwx--x--x 6 2951 2951 4096 2018-08-05 11:48 rfs[/COLOR]
drwx------ 2 root root 4096 1971-01-22 16:48 sds
drwxrwx--- 2 system system 4096 1971-01-22 16:48 secnvm
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2018-08-05 11:48 security
drwxrwxr-x 2 root root 4096 2018-08-05 11:48 sensors
drwxrwx--- 2 system system 4096 2018-08-05 11:48 time
drwxrwx--- 2 media media 4096 1971-01-22 16:48 vpp
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1970-01-01 12:03 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1970-01-01 12:03 wmdrm
The lines above in red, show that the ownership of the rfs and hlos_rfs folders are numbers, i.e. they are unknown to the system. To resolve, we need to change the ownership.
3) How to fix your persist
To fix the ownership, use the following commands (use su if not in a root shell):
Code:
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
ls -l /persist
Now when the ls command shows the ownership of the folders, you should see the correct ownership.
Fixing your IMEI if it was zero
If your IMEI was zero, reboot, and cross your fingers that you will have your IMEI back (Settings > About Phone > Status > IMEI information).
NEW - TWRP flashable Stock Persist Fix
I've created a TWRP flashable zip that does the above ownership fixes. The script has slight differences, it uses the AIDs (Android IDs) of rfs and rfs_shared in stock.
potter-stock-persist-fix.zip
4) Explanation
4a) What happened to persist.
To understand what happened, you need to know a few things about filesystem permissions in Linux. Files and folders have user and group ownership, and permissions. Examples of owners are the system, root, user, etc. Examples of permissions are read access, write access, execute access. The permissions are applied at three levels 1) the user, 2) the group, 3) everyone else.
@rachitrawat's investigation into the failures showed that the issue was relating to the persist partition, specifically some files dhob.bin etc that are under the rfs sub folder in this partition. Under stock, these files/folders are owned by a user called rfs, and have group ownership under a group also called rfs. Additionally, the permissions on these files/folders are limited - only the rfs user can read/write/execute these files. Other users, groups, or everyone else, cannot access the files.
Edit: This part here wasn't quite correct, it is fixed below. It kind of still applies, but only if looking from within TWRP (I wrongly assumed that TWRP had the same user names as Lineage, my bad!):
So something happened in the Oreo roms. If you flash and boot into an Oreo rom, and you look at the permissions/ownership, you will see exactly the same ownership patterns as stock. But there's a catch!
There was a change in the Oreo roms. If you flash and boot into an Oreo rom, and you look at the permissions/ownership, you will see that a user and group oem_2951 owns the rfs folder, and a group oem_2952 owns the hlos_rfs folder. Now this is a different name, but on its own, a different name does not mean different ownership.
In Linux, all users and groups are assigned an ID, i.e. a number. So for example, on my phone, the rfs user has ID 3012 under stock. In lineage oreo, the oem_2951 user has ID 2951. So something happened in lineage that changed the user IDs that are applied to the rfs folder.
If you look at the ownership of persist files/folders within TWRP, you will see that a STOCK PERSIST has the owner of the rfs folder as rfs_old. Similarly in TWRP, a LINEAGE PERSIST has the owner of the rfs folder as rfs. So TWRP is seeing owners differently again to stock and Lineage. Trying to run the above commands in TWRP will not fix the issue, as it will use ID 2951 for the user rfs, but we need it to be 3012 in stock (which TWRP sees as rfs_old).
In addition to the rfs folder, there is also another folder that is impacted - hlos_rfs. Its user owner is rfs, but its group owner if rfs_shared. A stock rfs_shared is shown as rfs_shared_o in TWRP. It appears that this folder is not as important in getting the IMEI back, but I have included the commands to restore ownership, to ensure there are no future errors.
4b) What happened to IMEI.
Despite the issue above, many people who flashed Oreo roms would have had no problems (other than I guess, bugs in the roms themselves). The change of ownership of the rfs folder didn't change the actual file content, so essentially all is intact. In fact, I verified that my dhob.bin and other files had the same md5sum in stock and lineage persist.
The issue of the IMEI changing to zero has only happened when people have flashed Stock roms. All of the guides that I have seen, have included the following commands (and equivalent commands have been included in the TWRP flashable stock builds as well):
Code:
fastboot erase modemst1
fastboot erase modemst2
The partitions modemst1 and modemst2 are your EFS. Normally, if your persist is pure stock, if either is erased, the modem re-creates them. But, referring to the above about permissions, if the rfs user (which is presumably used by the modem) cannot access the files (because the owner of the files is someone else, and the permissions on the files mean that only the owner can access them), then the modem cannot recreate the EFS, and the IMEI is left as zero.
4c) Restoring IMEI.
Changing the ownership of your otherwise untouched persist allows the rfs user to access those files. Rebooting will result in the modem checking the EFS, and when it sees that it is still blank, it will recreate the IMEI.
However, the dhob.bin file in persist is encrypted, and goes through some sort of hash check. You can only use your own dhob.bin to recreate the IMEI. This is why it is essential that you have your own persist, and no one else's will work.
5) Other info
Other things that may be good to know about this issue.
5a) Why did flashing another device's persist fix Volte?
Or rather, why did flashing another device's persist "fix Volte" at the expense of permanently breaking key functionality of your device?
Flashing another device's persist gave the impression of working, but most probably this was due to one thing alone - the permissions on the persist partition of Moto devices is similar. That is, other Moto devices have rfs and hlos_rfs folders, and the owner is the same (both in name and AID - Android ID).
So, after flashing a custom Oreo rom, then going back to stock, Volte would not work. However, if they hadn't erased modemst1/2 (EFS) they would still have IMEI, but other functionality would be broken (Volte, 4G, possibly others). Flashing the other persist changed the permissions to the right ones, and boom all of a sudden Volte worked. The regret comes after, when the user has erased EFS through an update or other flash.
XDA:DevDB Information
The Persist Project, Tool/Utility for the Moto G5 Plus
Contributors
NZedPred, rachitrawat
Version Information
Status: Stable
Created 2018-08-05
Last Updated 2018-09-15
Backing up your persist
One thing that cannot be emphasized enough is that you must keep backups of your persist. (Your efs is even more important to backup if you no longer have your own persist.) Once backed up, make a copy on your PC or laptop, and keep a private cloud copy somewhere as well.
Recent versions of TWRP have made it easy to back up your persist partition. Older versions may not have had native functionality to back it up, however there was also an alternative. Relevant details below.
TWRP backup of persist (recommended)
The official TWRP thread is below. You should consult this thread to check for the latest versions.
[RECOVERY][OFFICIAL][potter] TWRP 3.2.2-0 touch recovery
At the time of writing (2018-08-05), there was a special build made that fixed backing up with encryption. This is the one that I have used in my testing. Link below:
https://forum.xda-developers.com/showpost.php?p=77207112&postcount=199
You will see persist as an available option in Backup and Restore. The backup file will be called persist.ext4.win. It is in fact a tar archive, so you can extract it with tar if you want to examine the contents on your PC.
Image backup of persist
If you don't have TWRP handy, or an older version of it, you can instead use the dd command from a root shell (either within stock or within TWRP)
The following can be used to create a backup and place it at /sdcard/persist.img:
Code:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
The following can be used to restore a backup placed at /sdcard/persist.img:
Code:
dd if=/sdcard/persist.img of=/dev/block/bootdevice/by-name/persist
dd backups are bit-perfect, and can also be mounted if you need to look at a filesystem from e.g. your PC.
From post #77 - dhob.bin but no dhob.bin.bak
I'm repeating some findings from another post of mine further down the thread at post #77. It seems to be a common occurrence that unfortunately hasn't been solved.
OK, have done some more investigation into cases where there is a dhob.bin, but no dhob.bin.bak. This will be a long-ish post
So, a normal dhob.bin file looks like this in a hex editor / hex dump (limited to first 20 lines)
Code:
/persist/rfs/msm/mpss # hexdump dhob.bin | head -n20
0000000 7d60 fb6a 1c50 f9f9 54b0 04e1 76f3 7943
0000010 ae7b cb9b 7634 69e4 e6cc ac41 e54e 4444
0000020 860e 82c8 56d1 0cc0 0430 a6af 2652 7739
0000030 4936 1666 ee73 1e9e ef7f 2450 cc8b a999
0000040 56a0 d3ce 3e55 3852 bd23 fe5f 9c89 bdb9
0000050 b345 51e7 c056 43e6 6eba 9e3e 26cd fb9c
0000060 ea05 4edb 3dea 6cd5 a6ed 4b2f 1b16 8232
0000070 9203 d088 7477 5497 5ad6 cfa1 f176 98da
0000080 6d50 226e 8580 3ba3 c034 2176 b73d ec66
0000090 034c 97c7 a670 230a 04f0 318e c08e 930d
00000a0 7d51 3dc0 dd5c 2eb5 4fd2 b70a f929 83e3
00000b0 99fc 06dd a69d d5b5 4aca 8b35 f5bb c9cc
00000c0 3dcb ae6f 8d2d 5b00 55e8 bff3 7824 4ff5
00000d0 0399 cddd b337 709f 1b1c c828 972f 1cd7
00000e0 2420 c7fe 9981 1c42 5f8f a980 86c8 e416
00000f0 dccc 9847 cd26 a2b9 f6cc ecc5 7099 b466
0000100 d606 2fb4 dd08 048e d178 8d29 68c3 ed7e
0000110 2096 5751 39bd 6559 5e7d f43d 2184 e7e5
0000120 f6be ed1c 9722 92a9 a38a 4e7f d053 52a3
0000130 24d0 8347 62af 0f02 5e26 c3a9 b09a 1a26
A normal dhob.bin.bak looks like this (again, first 20 lines):
Code:
/persist/rfs/msm/mpss # hexdump dhob.bin.bak | head -n20
0000000 c0de 0002 3fb0 000c 1545 0006 d00d beef
0000010 0000 beef 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 beef 0000 0000 0000 beef
0000030 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 beef 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 beef 3001 3030 3030 0030
0000060 beef 3001 3030 3030 0030 beef 0000 beef
0000070 0801 153a 0958 8248 0353 beef 0801 153a
0000080 0958 8248 0453 beef 5301 4283 5908 3518
0000090 0000 beef 5701 0000 beef 0000 beef 0000
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000480 0000 0000 0000 0000 beef 0000 beef 0000
0000490 0000 0000 0000 0000 0000 0000 0000 0000
*
0000640 0000 0000 0000 0000 beef 0000 0000 0000
0000650 0000 0000 0000 0000 0000 0000 beef 0000
0000660 0000 0000 0000 0000 beef 0000 0000 0000
0000670 beef 0000 0000 0000 beef 0000 0000 0000
*
Reading the hexdump:
The left-most column is the address, so 0000000 is the top of the file, and it goes up in increments of 16 (10 hex).
The asterisks * in the latter just represent that the previous row was repeated up until it reached the row underneath. So row 00000a0 (which was all zeroes) was repeated right up until row 0000480 (which differed).
So, the summary of the two is this. 1) A dhob.bin looks like random stuff. 2) A dhob.bin.bak looks like slightly random stuff with a lot of zeroes. They are very distinct, and unlike what the bak extension may suggest, it is NOT a backup of dhob.bin.
So, as I mentioned a few posts previous, a couple of people have a dhob.bin, but no dhob.bin.bak. And interestingly, their dhob.bin does not look like a dhob.bin, it looks more like a dhob.bin.bak. I did a few experiments...
Experiment 1) - Change something in the dhob.bin and dhob.bin.bak
I changed a single byte in my dhob.bin and dhob.bin.bak (to ensure they were invalidated), erased EFS, and rebooted. In this case, the IMEI was of course not restored, and on checking the /persist/rfs/msm/mpss folder, the dhob.bin and dhob.bin.bak were both there.
Experiment 2) - Restore normal files, but delete dhob.bin
I restored my files, and removed the dhob.bin file, leaving the dhob.bin.bak and shob.bin. After rebooting, the dhob.bin file was restored, and so was my IMEI.
Experiment 3) - Delete dhob.bin, edit dhob.bin.bak
No dhob.bin, but a corrupt dhob.bin.bak. After reboot, there was a dhob.bin file, and no dhob.bin.bak. And, it seems, that the dhob.bin.bak file was simply renamed to dhob.bin.
So it appears that, for the dhob.bin.bak to become the dhob.bin file, someone/something has to remove the dhob.bin file. Keeping in mind that the dhob.bin.bak file appears to be used to recreate dhob.bin (probably with the help of shob.bin, I haven't experimented that much yet), and we know that the dhob.bin is encrypted in some way so that only the device it was made for can use it, it would appear that there has been some sort of manual intervention in the phones.
I suspect that is either 1) someone has restored another similar device's persist partition and manually or a custom rom has removed the dhob.bin file in an effort to get it recreated, or 2) well, I don't think there's a 2... (or rather, I can't think of it).
So at this point, if you only have a dhob.bin, and no dhob.bin.bak, and the guide doesn't work, something has been messed with, and at this point I have no solution.
Sorry for those that I'm working with at the moment, but I'm out of ideas.
Edit: Just to mention the obvious, for the couple of people that I have tried fixing by renaming dhob.bin to dhob.bin.bak, it didn't work. The dhob.bin.bak was simply renamed to dhob.bin again, indicating that the persist is probably not the one for the device, however that may have happened...
Click to expand...
Click to collapse
@NZedPred : As I said before, really nice catch.
One question: I made a img backup of persist using the dd commands. As you recommend the way saving it through TWRP, for me it's not clear if it's possible to backup persist with the 3.2.2.0 official TWRP or the special build is needed. I'm on the official one and would like to use it if there's no need to flash the other one. As there's no special " persist" backup option in it is it included somewhere else in the nandroid backup?
Well that's me screwed, I lost my persist before anyone knew wtf was going on.
Edit: If I fastboot stock while also using all the erase commands, will that leave me with original persist?. I am assuming so since after doing this in the past, I am left with 0 imei and 0 imei sv. If I use one of the shared persists, my imei sv changes to 8. If this is the case am I right to then assume this guide can work for anyone, even if they have no backup of original persist, since they can back up there own borked persist in twrp after a full fastboot job?.
Edit2: I think I am confusing persist with efs and how it rebuilds on erase. Is there a way to erase persist and let it rebuild much like efs folder would upon erase?
I got that error chown: bad user 'rfs' My phone is not g5 plus it's g5 and i was trying to fix it
here is the cmd window
Code:
1|cedric:/ # ls -l /persist
total 112
drwxrwx--- 2 system system 4096 1970-01-01 02:21 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 2018-08-05 08:29 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 1970-01-01 02:21 bluetooth
drwx------ 2 root system 4096 1970-01-01 02:21 bms
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1970-01-01 02:02 bt
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 camera
drwxrwx--- 2 system system 4096 1970-01-02 01:43 chargeonly
drwxr-xr-x 2 root root 4096 2017-11-22 11:25 coresight
drwx------ 4 system system 4096 2017-11-22 11:25 data
drwxrwx--- 2 system graphics 4096 1970-01-01 02:02 display
drwxrwx--- 2 system system 4096 1970-01-01 02:02 drm
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 1970-01-01 02:21 factory
drwxrwx--- 3 oem_2903 oem_2904 4096 2017-11-22 11:25 hlos_rfs
drwxrwx--- 2 root root 4096 2017-11-22 11:25 lost+found
drwxrwx--- 2 radio radio 4096 2017-11-22 11:25 mdm
drwxrwx--- 2 system system 4096 1970-01-01 02:21 misc
drwxrws--- 2 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 paks
drwxrwx--- 2 system system 4096 1970-07-07 12:32 properties
drwxr-xr-x 11 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 public
drwx--x--x 6 oem_2903 oem_2903 4096 2017-11-22 11:25 rfs
drwx------ 2 root root 4096 1970-01-02 01:43 sds
drwxrwx--- 2 system system 4096 1970-01-02 01:43 secnvm
drwxrws--- 2 drmrpc drmrpc 4096 1970-01-01 02:02 security
drwxrwxr-x 3 system system 4096 1970-01-02 01:43 sensors
drwxrwx--- 2 system system 4096 2018-08-05 08:30 time
drwxrwx--- 2 media media 4096 1970-01-02 01:43 vpp
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1970-01-01 02:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1970-01-01 02:02 wmdrm
Wolfcity said:
@NZedPred : As I said before, really nice catch.
One question: I made a img backup of persist using the dd commands. As you recommend the way saving it through TWRP, for me it's not clear if it's possible to backup persist with the 3.2.2.0 official TWRP or the special build is needed. I'm on the official one and would like to use it if there's no need to flash the other one. As there's no special " persist" backup option in it is it included somewhere else in the nandroid backup?
Click to expand...
Click to collapse
Hey, it may be that that special build is required. Perhaps my comment about 'recent versions of TWRP' wasn't quite correct, and only 'unofficial' versions have the persist option. The partition is not backed up anywhere else if it is not selected (or selectable).
Cupcake 1.5 said:
Well that's me screwed, I lost my persist before anyone knew wtf was going on.
Edit: If I fastboot stock while also using all the erase commands, will that leave me with original persist?. I am assuming so since after doing this in the past, I am left with 0 imei and 0 imei sv. If I use one of the shared persists, my imei sv changes to 8. If this is the case am I right to then assume this guide can work for anyone, even if they have no backup of original persist, since they can back up there own borked persist in twrp after a full fastboot job?.
Edit2: I think I am confusing persist with efs and how it rebuilds on erase. Is there a way to erase persist and let it rebuild much like efs folder would upon erase?
Click to expand...
Click to collapse
Yes, efs and persist are two completely different things. However, DO NOT ERASE PERSIST EVER!!! It is unique to your device, and without it you will lose functionality. If you have erased efs and it recreates on boot then chances are your persist is fine, and you should back it up.
My advise would be that, as long as your persist is your own, back it up and keep it safe.
AhmedtSadek said:
I got that error chown: bad user 'rfs' My phone is not g5 plus it's g5 and i was trying to fix it
here is the cmd window
Code:
1|cedric:/ # ls -l /persist
total 112
drwxrwx--- 2 system system 4096 1970-01-01 02:21 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 2018-08-05 08:29 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 1970-01-01 02:21 bluetooth
drwx------ 2 root system 4096 1970-01-01 02:21 bms
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1970-01-01 02:02 bt
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 camera
drwxrwx--- 2 system system 4096 1970-01-02 01:43 chargeonly
drwxr-xr-x 2 root root 4096 2017-11-22 11:25 coresight
drwx------ 4 system system 4096 2017-11-22 11:25 data
drwxrwx--- 2 system graphics 4096 1970-01-01 02:02 display
drwxrwx--- 2 system system 4096 1970-01-01 02:02 drm
drwxr-xr-x 5 mot_tcmd mot_tcmd 4096 1970-01-01 02:21 factory
drwxrwx--- 3 oem_2903 oem_2904 4096 2017-11-22 11:25 hlos_rfs
drwxrwx--- 2 root root 4096 2017-11-22 11:25 lost+found
drwxrwx--- 2 radio radio 4096 2017-11-22 11:25 mdm
drwxrwx--- 2 system system 4096 1970-01-01 02:21 misc
drwxrws--- 2 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 paks
drwxrwx--- 2 system system 4096 1970-07-07 12:32 properties
drwxr-xr-x 11 mot_tcmd mot_tcmd 4096 1970-01-02 01:43 public
drwx--x--x 6 oem_2903 oem_2903 4096 2017-11-22 11:25 rfs
drwx------ 2 root root 4096 1970-01-02 01:43 sds
drwxrwx--- 2 system system 4096 1970-01-02 01:43 secnvm
drwxrws--- 2 drmrpc drmrpc 4096 1970-01-01 02:02 security
drwxrwxr-x 3 system system 4096 1970-01-02 01:43 sensors
drwxrwx--- 2 system system 4096 2018-08-05 08:30 time
drwxrwx--- 2 media media 4096 1970-01-02 01:43 vpp
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1970-01-01 02:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1970-01-01 02:02 wmdrm
Click to expand...
Click to collapse
Hi there, I see you're responding to my comment in the cedric forum. It appears that your are also impacted, with the folders being owned by oem_2903 and oem_2904. However, I need to get the details of the correct owner from a fully working cedric device, to know who to change the owner to. Please keep replies in the thread I posted in the cedric forum. I'll keep monitoring that thread as well.
NZedPred said:
Yes, efs and persist are two completely different things. However, DO NOT ERASE PERSIST EVER!!! It is unique to your device, and without it you will lose functionality. If you have erased efs and it recreates on boot then chances are your persist is fine, and you should back it up.
My advise would be that, as long as your persist is your own, back it up and keep it safe.
Click to expand...
Click to collapse
As I said, my device was borked before anyone knew what was happening. At that time we was using other uploaded efs and persist files. My persist is not my own, probably well and truly screwed lol.
NZedPred said:
Hey, it may be that that special build is required. Perhaps my comment about 'recent versions of TWRP' wasn't quite correct, and only 'unofficial' versions have the persist option. The partition is not backed up anywhere else if it is selected (or selectable).
Click to expand...
Click to collapse
Also I should also clarify that I recommend TWRP only because you get a nice gui, and for novices entering dd commands with root privileges carries a high level of risk.
NZedPred said:
Also I should also clarify that I recommend TWRP only because you get a nice gui, and for novices entering dd commands with root privileges carries a high level of risk.
Click to expand...
Click to collapse
Ok, understand that. One more question, you changed the dd commands from the first time you posted them in the old thread.
The old ones were
Code:
dd if=/dev/block/mmcblk0p30 of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/mmcblk0p30
Now they look like this:
Code:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/bootdevice/by-name/persist
Is the change significant so that there's a need to make a new backup?
Sent from my Moto G5 Plus using XDA Labs
Hi bro
Maximum people's are not have persist and efs backup
You have any solutions please tell me
Me also same problem
I tried your commands
It's just rebooting
Nothing happens
And i flashed xda forums persist
Its showing dhob.bin file
But it's not creating imei's
I tried on stock (old 33 ver and 92-10 ver) and pixel experience also
Nothing worked..
Please help me
Sorry for my bad english....
Wolfcity said:
Ok, understand that. One more question, you changed the dd commands from the first time you posted them in the old thread.
The old ones were
Code:
dd if=/dev/block/mmcblk0p30 of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/mmcblk0p30
Now they look like this:
Code:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/bootdevice/by-name/persist
Is the change significant so that there's a need to make a new backup?
Sent from my Moto G5 Plus using XDA Labs
Click to expand...
Click to collapse
Hmm, I don't think so. If I understand it correctly - the first set of commands point to the partition directly (i.e. the first line is find partition mmcblk0p30, dd copy to an image, name image 'persist.img'. 2nd line is the reverse). The second set should be the same - just this time you're asking the device to look up a partition of the name 'persist' from the partition list, then copy and output that as the image.
I imagine the second set of commands are more useful generally, e.g. if you don't have a partition list handy or if you want to use it on another device with a persist partition. They should in practice give you the same partition on the G5 Plus. Still, as NZedPred has noted above, requesting the partition by name may be safer for those users unused to dd, since fat fingering the partition name may have some protection. If you fat finger the first set of commands (e.g. you overwrite partition 39 instead of 30), that's not good...
One thing I was thinking about was is it possible to make a permissions fix script for stock ROMs or perhaps patch the custom ROMs so that they don't change the permissions? Or is that permissions change a result of updating to Oreo (as in that you need that change for an Oreo ROM to work)?
Wolfcity said:
Ok, understand that. One more question, you changed the dd commands from the first time you posted them in the old thread.
The old ones were
Code:
dd if=/dev/block/mmcblk0p30 of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/mmcblk0p30
Now they look like this:
Code:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
dd if=/sdcard/persist.img of=/dev/block/bootdevice/by-name/persist
Is the change significant so that there's a need to make a new backup?
Sent from my Moto G5 Plus using XDA Labs
Click to expand...
Click to collapse
Hi - no there's no difference. The new commands differ only in that they are referring to the 'named partition', rather than a partition block number. The named partition is a symbolic link that points to the same place:
Code:
potter_n:/ $ su
potter_n:/ # ls -l /dev/block/bootdevice/by-name/persist
lrwxrwxrwx 1 root root 21 1971-01-25 16:38 /dev/block/bootdevice/by-name/persist -> /dev/block/mmcblk0p30
potter_n:/ #
I find the named partitions easier to understand and more distinct, so no one's going to accidentally backup/restore the wrong partition because they typed in the wrong number.
echo92 said:
One thing I was thinking about was is it possible to make a permissions fix script for stock ROMs or perhaps patch the custom ROMs so that they don't change the permissions? Or is that permissions change a result of updating to Oreo (as in that you need that change for an Oreo ROM to work)?
Click to expand...
Click to collapse
This is something that I'm considering. With the help of @rachitrawat we now know exactly where the Oreo custom roms have been changing the ownership of the rfs folder. However, I don't know if the 'fix' is as simple as changing the IDs to the correct ones, as there could be implications for those who are currently happily running the Oreo custom roms. Also, it would mean that every rom developer would have to make the change.
If TWRP scripts have the ability to change file ownership, then I will look to build a separate TWRP flashable that does it.
bro im using motog5s plus and while im lost my imei im tried lot of methods and also flashed presist from xda pages.. now i think my presist is gone (
but via trying your method my imei is changed from 0 to 000000876e5501 like this on 1st sim 2nd 1 remain 0 flashing a my efs backup showing a efs2 partition dosnt exist error
---------- Post added at 12:59 AM ---------- Previous post was at 12:59 AM ----------
bro im using motog5s plus and while im lost my imei im tried lot of methods and also flashed presist from xda pages.. now i think my presist is gone (
but via trying your method my imei is changed from 0 to 000000876e5501 like this on 1st sim 2nd 1 remain 0 flashing a my efs backup showing a efs2 partition dosnt exist error
---------- Post added at 01:00 AM ---------- Previous post was at 12:59 AM ----------
bro im using motog5s plus and while im lost my imei im tried lot of methods and also flashed presist from xda pages.. now i think my presist is gone (
but via trying your method my imei is changed from 0 to 000000876e5501 like this on 1st sim 2nd 1 remain 0 flashing a my efs backup showing a efs2 partition dosnt exist error
Would this work if I restored my EFS via TWRP? Or should I go back to the stock EFS to run these commands?
Side note: Very grateful for the hard work of all the people involved in this: @rachitrawat, @NZedPred, and the people who reported their experiences!
5P4RT0N said:
bro im using motog5s plus and while im lost my imei im tried lot of methods and also flashed presist from xda pages.. now i think my presist is gone (
but via trying your method my imei is changed from 0 to 000000876e5501 like this on 1st sim 2nd 1 remain 0 flashing a my efs backup showing a efs2 partition dosnt exist error
Click to expand...
Click to collapse
Is your persist your own one? If not, you need it. If you don't have a backup of it, you're out of luck. No idea about the efs2 partition error. Try this in a shell, and post back with the results:
Code:
su
ls -l /dev/block/bootdevice/by-name/modemst*
Jrhotrod said:
Would this work if I restored my EFS via TWRP? Or should I go back to the stock EFS to run these commands?
Side note: Very grateful for the hard work of all the people involved in this: @rachitrawat, @NZedPred, and the people who reported their experiences!
Click to expand...
Click to collapse
Not quite sure what you're getting at by restoring your EFS. The EFS is recreated on boot with a fully working persist.
NZedPred said:
Not quite sure what you're getting at by restoring your EFS. The EFS is recreated on boot with a fully working persist.
Click to expand...
Click to collapse
I mean that I restored the "cached" EFS in order to temporarily restore my IMEI. After flashing stock with the modemst commands, it gives you IMEI 0, so I restore my backed-up EFS to treat it.
So if I have that cached EFS, and with that my IMEI, can I still run this procedure? Because I still do get IMEI 0 after taking OTAs, flashing stock, etc.
I hope I'm making sense :silly:
Jrhotrod said:
I mean that I restored the "cached" EFS in order to temporarily restore my IMEI. After flashing stock with the modemst commands, it gives you IMEI 0, so I restore my backed-up EFS to treat it.
So if I have that cached EFS, and with that my IMEI, can I still run this procedure? Because I still do get IMEI 0 after taking OTAs, flashing stock, etc.
I hope I'm making sense :silly:
Click to expand...
Click to collapse
Ok you probably can run through this procedure as long as your persist is yours. If in doubt, post the info that I ask for in the OP including the output of the commands.