The attachment "0001-Fix-extraction-of-stage2-image.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu- reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to abootimg in Ubuntu. https://bugs.launchpad.net/bugs/1606633 Title: Abootimg sometimes extracts corrupted stage2 images Status in abootimg package in Ubuntu: New Bug description: On Ubuntu 16.04, abootimg-0.6-1 sometimes produces corrupted stage2 images during extraction of Android bootimage. I cannot share real boot images that exhibit this problem, but here's artificial way to reproduce it: $ yes "KERNEL " | dd of=kern.src bs=1 count=5000 5000+0 records in 5000+0 records out 5000 bytes (5.0 kB) copied, 0.00548857 s, 911 kB/s $ yes "RAMDISK" | dd of=ramd.src bs=1 count=5000 5000+0 records in 5000+0 records out 5000 bytes (5.0 kB) copied, 0.0186445 s, 268 kB/s $ yes "STAGE 2" | dd of=s2.src bs=1 count=5000 5000+0 records in 5000+0 records out 5000 bytes (5.0 kB) copied, 0.0157602 s, 317 kB/s $ hexdump -C kern.src 00000000 4b 45 52 4e 45 4c 20 0a 4b 45 52 4e 45 4c 20 0a |KERNEL .KERNEL .| * 00001388 $ hexdump -C ramd.src 00000000 52 41 4d 44 49 53 4b 0a 52 41 4d 44 49 53 4b 0a |RAMDISK.RAMDISK.| * 00001388 $ hexdump -C s2.src 00000000 53 54 41 47 45 20 32 0a 53 54 41 47 45 20 32 0a |STAGE 2.STAGE 2.| * 00001388 $ abootimg --create boot.img -k kern.src -r ramd.src -s s2.src reading kernel from kern.src reading ramdisk from ramd.src reading second stage from s2.src Writing Boot Image boot.img $ abootimg -x boot.img writing boot image config in bootimg.cfg extracting kernel in zImage extracting ramdisk in initrd.img extracting second stage image in stage2.img $ hexdump -C stage2.img 00000000 52 41 4d 44 49 53 4b 0a 52 41 4d 44 49 53 4b 0a |RAMDISK.RAMDISK.| * 00000380 52 41 4d 44 49 53 4b 0a 00 00 00 00 00 00 00 00 |RAMDISK.........| 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 53 54 41 47 45 20 32 0a 53 54 41 47 45 20 32 0a |STAGE 2.STAGE 2.| * 00001388 $ I've looked into sources and found that offset may be calculated incorrectly due to wrong rounding (as you may see STAGE 2 text begins at offset 0x800 - size of one block). You may find fix that I use in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/abootimg/+bug/1606633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
