Database Info

[Think-Tank] Bad Blocks causing missing apps & broken functions

Seems that a refurbished G1 I received has 3 blocks stuck and marked in eccUnfixed for some time, pulled the info from command:
Code:
cat /proc/yaffs
Issues:
I'm thinking as our G1s are getting older and with ROM flashing abuse we are killing NAND blocks on them fast. Researching at various sites linux-mtd & Yaffs.net, the garbage collector of Yaffs should be marking and removing these if Yaffs was controlling the ECC mode. However since Yaffs G1 android setting relies on NANDecc for marking bad blocks I'm not so sure which is cleaning up and not retiring these blocks, maybe NAND and YAFFS are in disagreements or one has ability to retire these blocks and end this problem. It seems though that while flashing ROMs data is being written on to these areas and after a remount it is evident that something may be wrong.
Experiences:
An app could go missing or a file or folder name with invalid characters may happen or a phones feature may suddenly stop workin such as scanning for wireless networks timing out.
The issue is reproducable on freshly erased partitions via fasboot erase system -w.
If a dev would like to co-ordinate with me I will grant them remote access to a system with said phone connected via usb with adb port redirection/remote adb or desktop access with adb and fastboot and vnc client with vnc server on phone .
Workaround:
Working with xda member Licknuts we tested numerous times with a few ROMs 1.6 and 2.1 and came up with this for a quick work around that basically involves erasing /system via fastboot then in recovery lock /system from being formatted and unmounted after ROM Flashing you then tarball /system partition to /sdcard do a reboot into fastboot and erase system again reboot into recovery and untarball back to /system.
Prerequisite:
A phone that suffers missing apps in /system or odd phone behavior features after fresh ROM flash.
ADB with Fastboot, USB Cable connected to your Phone.
Adapt the procedure bellow for issues stemming from the /data partition.
<Go for it>
Going to have to clear out system as it probably has corruption.
Code:
fasboot erase system
Note:::
Hboot spl dictates reboot & some engineer spls have no menu option and engineer spls do not reboot to recovery with an empty partitions when USB cable is connected so disconnect it and reboot then reconnect when in recovery console or just fastboot flash system system.img using HTC 1.6 system.img extracted from their zip.
FYI:::
Haykura sapphire spls (aka: danger spl / death spl) are able to boot to recovery with only radio/hboot/recovery partitions intact as long as it is instructed to do so other wise you get G1 screen with red[fastboot] with USB cable attached (might be the missing safety mode for bricked G1s but not certain).
Anyhow just Reboot to recovery console from menu option or [send][menu][hang] quickly hold [home]
Using adb shell we can lock system partition from being formatted and unmounted by ROM Flash scripts instructions in scripts.
Code:
adb shell
mount -a
cd /system
flash ROM and any updates from Recovery console on phone as normal...... and then we tarball the /system partition before it remounts on reboot and corruption happens
While still in adb shell and hanging out in /system, issue these commands to mount the sdcard and create a tarball of /system.
Code:
mount /sdcard
tar -cvf /sdcard/system.tar /system
sync
reboot bootloader
in fastboot we erase system again because most likely data will corrupt because the Flashing procedure may have written to bad blocks and when mounted or remounted it will corrupt, this is why we tarballed /system before it happens.
Code:
fastboot erase system
then reboot back to recovery console
using adb shell we un-tarball system.tar back to /system mountpoint with YAFFS that supposedly knows about these bad blocks so writing filles out these should be checked and avoided.
Issue these commands:
Code:
mount /sdcard
mount /system
tar -xvf /sdcard/system.tar -C /
sync
reboot
reboot as normally would and with some luck files wrote out avoiding those marked bad blocks.
Resolutions and notes:
flash_image and ROM flashing scripts may be flashing directly to device level which does not have YAFFS bad block information and once mounted with a file system, corruption happens from file system having bad block information.
Using sapphire spls (danger spl) we have access to fasboot oem task 28 & fastboot oem task 29 will low level format, repair, report and mark blocks bad but doesn't seem to resolve issues maybe YAFFS doesn't sync or care about the blocks marked in NAND mtd.
Possibly we need a compiled kernel and complete compiled tool set to fully work on Nand device mtd and format tools for Yaffs and scripts to automate some tasks. Seems Nandroid and /system/xbin, /sbin, /system/bin and recovery console tool-sets are limited as well.
*I think and type fast so note that typos may exists hopefully not in coding but elsewhere and if you exist solely to point out grammar and spelling of others on internet forums or broken English of members from other countries, then respect my preemptive "go **** yourself".
If my help aided in getting your phone in working order then give a family member or friend a call or donate some $ to the devs that keep our phones fun to use.

Have you got any more in-depth info on this?
The way I see it, you erase with fastboot... What does this accomplish that doesnt happen if one from the recovery console or adb, dd /dev/zero into the MTD device?
Or, better yet, wouldn't tarring the system partition after its written just copy the bad files that existed on the bad erase block(s)?
Or am i seriously not understanding what your instructions are doing.. To me:
Erase in some way once. What this does, i'm unsure.
Flash
Mount /system and tar to sdcard
Erase again (again what this does to assist the process is uncertain to me)
Boot to recovery
Mount everything
Untar from sdcard.
Tell me if I understand this wrong?

as some blocks are reserved to replace bad blocks , most of the time you won't see a problem
However, once these are used up you will effectively see partition 'shrinkage'
we can limit this 'shrinkage by using lbcoder's custom MTD via the kernel command line
I have a relatively simple way of implementing this
http://forum.xda-developers.com/showthread.php?p=7061471#post7061471

Thanks Phonekenstein for such a great input. I never knew this thread was exist until now but I found this and read the title, damn this is exactly what my case is!
Follow your instruction and re-install the rom, every single headached weird behaviors are disappear and the system runs like butter. It seems my phone is finally fixed!
I think this thread should get more attention.

(bump)
This is a great find! I will be trying this on my HD2 as I have some bad blocks also causing Android builds to go wack.

[Q][Kernel][i9023] Help : flashing kernel killed my phone

Hello everybody,
Before telling you about my issue, i should mention that i am a complete newbie regarding flashing kernels. This was my first try, and it didn't work out too well.
I needed to test the USB OTG/Host Functionality for a project at work, and i read that it was possible to enable it on the Nexus S by flashing a custom kernel (kernel_usbhost_build5_icsnexuss from sztupy). It's probably worth mentioning that prior to this i updated the phone to Android 4.0.3.
So i started this morning by rooting it, unlocking the bootloader and installing CWM.
At that point i realized that the recovery mode wasn't accessible : the graphics of the droid with an open belly appears for half a second, and then it gives me the black screen treatment for about a minute before rebooting.
However since there are other ways to flash kernels, i figured i could do without recovery so i didn't look more into it.
I then flashed the kernel using fastboot with this command :
Code:
C:\Program Files\Android\android-sdk\tools>fastboot flash:raw boot H:\data\Downloads\kernel_usbhost_build5_icsnexuss\kernel\zImage
creating boot image...
creating boot image - 3446784 bytes
sending 'boot' (3366 KB)...
OKAY [ 0.422s]
writing 'boot'...
OKAY [ 0.500s]
finished. total time: 0.922s
From the trace i figured that all went well, but when i reboot it stays blocked on the splash screen with the Google logo. Since then i tried flashing several other kernels, without any success. Also tried to flash an update.zip (both ICS and GB) over fastboot but i get this error :
Code:
C:\Program Files\Android\android-sdk\tools>fastboot update H:\data\Downloads\upd
ate.zip
archive does not contain 'android-info.txt'
archive does not contain 'android-product.txt'
error: update package has no android-info.txt or android-product.txt
So to sum it up i now only have access to the bootloader, without recovery mode.
Before you all jump on me, i know what i did is bad habits (i should have tested the kernel before flashing it), i did it in a hurry without checking i had all sufficient knowledge, and to be honest i would probably have been more careful if was doing it on my personal device.
Truth is now i'm really desperate because i turned my company issued phone into a brick and don't have the slightest idea what to do about it...
Is there any guru out there who knows how i could get out of this ?
Thanks a lot !

Download clockworkmod recovery and use fastboot to flash it.
Fastboot flash recovery yourfilename.img
Enter recovery and mounts and storage and mount USB storage
Transfer the kernel you want to your SD card. The one you flashes isn't a kernel I'm almost sure.
Try a different one.
Then transfer a rom to your SD card.
Factory reset/full wipe, then go to mounts and storage and format everything except your sdcard.
DO NOT FORMAT YOUR SD CARD!!!
Once that is done go to install zip from sdcard and flash the rom and then the kernel and reboot. Should be fine then. Keep me posted.

..

Election Day said:
The image you need would be this ClockworkMod img. Save it somewhere, cd to the sdk/platform-tools/ directory and then do:
Code:
fastboot flash recovery /path/to/saved/file/recovery-clockwork-5.0.2.0-crespo.img
Just drag and drop the file in your terminal, after typing the space after "recovery".
Furthermore, what nodstuff said.
Click to expand...
Click to collapse
Ha ha oops! Forgot that part!
I usually just cd to the one where I have recovery saved!

..

Thanks a lot for answering so quickly !
I'll give it a try on Monday, let you know how it goes.

Election Day said:
Yes, you can also do that, of course. In that case you'd have to provide the full path for fastboot. Or maybe you don't have to on Windows? I don't really use that operating system to be honest.
In that case it would be something like:
Code:
C:\Program Files\Android\android-sdk\tools\fastboot flash recovery recovery-clockwork-5.0.2.0-crespo.img
Looking at OP's quotes that is probably the most logical way in this case, you're right.
Click to expand...
Click to collapse
No I just cd to downloads (where recovery file would be) in terminal, type: fastboot flash recovery xxxxxx img
And that's it.
I set the path to fast boot and adb in environmental variables in device manager.
Maybe that's why.

..

Just tried out your tips, worked like a charm !
However I had to wipe everything twice before it would let me update to 4.0.3, I would get this weird error :
file_getprop: failed to stat "/system/build.prop": No such file or directory
Anyway now I'm back on ICS and, following your advice, i found another kernel to flash : Matr1x. No problem with this one, now I can test USB OTG.
Thanks again, you guys rule !

NVIDIA Shield Unlock Bootloader FAILED <Remote: <>

Good afternoon-
I recently picked up a NVIDIA Shield from a friend of mine because it would not turn back on for him. It is currently stuck at the NVIDIA Boot screen. I can access the Bootloader and I can access stock recovery. However, when I attempted to use Fastboot to unlocked the bootloader I receive the below...
(bootloader) Showing Options on Display.
(bootloader) Use device keys for selection.
(bootloader) erasing userdata...
(bootloader) erasing userdata done
(bootloader) erasing cache...
(bootloader) erasing cache done
(bootloader) unlocking...
FAILED (remote: ()
finished. total time: 3.872s
I am using "Fastboot OEM Unlock" and it does prompt me on the Shield to unlock, but once I select unlock it bounces right back to the bootloader and fails. I tried wiping data and factory reset via stock recovery, but when I do I receive an E: Failed to Mount /Cache (Invalid Argument). It will not let me read/write any of my user data files at all. It seems as if they are corrupt, but I am not quite sure.
I am looking for a way to get this thing back up and running. I am perfectly fine with losing all data on it. Is there a stock kernal that I can flash with a locked bootloader? I fear the issue is with the bootloader or corrupted EMMC. I am open to any and all suggestions!

Make sure that your USB cable is plugged into a USB 2.0 port directly connected to your motherboard as sometimes USB 3.0 ports can cause problems and front panel USB connections can be unreliable.
from: https://forum.xda-developers.com/showthread.php?t=2399737

In case it is interesting, (if someone get managed) it should be possible to boot into twrp recovery with locked bootloader.
- Linux only - (I have not tested and can not confirm if this works. maybe i have a thinking blunder)
first we need a u-boot from another unlocked (similar) device (not sure about size?)
Code:
dd if=/dev/mmcblk0boot0 of=u-boot-dtb-tegra.bin bs=1048576 count=1
second we can boot this u-boot without flashing
Code:
tegra-uboot-flasher exec u-boot-dtb-tegra.bin
third we can boot twrp from fastboot
Code:
fastboot boot twrp-3.3.1-0-shieldtablet.img
Pre-requisites
you need to create your own cbootimage-config
https://github.com/NVIDIA/cbootimage-configs/tree/master/tegra124/nvidia
Adding Board Support
====================
If that doesn't work out, you may create the required configuration files
using the following process:
1)
Extract the BCT from the existing device. Various methods exist to do this:
1a)
Recent versions of tegrarcm now have the capability to read the BCT from the
device without requiring any HW-specific binaries, nor code already installed
on the device:
tegrarcm --bct board.bct readbct
1b)
If you have access to Linux running on the device already, then you can use
dump the memory device directly:
For devices which boot from eMMC:
dd if=/dev/mmcblk0boot0 of=bct.bin bs=65536 count=1
For devices which boot from SPI:
dd if=/dev/mtd0ro of=bct.bin bs=65536 count=1
1c)
If you have a working nvflash for your device, then this can also extract the
BCT:
nvflash --bl fastboot.bin --getbct --bct board.bct
If that doesn't work, you could try reading the content of the BCT partition
or the start of the raw device, then extracting the BCT:
nvflash --bl fastboot.bin --read 2 board.bct
or:
nvflash --bl fastboot.bin --rawdeviceread 0 128 board.bct
Note that some of the above commands extract many more bytes of data that is
strictly required. However, this avoids updating these instructions for each
new chip; Tegra20's BCT is just under 4KiB, Tegra30's around 6KiB, etc.
2)
Convert the BCT to a cbootimage configuration file:
bct_dump board.bct > board.bct.cfg
This will de-compile the extracted BCT binary into a text configuration file
suitable for later use by cbootimage.
To follow the same structure as the rest of the configuration files in this
project, it's then best to split up board.bct.cfg into separate board.bct.cfg
(DevType, DeviceParam, and SDRAM lines), and board.img.cfg (all other header
parameters). Use the existing configuration files as a guide.
Once you have performed these steps, you will have configuration files
suitable for your personal use. We don't accept contributions to this project
that were derived in this fashion. We encourage you to contact the vendor
and request them to submit their own configuration files.
Click to expand...
Click to collapse
tegra-uboot-flasher
https://github.com/NVIDIA/tegra-uboot-flasher-scripts
Introduction
============
This project provides scripts and data that provide a simple way of using
tegrarcm and U-Boot to write U-Boot (or an alternative image) to the boot
flash of a Tegra device.
The flash images handled by this tool include just the bootloader and any
other data necessary for the bootloader to execute (i.e. the BCT). Creating or
flashing a root filesystem, either on the Tegra device's built-in flash, or on
external storage media, is a separate step unrelated to this tool.
Pre-requisites
==============
This document assumes that the instructions in README-developer.txt have
already been followed. Those instructions generate various files that the
flashing process uses. These include host-based utilities such as tegrarcm,
U-Boot binaries that run on the Tegra target device, and the flash images to
write to the Tegra device.
If you are using a distribution package of this tool, the development steps
have likely already been followed, and you need only follow the instructions
in this file.
If you are working with the source code to this tool, you almost certainly
need to follow the instructions in README-developer.txt first.
Board Configurations
====================
Every Tegra board design has a name. Examples are Harmony or Cardhu.
Each board may exist in a number of different configurations; perhaps the
RAM size or speed varies, or a different type of boot flash is supported.
Each of these configurations is also given a name. tegra-uboot-flasher's
user-interface uses these configuration names exclusively. Examples are
harmony, cardhu-a02-1gb, cardhu-a04-1gb.
You may find a list of valid values for configname by executing:
tegra-uboot-flasher list-configs
Simple Usage - Flashing
=======================
To flash a board, connect a USB cable from your host PC to the Tegra device,
place that board into USB recovery mode, and execute the following as root
on the host machine:
tegra-uboot-flasher flash CONFIG
This will download code and data to the Tegra device and execute a flashing
routine. Once this is complete, the system will reboot into the freshly
flashed boot image, and the system will proceed to boot normally. Depending
on the board and U-Boot support, the flashing process may be observed via the
debug serial port, or on a built-in LCD panel.
Simple Usage - Testing U-Boot
=============================
If you simply want to download an unmodified U-Boot to the Tegra device and
execute it, execute the following as root on the host machine:
tegra-uboot-flasher exec CONFIG
This can be useful for quickly testing changes to U-Boot without writing it
to flash every time. This mode of operation is a very simple wrapper around
tegrarcm, which eliminates the need to remember which BCT to use for each
board configuration.
Advanced Options
================
A number of command-line options exist to control tegra-uboot-flasher's
behaviour. For example, you may specify an alternate image to be written
to boot flash, load configuration data from an alternate location, save
the temporary files created during execution for later analysis, etc.
Execute tegra-uboot-flasher with the --help option to see a description
of these options.
Click to expand...
Click to collapse

[HOW-TO] Recover Bricked U11+

Greetings all.
Several weeks ago, I made this post seeking help with a self-created problem. I am happy to announce that the problem has been resolved with the immense help of sephstyler. He is literally my phone's messiah.
The afore-mentioned XDA member has a device identical to mine. I borrowed his and mirrored most of the data on his device by copying several partitions off his phone on to mine. I followed this guide about changing CID/MID.
I got a hold of a notepad document (you'll find it here) that lists partition information of the U11+. I wasn't sure which of my partitions were corrupt but I was certain the one containing the OS and IMEI information were messed up. My IMEI was blank. The OS version reported in fastboot was 9.99999 or something like that.
So I set out to copy these partitions and their corresponding img files in no particular order - boot, hosd, radio, modemst1, modemst2, cache, system, vendor, persist, and sdf1 (which carries CID info).
Please note that this method fixes the issue where your device is stuck on the bootloader screen with the message, "this phone has been flashed with unauthorised software and is locked....." And you will need a second device that is identical to yours (and functional too) for this process to work. I don't know if they both have to come from the same region (i.e have the same CID and MID). I guess there is no harm in trying. You couldn't possibly do more harm to your device by doing this. Or maybe you could. Either way, I will not be held responsible for any undesirable outcomes.
Steps taken:
- I installed HTC drivers on my computer, running Windows 10 64-bit. And 15-second ADB Installer. Get them both from here and here. I uninstalled HTC Sync Manager after the installation was done as I only needed the drivers.
- I flashed TWRP on the borrowed device so I could have access to adb from recovery.
- I then opened up a command prompt window on my computer, typed adb devices just to be sure that drivers were installed correctly.
The next few steps can be achieved right from within TWRP using the Terminal function. But I chose to use my computer as it'd be much quicker and I am less likely to make typos on a full-sized keyboard.
In a command prompt window, type adb shell. Hit enter.
To copy the system image, type dd if=/dev/block/sda5 of=/sdcard/system.img
For cache, type dd if=/dev/block/sdd21 of=/sdcard/cache.img
For boot, type dd if=/dev/block/sda3 of=/sdcard/boot.img
For radio, type dd if=/dev/block/sdd13 of=/sdcard/radio.img
For modemst1, type dd if=/dev/block/sde2 of=/sdcard/modemst1.img
For modemst2, type dd if=/dev/block/sde3 of=/sdcard/modemst2.img
For persist, type dd if=/dev/block/sde5 of=/sdcard/persist.img
For vendor, type dd if=/dev/block/sda6 of=/sdcard/vendor.img
For sdf1 (board_info), type dd if=/dev/block/sdf1 of=/sdcard/sdf1.img
For hosd, type dd if=/dev/block/sdd12 of=/sdcard/hosd.img
These img files would be saved to your internal storage. I then copied all files to the root folder of my faulty device's storage using Windows Explorer. System.img however refused to transfer. I got creative and used a microSD to make the transfer possible.
Now that these files were sitting comfortably on my phone, I booted to TWRP, connected it to my PC, then entered the following commands in Command Prompt via adb shell.
To copy these images to the appropriate partitions on your phone:
For board_info, type dd if=/sdcard/sdf1.img of=/dev/block/sdf1
For system, type dd if=/sdcard/system.img of=/dev/block/sda5
For cache, type dd if=/sdcard/cache.img of=/dev/block/sdd21
For boot, type dd if=/sdcard/boot.img of=/dev/block/sda3
For radio, type dd if=/sdcard/radio.img of=/dev/block/sdd13
For modemst1, type dd if=/sdcard/modemst1.img of=/dev/block/sde2
For modemst2, type dd if=/sdcard/modemst2.img of=/dev/block/sde3
For persist, type dd if=/sdcard/persist.img of=/dev/block/sde5
For vendor, type dd if=/sdcard/vendor.img of=/dev/block/sda6
For hosd, type dd if=/sdcard/hosd.img of=/dev/block/sdd12
Upon completion, press Ctrl+C or type exit to quit adb shell. Then type adb reboot to reboot your device.
If the above commands were entered correctly (and if the adb gods smile upon you), your device should be restored.
Now I know that copying all images fixed the issue. My guess is the system, boot, and radio images were the crucial ones. I am not entirely sure. But I was desperate for a positive result so I copied the ones that I deemed important.
I hope this helps someone. Cheers.
P.S: My apologies for the formatting. I am still fairly new to this. Also, I just realised I could upload these images for anyone who doesn't have access to a second device. I shall update the post with download links after the upload's completed. Sorry about the brain fart.
[EDIT] Images are up. You can find them here. These files are for the Taiwan-based HTC U11+ (CID - HTC_621)

Nice tutorial.

Hi, I'm having a similar problem with my U11+.... followed ur download link but a decryption key is needed. whats the decryption key?

ChuDust said:
Hi, I'm having a similar problem with my U11+.... followed ur download link but a decryption key is needed. whats the decryption key?
Click to expand...
Click to collapse
Here's the key. I had no idea the files were encrypted to begin with. Sorry about that.
-b087zdU9re0k3e3HHah1w
P.S: Since you're downloading the image files from the link provided, you don't have to go through the first half of the process - copying data from a working phone to an external location.
Best of luck.

Hello. I have an identical situation. My original CID is 622. I changed the CID to 001, but after RUU firmware I could not boot into the system. Now after flash RUU, the phone will reboot into the bootloader. Can anyone help me?

Do you have to be rooted or with unlocked bootloader to be able to backup the phone partitions using this method ?
Or does it just work on completely stock from an db connection to PC ?
Thank you.

The bootloader needs to be unlocked at the very least so you can gain access to the required partitions. Root isn't necessary.
Hope this helps.

Hello, I followed your instructions and made backups of my partitions from HTC U11+ dual-sim european version 401.12.
With unlocked bootloader and rooted with magisk by patched boot image.
Ran adb shell and su while phone was running normally in Android OS and connected to PC.
I'm curious about the sizes of the images created because they don't match with the sizes from partitions.txt.
For example "4210688 sda5 - system" is actually 4,311,744,512 bytes,
"65536 sda3 - boot" is actually 67,108,864 bytes in created image, but the actual boot.img from the OTA file is 38,163,762 bytes.
If these sizes are different can I actually trust the created images ? and use them in need.
Can these created images be flashed by fastboot, for example for system.img: "fastboot flash -S 1G system system.img" ?
Thanks.

andreipaval said:
I'm curious about the sizes of the images created because they don't match with the sizes from partitions.txt.
For example "4210688 sda5 - system" is actually 4,311,744,512 bytes,
"65536 sda3 - boot" is actually 67,108,864 bytes in created image, but the actual boot.img from the OTA file is 38,163,762 bytes.
Thanks.
Click to expand...
Click to collapse
If you divide the 4,311,744,512 bytes by the 1024, you get what you need - 4210688 - this is in Kb.
And so same for boot - 67,108,864 bytes / 1024 = 65536 Kb.

andreipaval said:
Hello, I followed your instructions and made backups of my partitions from HTC U11+ dual-sim european version 401.12.
With unlocked bootloader and rooted with magisk by patched boot image.
Ran adb shell and su while phone was running normally in Android OS and connected to PC.
I'm curious about the sizes of the images created because they don't match with the sizes from partitions.txt.
For example "4210688 sda5 - system" is actually 4,311,744,512 bytes,
"65536 sda3 - boot" is actually 67,108,864 bytes in created image, but the actual boot.img from the OTA file is 38,163,762 bytes.
If these sizes are different can I actually trust the created images ? and use them in need.
Can these created images be flashed by fastboot, for example for system.img: "fastboot flash -S 1G system system.img" ?
Thanks.
Click to expand...
Click to collapse
Hi. I hope your first question was answered. Regarding your second concern, I'm afraid I don't have an answer to that. At the time, flashing any image files onto my device didn't fix the issue even though each flash completed successfully. Copying them manually sure did.
Hope this helps.

Do you have the twrp backup of the stock rom?
andreipaval said:
Hello, I followed your instructions and made backups of my partitions from HTC U11+ dual-sim european version 401.12.
With unlocked bootloader and rooted with magisk by patched boot image.
Ran adb shell and su while phone was running normally in Android OS and connected to PC.
I'm curious about the sizes of the images created because they don't match with the sizes from partitions.txt.
For example "4210688 sda5 - system" is actually 4,311,744,512 bytes,
"65536 sda3 - boot" is actually 67,108,864 bytes in created image, but the actual boot.img from the OTA file is 38,163,762 bytes.
If these sizes are different can I actually trust the created images ? and use them in need.
Can these created images be flashed by fastboot, for example for system.img: "fastboot flash -S 1G system system.img" ?
Thanks.
Click to expand...
Click to collapse
Hello,
do you have the twrp backup of stock rom?

I did not make backups with twrp.

a7y18lte: Porting on postmarketOS

Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources

Thanks alot for making this contribution

M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
After a week or 2 i can get back home and test it , so keep making these and I'll test them and tell you about my experience

Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.

Arm1nas said:
Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.
Click to expand...
Click to collapse
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out

animegamer4422 said:
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out
Click to expand...
Click to collapse
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.

Arm1nas said:
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.
Click to expand...
Click to collapse
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.

animegamer4422 said:
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.
Click to expand...
Click to collapse
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?

Arm1nas said:
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?
Click to expand...
Click to collapse
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)

animegamer4422 said:
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)
Click to expand...
Click to collapse
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR

Arm1nas said:
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR
Click to expand...
Click to collapse
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care

animegamer4422 said:
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care
Click to expand...
Click to collapse
Hello, did you make any progress with it? I will try installing pmOS again and recording everything.

This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png

D
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
Click to expand...
Click to collapse
Sorry for the late reply
Anyways i just got home and have the smartphone I'm my hands
So i can too test it out
Also I think we should try switching to Wayland as X seems to be crashing
By using Wayland if it works we'll know that it's not a Xorg issue but if Wayland too fails we'll know that it's a big in the Kernel and the way it handles hardware
Also could you create a Telegram group for us to chat instantly I think that way we can help each other better and then we'll just create a general guide on fixing things ok XDA
(I cannot post links since I didn't started the thread)[/url]

Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
Sorry for the late reply
Anyways ...post links since I didn't started the thread)

Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration

animegamer4422 said:
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration
Click to expand...
Click to collapse
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?

Arm1nas said:
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?
Click to expand...
Click to collapse
I created a recovery zip using Pmbootstrap and also I set the free space parameter (after running pmbootstrap init) to 2000mb (2gb)
And then i copied that zip file from the temp directory to a Pendrive and connected the pendrive to the phone in recovery mode (PBRP Recovery) and then flashed it
I'll upload the files in a bit
Also I tried using Phosh but it just gets to the Login TTY and then doesn't boots up and i think that's because the device lacks GPU acceleration

Also here's a Telegram group link which I'll delete once you join the group
~REMOVED~

M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
hello, are this thread still active?