linux/poky.git/scripts, branch 2.6_M2

wic/engine: use up all free space when expanding partitions

2018-07-18T09:18:42+00:00

Currently we just divide up the free space by the number of partitions that need to be re-sized. This leads to problems when a user has explicitly specified a subset of partitions (but not all) that need to re-sized along with the sizes. As an example, for an image with 3 partitions, if we use: wic write image.wic /dev/sdb --expand 1:10G This would lead to paritions 2 and 3 each being re-sized to one thirds of the free space instead of half. Change the behavior to use up all the free space. (From OE-Core rev: a88f1b5d88dbc5fb28be24b9787d73b9e0cdf183) Signed-off-by: Anuj Mittal Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

wic/engine: fix errors when expanding partitions

2018-07-18T09:18:42+00:00

The UEFI spec implies that GPT partitions should be assumed to be on a 2048 sector boundary (for a 512 byte sector) and the current logic just divides the free sectors available by the number of partitions that need re-sizing, which may or may not align and the final result might overshoot the limits imposed after alignment. Since we are expanding already aligned partitions, just divide up the free space in multiples of 2048. Also use the exec_cmd wrapper instead of the subprocess call directly. Fixes [YOCTO #12840] (From OE-Core rev: 5eef63f5afdfbab8e30748cb1bf42bf2e6524759) Signed-off-by: Anuj Mittal Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-10T16:33:00+00:00

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512" ... [ 0.000000] Call Trace: [ 0.000000] [] clear_page+0x0/0x128 [ 0.000000] [] get_page_from_freelist+0xab8/0xc00 [ 0.000000] [] __alloc_pages_nodemask+0xdc/0xf68 [ 0.000000] [] __get_free_pages+0x18/0x70 [ 0.000000] [] setup_zero_pages+0x1c/0xb8 [ 0.000000] [] mem_init+0x54/0xa0 [ 0.000000] [] start_kernel+0x204/0x4d8 [ 0.000000] [] kernel_entry+0x0/0x40 [ 0.000000] Code: 02002025 1000f8d9 8e634d7c <34860f80> cc9e0000 cc9e0020 cc9e0040 cc9e0060 cc9e0080 [ 0.000000] [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ... OE uses qemumips to simulate a Malta board by default. As upstream qemu introduced: https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b The Malta board can support up to 2GiB of RAM which should be able to boot a Linux kernel built with CONFIG_HIGHMEM enabled and passing "-m 2048" to QEMU and appending the following kernel parameters: ... mem=256M@0x0 mem=256M@0x90000000 mem=1536M@0x20000000 ... But the following commit in kernel broke above mem=X@Y setting which added the memory as reserved memory area. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ... commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 Author: Marcin Nowakowski Date: Wed Nov 23 14:43:49 2016 +0100 MIPS: fix mem=X@Y commandline processing ... So remove `mem=*' to disable user-defined physical RAM map which let kernel itself caculates memory ranges. Author: Hongxu Jia [ Merge the two fixes for qemumips32 and qemumips64 into one patch, and make it support all mips cases ] (From OE-Core rev: 0220cb34a91658ecc3782ec1a4700dcb5ece37d8) Signed-off-by: He Zhe Signed-off-by: Richard Purdie

send-error-report: Fix test for name > 50 chars

2018-07-04T11:19:13+00:00

A name > 50 chars causes a 500 internal server error and should be warned to the user but the code to do so currently doesn't work. Fix the logic. (From OE-Core rev: 844f8d46f522a994dbff00245c4ffb07452577a8) Signed-off-by: Richard Purdie

send-error-report: Fix dubious error reporting

2018-07-04T11:19:13+00:00

Currently this code prints things like: ERROR: OK which is unhelpful at best. After this change it would print: ERROR: HTTP Error 500 which at least gives us something to work on. (From OE-Core rev: 06079240e4eb0a3e1f528f6c8d6f3ea20754afee) Signed-off-by: Richard Purdie

recipetool: add 'edit' subcommand

2018-07-03T23:02:16+00:00

This edits the recipe and any bbappends for the specified target. (From OE-Core rev: 7aece42c6b4744c54a8eb05ff90bd3bf4fbb14a3) Signed-off-by: Christopher Larson Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

wic: isoimage-isohybrid: debloat image of redundant rootfs

2018-06-29T10:07:45+00:00

There's no reason to have that rootfs.img filesystem in the image: it's not used for anything because both the EFI and legacy boot paths use the /initrd which contains the same contents as the rootfs.img, only compressed. It was probably forgotten in there :) My iso went down from 224 to 94 mb. Tested using UEFI/legacy boots on CD-roms, usb dongle and qemu VM's. (From OE-Core rev: 4c784379524cb12807ef87a02ef1514ed45c1cc3) Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Richard Purdie

wic: isoimage-isohybrid: fix UEFI spec breakage

2018-06-29T10:07:44+00:00

It's really good that OE supports multiple EFI_PROVIDERs and that commit 9a1709278de87 ("wic: isoimage-isohybrid: use grub-efi from deploy dir") makes re-use of the grub-efi built image, but we should still respect the standard otherwise the ISO will not boot, so install grub images as boot[x64|ia32].efi not ${PN}-boot[x64|ia32].efi. (From OE-Core rev: 1608129692d92c239b5fb9244b649a32b9009254) Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Richard Purdie

oe.scriptutils.run_editor: ditch the error-prone argument quoting

2018-06-27T12:55:21+00:00

Rather than trying to construct a string by quoting the files in an error-prone way, parse $EDITOR to pass a list to subprocess rather than a string. (From OE-Core rev: c9fdf3d046606a0becb2e6b566a481c483b9021a) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

runqemu-ifdown: ensure to clean up TAP

2018-06-18T10:07:58+00:00

In runqemu-ifup, ip command is used to add TAP; in runqemu-ifdown, we should do the reversed logic, using ip command to delete TAP, to make sure TAP is cleaned up by ourselves. I can see that in runqemu-ifdown script, 'tunctl -d' and 'iptables' commands are used to deal with TAP, but these two commands cannot make sure that the TAP is cleaned up. runqemu-ifup uses 'ip' to set up TAP, we really need to do the opposite in runqemu-ifdown. (From OE-Core rev: 322e41de7f4fb21315bf75f1038314c31ac4754b) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie