Imaging system.img

[lavahot]

Hi Alok,

I'm trying to create a version of your picuntu that is headless, and I've succeeded in making changes to a live install on a Beelink MK908II to this effect, but when I imaged it with rkflashtool with parameters 0x12000 (offset) and 14820305 (size in 512B blocks)(was told to just overshoot that one, actual size is 14820304), the image is unmountable in ubuntu. The weird thing is that if I flash that image in place of your system image onto a new device (same model), it works just fine (apparently).

dmesg says this: EXT4-fs (loop2): bad geometry: block count 1882368 exceeds size of device (1852540 blocks) Tried to do sudo resize2fs, but it wanted me to do efsck -f first, which failed because of: Error reading block 1867776 (Invalid argument) while reading inode and block bitmaps.

As far as I can tell, the partition table is either unreadable or non-existent. My question to you is how did you build system.img the first time? At this point I'm thinking that it might be easier to build my own system.img than to fix what I've done to yours so I can reduce it to something more manageable than the 7.2 GB that I had to image.

Big thanks for your help!

Lava

[aloksinha2001]

The system.img is a standard image file created out of deb bootstrap...

The sytem.img can be and should be mountable under linux... use -o loop.

If your recovered image from the device is not mountable.. i suspect, the memory map (parameter file) to be the culprit...

step back to basics... use the android parameter config to get the exact params... use them in the kernel to get the right addresses... and then flash the same...

It shud hopefully work...

Alok

This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.

On Thu, Jan 9, 2014 at 12:15 AM, lavahot notifications@github.com wrote:

Hi Alok,

I'm trying to create a version of your picuntu that is headless, and I've succeeded in making changes to a live install on a Beelink MK908II to this effect, but when I imaged it with rkflashtool with parameters 0x12000 (offset) and 14820305 (size in 512B blocks)(was told to just overshoot that one, actual size is 14820304), the image is unmountable in ubuntu. The weird thing is that if I flash that image in place of your system image onto a new device (same model), it works just fine (apparently).

dmesg says this: EXT4-fs (loop2): bad geometry: block count 1882368 exceeds size of device (1852540 blocks) Tried to do sudo resize2fs, but it wanted me to do efsck -f first, which failed because of: Error reading block 1867776 (Invalid argument) while reading inode and block bitmaps.

As far as I can tell, the partition table is either unreadable or non-existent. My question to you is how did you build system.img the first time? At this point I'm thinking that it might be easier to build my own system.img than to fix what I've done to yours so I can reduce it to something more manageable than the 7.2 GB that I had to image.

Big thanks for your help!

Lava

— Reply to this email directly or view it on GitHubhttps://github.com/aloksinha2001/Picuntu/issues/1 .

Alok Sinha Chief Executive Officer, Globus Eight Suite 600, 2201 Cooperative Way, Herndon, VA, USA 20171 Level 12, Tower 8C, DLF Phase II, Gurgaon, India 122002 Phone: +1-757-447-4642 | +91-9810159444 asinha@g8.net | www.g8.net

[lavahot]

Thanks for responding so quickly!

I figured it out. The parameter file actually indicates the system.img to be of indefinite size, "-", so I had to guess how big it was from df. Turns out that /dev/mtdblock2 is not the entire image as I was under by <3000 4K blocks (found this out from dmesg, but didn't know what it meant until I imaged again with a different size). When I imaged with a bigger size at or above the superblock reported size, it seems to have corrected this problem. How do I get the exact parameters from the kernel?

The problem I'm running into now is reducing the size of the image into something more portable. I tried to reduce the partition with gparted, but since system.img doesn't have a partition table, gparted doesn't work with it. Can you make any recommendations to reduce the size of the image to remove (most) empty space?

I noticed in /etc/rc.local, you resize2fs on first boot (cool trick), and I intend to leave this mechanism in place in my version and maybe even expand it to do some other things like run a first boot script.

Thanks again for all of your help, it is very much appreciated!

[aloksinha2001]

The system.img is already a compressed - zero empty byte image... you would NOT be able to reduce it further. The way to reduce it would be .. to mount it, remove the files in it... and then recompress it... ofcourse, u need to play with the file mount dates...

Yes, the first_boot is very useful trick, when you need to do things on first boot... this is not the most preferred way, (because - by the time /etc/rc.local is mounted) a lot of things have already happened... but it works ... the ideal would be to have a /rc/init.d/00-xxx script... but then that is for another day :)

Alok

This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.

On Thu, Jan 9, 2014 at 11:38 AM, lavahot notifications@github.com wrote:

Thanks for responding so quickly!

I figured it out. The parameter file actually indicates the system.img to be of indefinite size, "-", so I had to guess how big it was from df. Turns out that /dev/mtdblock2 is not the entire image as I was under by <3000 4K blocks (found this out from dmesg, but didn't know what it meant until I imaged again with a different size). When I imaged with a bigger size at or above the superblock reported size, it seems to have corrected this problem. How do I get the exact parameters from the kernel?

The problem I'm running into now is reducing the size of the image into something more portable. I tried to reduce the partition with gparted, but since system.img doesn't have a partition table, gparted doesn't work with it. Can you make any recommendations to reduce the size of the image to remove (most) empty space?

I noticed in /etc/rc.local, you resize2fs on first boot (cool trick), and I intend to leave this mechanism in place in my version and maybe even expand it to do some other things like run a first boot script.

Thanks again for all of your help, it is very much appreciated!

— Reply to this email directly or view it on GitHubhttps://github.com/aloksinha2001/Picuntu/issues/1#issuecomment-31905278 .

Alok Sinha Chief Executive Officer, Globus Eight Suite 600, 2201 Cooperative Way, Herndon, VA, USA 20171 Level 12, Tower 8C, DLF Phase II, Gurgaon, India 122002 Phone: +1-757-447-4642 | +91-9810159444 asinha@g8.net | www.g8.net

[lavahot]

I know that your system.img is devoid of empty space at about >1GB in size, but the image I had to read from the NAND after the resize in /etc/rc.local is >7GB and thanks to looking at a hex editor, I know is mostly empty space. How can I make it sparse? resize2fs -MP? Then dd to a new image the size of the output of -P?

Thanks for the first_boot tip. I really need to study the init/rc stuff in linux anyway.

Lava

[lavahot]

Alok,

Hey, what do you know, I solved my own question. I actually had to do efsck -f /dev/loop1 , because resize2fs forced me to, then resize2fs -Mp /dev/loop1 to change the logical size of the filesystem to the minimum (237950 4k blocks), then truncate --size=$[(237950+1)*4096] system.img. Thanks again for all your help!

Lava