Installer: Allow Chrome OS to use disks with a non-512 block size |
|||||||
Issue descriptionUFS device expose a 4K logical block size. build_image assume image is built on and for device with 512 bytes block. Keep doing that for all device, but be 4k aware: - be sure all partitions are 4k aligned (both size and offset) - when writing/reading GPT to/from a device be aware of the logical sector size. By continuing building images for 512bytes sector, we are still supporting USB device or flash device (even UFS) that may support 512b emulation.
,
Apr 18 2018
build_image shouldn't be making any assumptions about block size. that's what the disk layout json setting is for:
"metadata":{
"block_size": 512,
"fs_block_size": 4096
},
if you know of a place where 512 is hardcoded instead of using that info, we should fix it of course.
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/factory/+/f148d32190b8547731f6df3cc8a2d439040b11d3 commit f148d32190b8547731f6df3cc8a2d439040b11d3 Author: Hung-Te Lin <hungte@chromium.org> Date: Fri Apr 20 14:12:24 2018 pygpt: Support 4K block images. pygpt is a general disk image partition parser, we have to deal with images that use non-512b blocks. Today the major format are either 512 or 4k, so the pygpt will try to read GPT in 4k location and change block size calculation to that if needed. This is tested by scsi_debug kernel module: sudo modprobe scsi_debug dev_size_mb=16384 sector_size=4096 sudo lsblk -o NAME,PHY-SEC,LOG-SEC # Find the entry with NAME,4096,4096 sudo parted /dev/sdX mktable GPT mkpart Start=64,END=128 sudo pygpt.py show /dev/sdX # show information properly. BUG= chromium:832160 TEST=make test Change-Id: I96614580a49fa39c51a8ee294d617a809793a995 Reviewed-on: https://chromium-review.googlesource.com/1011903 Commit-Ready: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Pi-Hsun Shih <pihsun@chromium.org> [modify] https://crrev.com/f148d32190b8547731f6df3cc8a2d439040b11d3/py/tools/image_tool.py [modify] https://crrev.com/f148d32190b8547731f6df3cc8a2d439040b11d3/py/utils/pygpt.py [modify] https://crrev.com/f148d32190b8547731f6df3cc8a2d439040b11d3/py/utils/sys_utils.py
,
Apr 27 2018
Talking with Julius and Sam, changing the cgt add command is not right.
Instead:
- disklayout.json should keep counting size in MB or GB.
- remove block_size in metadata as it can not be enforced on real devices.
- remove blocks in partition layout section. When not specified, size will be one logical block.
- in build_library/cgpt_shell.sh, use $block_size properly or bytes when destroying the GPTs.
- in build_library/cgpt.py,
+ partition['var'] should be in bytes, not sectors.
+ WriteLayoutFunction()
+ calculate the logical block size in the 'if [ -b "${target}" ]; then' section, move that section earlier.
+ use the block size for deleting the cgpt
+ add a script function that divides on the fly the size in bytes to a size in sector. Update $curr accordingly.
,
Apr 28 2018
But we still haev to change 'cgpt create' right? Otherwise how to you create the header in right location?
,
Apr 28 2018
cgpt already had code to detect the block size when it's called on a device node. It only defaults to 512 when used on an image file. I think(?) we never actually need to create image files with 4K blocks (chromeos-install doesn't), but I'm not familiar with the special factory use cases.
,
Apr 28 2018
We do. For many times the factory may need to prepare an image for "preflashing". Then will run a command (now factory/setup/image_tool preflash -o disk) and specify the size of disk to create - and this is done on a desktop machine without accessing the real Chromebook. Newer linux supports mounting loop device with different logical block size, but most machines today do not support that, even gLinux. So i think at least 'create' need to have an parameter to override block size, then all other commands can detect block size by finding GPT from 'create' command.
,
May 1 2018
,
May 1 2018
#8: Looking at image_tool.py, the code is not ready for 4k device yet: InitDiskImage would assert on sector_size != 512 Now, I understand there is a need to build an file image with 4k sector size if we flash the image on the SSD before reflown. To address that, we should not assume a loopback device has a 512bytes sector size either: cat /sys/block/loop0/queue/logical_block_size gives you the size of the loopback device (512 is the default). Before building the reflow image, you need: - a workstation/server a kernel with commit 89e4fdecb51cf5535867026274bc97de9480ade5 (loop: add ioctl for changing logical block size), [4.14] has it. - use the latest losetup (util-linux-2.31 at least) where losetup can set the block size. We need to always write through the loopback device, Mike changes are making it easier. [CL:1034229]
,
May 1 2018
Re#8: Yes it's not very ready for 4k because it needs a way to initialize disk image by calling write_gpt.sh, which calls cgpt - and there's no way to enforce it in 4k mode. But we're very close - image_tool can be changed easily if the gpt tools allowing to specify block size. I have some concern in choosing particular kernel, because it's not available even on glinux (tried the ioctl last time). Will it be pretty hard for partners (who has to run the process to generate preflash images) to find a working environment ?
,
May 2 2018
Looks like image_tool.py is only calling losetup on individual partitions, never on the full disk image anyway... so unless we want to change that, Gwendal's kernel patches shouldn't really matter that much. You're always running cgpt on the file, not on the loopback device. I'm pretty concerned how image_tool.py is hacking around within write_gpt.sh, btw. That is godawful and just begging to break in all sorts of ways. We're controlling both sides of this equation, we shouldn't need to have one script perform ad-hoc surgery on another... instead, we should just change write_gpt.sh to offer enough options to be run in the way the factory installer wants (e.g. via optional command line arguments or environment variables). We'll need to provide a way to pass in the block size anyway, while we're there we should also clean up this other crap.
,
May 2 2018
The factory code usually need to do some surgery to many scripts because unlike other programs and scripts that only need to work on same branch, most of factory setup stuff need to work on images from different branches, especially to support images "from a very old branch" or "a very new branch" - which may across 20 or even 30 milestones. And since those branches can't be changed, we have to hack everything in factory code. But yes, if write_gpt.sh can be modified to be more compatible, we can try to support both and hopefully finally to eliminate the legacy hacks someday.
,
May 2 2018
will it help if we change image_tool preflash to
- create the image with expected size
- call "losetup -b" to specify right block size (note: glinux is 4.9 so all Google developers can't get it to work at the moment :) )
- change the hack of partition creation script into
. PATH_TO/chromeos_common.sh
. PATH_TO/write_gpt.sh
GPT="XX" # override with the real GPT we have
write_base_table path_to/image path_to/pmbr
${GPT} add -i 2 ...
that should prevent dirty hacks and performing all correct procedure, right?
,
May 2 2018
write_gpt.sh is generated with the expectation it's going to be sourced in diff envs. if you want to make it support factory, then go for it. but i agree with Julius here: no script should be running random regexes over write_gpt.sh to try and pick out or modify the generated script. the fact it hasn't broken is probably dumb luck, and if it did break, i wouldn't expect the CL that changed the format to be reverted/penalized at all.
,
May 2 2018
image_tool changes in https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/1039303
,
May 2 2018
Yes, if you're willing to accept that losetup -b will need to be supported for all factories with UFS boards, I think that's an okay solution. I'm still not sure what you're doing with that last line, btw. You're prioritizing KERN-A, but wouldn't vboot be doing that on the first boot anyway? An explanatory comment would be nice there...
,
May 3 2018
Re#18 comment added. vboot won't set -S, only in userland/update_engine will set that, which factory environment may not invoke. losetup -b is fine until we really have projects that need to do 4k - and we'll need to ask them to upgrade their kernel then, hope glinux will be updated to a newer kernel at that time, otherwise I'll need to forward everyone here to see why that does not work :)
,
May 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/factory/+/446eb51e31f1a359443a4f774591ce3dcefb2695 commit 446eb51e31f1a359443a4f774591ce3dcefb2695 Author: Hung-Te Lin <hungte@chromium.org> Date: Fri May 04 10:02:11 2018 pygpt: Support block device files as input. When a disk image file is mounted as loop device, we should be able to get its real block size without using arguments from command line. Also, when trying to find LBA 1, we don't need to try additional values if the image is already a block device file. BUG= chromium:832160 TEST=make test Change-Id: Ib1603ea5ac510bb1bb2a6f6268d69645ad4cc3a0 Reviewed-on: https://chromium-review.googlesource.com/1038947 Commit-Ready: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Pi-Hsun Shih <pihsun@chromium.org> [modify] https://crrev.com/446eb51e31f1a359443a4f774591ce3dcefb2695/py/utils/pygpt.py
,
May 8 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/factory/+/3177463f5d403e8e0ac43a9e7a7487fc40474518 commit 3177463f5d403e8e0ac43a9e7a7487fc40474518 Author: Hung-Te Lin <hungte@chromium.org> Date: Tue May 08 08:22:01 2018 image_tool: Call write_gpt without hacking its contents. To prevent hacking write_gpt, we should mount the disk image as loop device (as block device file) and invoke write_gpt directly on it. BUG= chromium:832160 TEST=make test; image_tool preflash -o disk.bin Change-Id: I71f0ffaf25a65a1ed5402202d26df862d64be60b Reviewed-on: https://chromium-review.googlesource.com/1039303 Commit-Ready: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/3177463f5d403e8e0ac43a9e7a7487fc40474518/py/tools/image_tool.py [modify] https://crrev.com/3177463f5d403e8e0ac43a9e7a7487fc40474518/py/tools/image_tool_unittest.py
,
May 17 2018
Removing access restrictions so external partners who might be interested in this feature can read along. We've discussed no state secrets in here.
,
May 17 2018
,
Jun 9 2018
i think we'll have trouble updating scripts that run on the device to use losetup's -b option as none of our devices are running linux-4.14+. we'll have to backport the commit gwendal mentioned in comment #10.
,
Jun 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/545e551b01af9e5f4b2e76b88affe57b3449e879 commit 545e551b01af9e5f4b2e76b88affe57b3449e879 Author: Sam Hurst <shurst@google.com> Date: Mon Jun 11 17:29:17 2018 chromeos-common-script: Add function that auto detects blocksize Add blocksize function that returns the auto detected sector size of a device or return 512 for a file. BUG= chromium:832160 BRANCH=none TEST=manual ./build_image --board=scarlet factory_install Ran image on device Change-Id: I500366d6b1b86dad3ae52d22e6ad90046df33fe4 Signed-off-by: Sam Hurst <shurst@google.com> Reviewed-on: https://chromium-review.googlesource.com/1091293 Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/545e551b01af9e5f4b2e76b88affe57b3449e879/chromeos-common-script/share/chromeos-common.sh
,
Jun 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/45430bb36e88547833e412310b4bf4eafc3343c0 commit 45430bb36e88547833e412310b4bf4eafc3343c0 Author: Sam Hurst <shurst@google.com> Date: Fri Jun 22 02:56:29 2018 installer: Auto detect blocksize instead of assuming 512. Removed hardcoded 512 blocksize restriction and auto detect blocksize. BUG= chromium:832160 BRANCH=none TEST=manual ./build_image --board=eve Ran image on device CQ-DEPEND=CL:1091293 Change-Id: I3837db780560b4071640c0b4fed267fdb1e679be Reviewed-on: https://chromium-review.googlesource.com/1091299 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> [modify] https://crrev.com/45430bb36e88547833e412310b4bf4eafc3343c0/installer/chromeos-install
,
Jun 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/580439dd3e6c33a46996d3972a9831e3a187f2d8 commit 580439dd3e6c33a46996d3972a9831e3a187f2d8 Author: Gwendal Grignou <gwendal@google.com> Date: Fri Jun 22 19:58:20 2018 Revert "installer: Auto detect blocksize instead of assuming 512." This reverts commit 45430bb36e88547833e412310b4bf4eafc3343c0. Reason for revert: Prevent install get_fixed_dst_drive can not be called until /usr/sbin/write_gpt.sh is included. Original change's description: > installer: Auto detect blocksize instead of assuming 512. > > Removed hardcoded 512 blocksize restriction and auto detect blocksize. > > BUG= chromium:832160 > BRANCH=none > TEST=manual > ./build_image --board=eve > Ran image on device > > CQ-DEPEND=CL:1091293 > > Change-Id: I3837db780560b4071640c0b4fed267fdb1e679be > Reviewed-on: https://chromium-review.googlesource.com/1091299 > Commit-Ready: Sam Hurst <shurst@google.com> > Tested-by: Sam Hurst <shurst@google.com> > Reviewed-by: Julius Werner <jwerner@chromium.org> BUG= chromium:832160 ,b:110699654 Change-Id: I5ceabde72660384d4be6b3ad92f010638ba06d3e Reviewed-on: https://chromium-review.googlesource.com/1112058 Tested-by: Gwendal Grignou <gwendal@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> [modify] https://crrev.com/580439dd3e6c33a46996d3972a9831e3a187f2d8/installer/chromeos-install
,
Jul 1
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/ab84d6811300a43268f8a8bc37c716ea38265eae commit ab84d6811300a43268f8a8bc37c716ea38265eae Author: Sam Hurst <shurst@google.com> Date: Sun Jul 01 04:17:53 2018 installer: Auto detect blocksize instead of assuming 512. Removed hardcoded 512 blocksize restriction and auto detect blocksize. BUG= chromium:832160 BRANCH=none TEST=manual $ ./build_image --board=eve $ dd if=/dev/zero of=file.img bs=1G count=20 $ sudo mknod /dev/sdz b 7 200 $ sudo losetup -P /dev/sdz ./file.img $ cros flash --install usb:///dev/sdz ../build/images/eve/latest/factory_install_shim.bin $ fdisk file.img Welcome to fdisk (util-linux 2.31.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk file.img: 20 GiB, 21474836480 bytes, 41943040 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 0300932E-8664-A448-A228-448A61D56A94 Device Start End Sectors Size Type file.img1 17092608 37748695 20656088 9.9G Microsoft basic data file.img2 20480 53247 32768 16M ChromeOS kernel file.img3 8704000 17092607 8388608 4G ChromeOS root fs file.img4 53248 86015 32768 16M ChromeOS kernel file.img5 315392 8703999 8388608 4G ChromeOS root fs file.img6 16448 16448 1 512B ChromeOS kernel file.img7 16449 16449 1 512B ChromeOS root fs file.img8 86016 118783 32768 16M Microsoft basic data file.img9 16450 16450 1 512B ChromeOS reserved file.img10 16451 16451 1 512B ChromeOS reserved file.img11 64 16447 16384 8M unknown file.img12 249856 315391 65536 32M EFI System Partition table entries are not in disk order. $ cros flash usb:// ../build/images/eve/latest/factory_install_shim.bin Booted image on EVE device CQ-DEPEND=CL:1091293 Change-Id: I17ab0ba8c6889eedb7a60e6f9050ca43f5b1778b Signed-off-by: Sam Hurst <shurst@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1118715 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> [modify] https://crrev.com/ab84d6811300a43268f8a8bc37c716ea38265eae/installer/chromeos-install
,
Jul 11
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7660ab0a7bda6c6bf3227d6c4cb29e21846434c8 commit 7660ab0a7bda6c6bf3227d6c4cb29e21846434c8 Author: Evan Green <evgreen@chromium.org> Date: Wed Jul 11 19:13:27 2018 UPSTREAM: loop: Add LOOP_SET_BLOCK_SIZE in compat ioctl This change adds LOOP_SET_BLOCK_SIZE as one of the supported ioctls in lo_compat_ioctl. It only takes an unsigned long argument, and in practice a 32-bit value works fine. Reviewed-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 9fea4b395260175de4016b42982f45a3e6e03d0b) BUG= chromium:832160 TEST=Run chromeos-install on Cheza, observe losetup -b 4096 succeeding Change-Id: I61604d0d451666b848dfd3c478d3e17c9c5398e0 Reviewed-on: https://chromium-review.googlesource.com/1123646 Commit-Ready: Evan Green <evgreen@chromium.org> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> [modify] https://crrev.com/7660ab0a7bda6c6bf3227d6c4cb29e21846434c8/drivers/block/loop.c
,
Jul 14
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/c8e171779342805225f5ccd793a2e46a0a3f390e commit c8e171779342805225f5ccd793a2e46a0a3f390e Author: Sam Hurst <shurst@google.com> Date: Sat Jul 14 00:29:03 2018 chromeos-common-script: numsectors function returns number of physical sectors. The numsectors function currently returns the number of 512 sectors on a block device even though the sector size of the device might be different. Update numsectors function to return the number of physical sectors on the device. BUG= chromium:832160 TEST=manual ./build_image --board=eve factory_install Ran image on device Change-Id: I2b5a0408d600b96f8745b4a19609b6884b739001 Reviewed-on: https://chromium-review.googlesource.com/1121781 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/c8e171779342805225f5ccd793a2e46a0a3f390e/chromeos-common-script/share/chromeos-common.sh
,
Aug 7
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/910e04cf61a04cfaac39077f8ad41a5ef8f9ee3a commit 910e04cf61a04cfaac39077f8ad41a5ef8f9ee3a Author: Sam Hurst <shurst@google.com> Date: Tue Aug 07 08:51:19 2018 init: Detect sector size of device instead of hard coding to 512. Use blocksize function to detect sector size of device instead of hard coding to 512. BUG= chromium:832160 TEST=Trybot cheza-paladin-tryjob Change-Id: I442edd5b7692e02b0f05e6bc07de1f968a880b7d Reviewed-on: https://chromium-review.googlesource.com/1161552 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> [modify] https://crrev.com/910e04cf61a04cfaac39077f8ad41a5ef8f9ee3a/init/clobber-state
,
Aug 14
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/overlays/overlay-loonix-private/+/909813998550c1fdb8ec543d96c21f3b0b7921b2 commit 909813998550c1fdb8ec543d96c21f3b0b7921b2 Author: Sam Hurst <shurst@google.com> Date: Tue Aug 14 00:48:52 2018
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/crosutils/+/c94b7f98b93ce91e3470ac36e185a4f6b19db4bc commit c94b7f98b93ce91e3470ac36e185a4f6b19db4bc Author: Sam Hurst <shurst@google.com> Date: Tue Aug 14 00:48:53 2018 cgpt: Enable images to be built with auto detected block sizes. Do not assume all images use 512 block sizes. Use new common blocksize function to auto detect block size. Removed 'blocks' label from partition and let them default to a minimum size and removed 'blocks' field from default JSON file. BUG= chromium:832160 BRANCH=none CQ-DEPEND=CL:*657734 TEST=manual ./build_image --board=bob installed on device and booted Output of 'cgpt show /dev/mmcblk0' with my changes: start size part contents 0 1 PMBR (Boot GUID: F3E1F680-95B0-054E-A82B-BD3F017DE459) 1 1 Pri GPT header 2 32 Pri GPT table 8704000 52367312 1 Label: "STATE" Type: Linux data UUID: 3DFED94B-D9AE-B744-BD9F-BF0834938B33 20480 32768 2 Label: "KERN-A" Type: ChromeOS kernel UUID: 0165168D-FA3F-E54F-8707-0AAEEF4D41EF Attr: priority=1 tries=0 successful=1 4509696 4194304 3 Label: "ROOT-A" Type: ChromeOS rootfs UUID: C74D9CF6-152E-6B4E-964B-D4531A1268D1 53248 32768 4 Label: "KERN-B" Type: ChromeOS kernel UUID: A0448FB5-D631-6C41-A5DA-18D8242735BC Attr: priority=0 tries=15 successful=0 315392 4194304 5 Label: "ROOT-B" Type: ChromeOS rootfs UUID: DA8A4C29-EBCC-994C-ACD3-93C4F58A77DF 16448 1 6 Label: "KERN-C" Type: ChromeOS kernel UUID: 36BA8C58-B600-3A4B-8B55-C32EB0164BBC Attr: priority=0 tries=15 successful=0 16449 1 7 Label: "ROOT-C" Type: ChromeOS rootfs UUID: 56CE49CE-1DBD-F146-89E4-25B06C8B62C4 86016 32768 8 Label: "OEM" Type: Linux data UUID: FA935D09-E726-E042-9B10-AA4C03AFB2EE 16450 1 9 Label: "reserved" Type: ChromeOS reserved UUID: 2B982238-8E22-FA49-86C7-38734C5B33DE 16451 1 10 Label: "reserved" Type: ChromeOS reserved UUID: 3B81F9CA-1BBA-164D-BEE9-0BCB1FA26F19 64 16384 11 Label: "RWFW" Type: ChromeOS firmware UUID: E6944883-005E-AE4A-B3A8-B55AFCE94C42 249856 65536 12 Label: "EFI-SYSTEM" Type: EFI System Partition UUID: F3E1F680-95B0-054E-A82B-BD3F017DE459 Attr: legacy_boot=1 61071327 32 Sec GPT table 61071359 1 Sec GPT header Output without changes: start size part contents 0 1 PMBR (Boot GUID: 9DA82550-D83E-6A4C-BA78-054E98F12006) 1 1 Pri GPT header 2 32 Pri GPT table 8704000 52363264 1 Label: "STATE" Type: Linux data UUID: 3F35D00C-8097-D54C-B480-CF48872FA474 20480 32768 2 Label: "KERN-A" Type: ChromeOS kernel UUID: 920D89C0-F1A6-924D-9EE9-A30FD8FEC247 Attr: priority=1 tries=6 successful=1 4509696 4194304 3 Label: "ROOT-A" Type: ChromeOS rootfs UUID: BA717C2B-83EC-0944-B24D-CD3ED88BC9C4 53248 32768 4 Label: "KERN-B" Type: ChromeOS kernel UUID: 3DD0DBA3-0525-0B4E-9327-9FCDBAAB6580 Attr: priority=0 tries=15 successful=0 315392 4194304 5 Label: "ROOT-B" Type: ChromeOS rootfs UUID: F88EBFC4-A004-B348-ACFB-539E3AA93575 16448 1 6 Label: "KERN-C" Type: ChromeOS kernel UUID: 82A9EF93-5DAA-5F45-9FFE-8A3A5C8DAE7F Attr: priority=0 tries=15 successful=0 16449 1 7 Label: "ROOT-C" Type: ChromeOS rootfs UUID: D92CE030-3113-AF4E-AFD8-5E7AA302B35A 86016 32768 8 Label: "OEM" Type: Linux data UUID: 27D59369-75CA-3946-B9A5-B6F091E4908A 16450 1 9 Label: "reserved" Type: ChromeOS reserved UUID: E234C4E2-3F61-7147-B281-06B90047CE75 16451 1 10 Label: "reserved" Type: ChromeOS reserved UUID: F3961050-D6A0-3A43-BC2D-0E1DB18EBF3D 64 16384 11 Label: "RWFW" Type: ChromeOS firmware UUID: BA21F542-9AD9-FD49-9CA9-7E7C472EDA78 249856 65536 12 Label: "EFI-SYSTEM" Type: EFI System Partition UUID: 9DA82550-D83E-6A4C-BA78-054E98F12006 Attr: legacy_boot=1 61071327 32 Sec GPT table 61071359 1 Sec GPT header CQ-DEPEND=CL:1091293, CL:1091299, CL:1121781 Change-Id: I9494a3a5f6d277c61a369e32e47ef1a17f95e8ad Reviewed-on: https://chromium-review.googlesource.com/1091308 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> [modify] https://crrev.com/c94b7f98b93ce91e3470ac36e185a4f6b19db4bc/build_library/legacy_disk_layout.json [modify] https://crrev.com/c94b7f98b93ce91e3470ac36e185a4f6b19db4bc/build_library/cgpt.py [modify] https://crrev.com/c94b7f98b93ce91e3470ac36e185a4f6b19db4bc/build_library/cgpt_shell.sh [modify] https://crrev.com/c94b7f98b93ce91e3470ac36e185a4f6b19db4bc/image_to_vm.sh
,
Aug 16
Hey guys, I think this change broke the adjust_part flag of the build_image script. I think the change to cgpt.py that modified the 'partition' map variable removed the last instance of the 'blocks' key/value pair causing a KeyError later on. Output below:
(cr) ((c94b7f98b93c...)) christian@christian-Z170X-UD5 ~/trunk/src/scripts $ USE="chrome_media" ./build_image --board=soraka --adjust_part='STATE:+16G' --noenable_rootfs_verification test
Chromium OS version information:
CHROME_BASE=
CHROME_BRANCH=70
CHROME_VERSION=
CHROMEOS_BUILD=10968
CHROMEOS_BRANCH=0
CHROMEOS_PATCH=2018_08_15_1046
CHROMEOS_VERSION_STRING=10968.0.2018_08_15_1046
INFO : The following images will be built chromiumos_test_image.bin.
INFO : Clearing shadow utils lockfiles under /build/soraka
* Building file list for packages cleaning...
* Cleaning binary packages...
[ 3.7 M ] /dev-only-extras
Emaint: fix binhost 100% [============================================>]
[ 0.0 B ] Packages Index
===========
[ 3.7 M ] Total space from 1 files were freed in the packages directory
INFO : Verifying that the base image does not contain a blacklisted package.
INFO : Generating list of packages for virtual/target-os.
INFO : No blacklisted packages found.
Traceback (most recent call last):
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 1570, in <module>
sys.exit(main(sys.argv[1:]))
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 1564, in main
ret = opts.callback(opts, *opts.args)
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 1467, in Validate
partitions = GetPartitionTableFromConfig(options, layout_filename, image_type)
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 663, in GetPartitionTableFromConfig
partitions = GetPartitionTable(options, config, image_type)
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 606, in GetPartitionTable
ApplyPartitionAdjustment(partitions, metadata, label, operator, operand)
File "/mnt/host/source/src/scripts/build_library/cgpt.py", line 632, in ApplyPartitionAdjustment
partition['blocks'] += operand_blocks
KeyError: 'blocks'
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/5b01484d1ab26d189764a8ae3342877e93c8a546 commit 5b01484d1ab26d189764a8ae3342877e93c8a546 Author: Evan Green <evgreen@chromium.org> Date: Wed Aug 29 18:15:30 2018 installer: Fix dd when SRC_BLKSIZE != DST_BLKSIZE When installing from a USB stick onto a 4k-block device like UFS, the sector offsets and counts are in different units. It is not appropriate to just send a bs=<N> argument into dd. Instead, send ibs= and obs= arguments in. According to the man page for dd, count= is in input blocks, seek= is in output blocks, and skip= is in input blocks. BUG= chromium:832160 TEST=Run chromeos-install on Cheza, with source of USB, dest of UFS. Change-Id: Idd604bf85a0011d1b84f57e52fcbbca81b91528a Reviewed-on: https://chromium-review.googlesource.com/1164463 Commit-Ready: Evan Green <evgreen@chromium.org> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/5b01484d1ab26d189764a8ae3342877e93c8a546/installer/chromeos-install
,
Aug 29
This is fixed now, right?
,
Aug 29
...mostly. There are some lingering pieces that need to get fixed, but those can probably be separate bugs.
,
Sep 1
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/overlays/overlay-variant-lakitu-mobbuild-private/+/2dc4be0e38365108108dad936c18481c18c1b1fe commit 2dc4be0e38365108108dad936c18481c18c1b1fe Author: Sam Hurst <shurst@google.com> Date: Sat Sep 01 02:03:21 2018
,
Sep 1
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/981cd3bf930882b4057c2e5272bc8f837bf70072 commit 981cd3bf930882b4057c2e5272bc8f837bf70072 Author: Sam Hurst <shurst@google.com> Date: Sat Sep 01 10:26:33 2018 disk_layout: Remove padding section Remove unneeded padding section BUG= chromium:832160 BRANCH=none CQ-DEPEND=CL:1179065 TEST=manual Change-Id: I94fc049c9e7270cef8ab5382c85ca4b3f255952f Reviewed-on: https://chromium-review.googlesource.com/1189129 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Stephen Barber <smbarber@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> [modify] https://crrev.com/981cd3bf930882b4057c2e5272bc8f837bf70072/project-termina/scripts/disk_layout.json
,
Sep 1
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/crosutils/+/14becb8b0d61e9769932e62349fede35129ae399 commit 14becb8b0d61e9769932e62349fede35129ae399 Author: Sam Hurst <shurst@google.com> Date: Sat Sep 01 10:26:32 2018 cgpt: Remove unused key name 'blocks' and 'block_size' Partition sizes are calculate in bytes instead of blocks. Remove unused key 'blocks' and 'block_size from ApplyPartitionAdjust function. BUG= chromium:832160 BRANCH=none CQ-DEPEND=CL:*668838 CQ-DEPEND=CL:1189129 TEST=manual setup_board --board=soraka build_image --board=soraka USE="chrome_media" ./build_image --board=soraka --adjust_part='STATE:+16G' --noenable_rootfs_verification test cros tryjob -g 1179065 -g 1189129 tatl-paladin-tryjob Change-Id: I8a5276adb4045e0fee940ce4f8a990c7a1e9303e Reviewed-on: https://chromium-review.googlesource.com/1179065 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> [modify] https://crrev.com/14becb8b0d61e9769932e62349fede35129ae399/build_library/cgpt.py
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/04211c61ef8d1f9d680ee9db5b30ad0855f4b99e commit 04211c61ef8d1f9d680ee9db5b30ad0855f4b99e Author: Evan Green <evgreen@chromium.org> Date: Tue Sep 18 21:04:23 2018 installer: Use best block size in dd This change uses the largest block size in fast_dd where count=, skip=, and seek= can all be represented exactly (without remainder). BUG= chromium:832160 TEST=Run chromeos-install on Cheza, with source of USB, dest of UFS. Change-Id: Icde0cfa6872434ef65f9ade6ee98ca10e513c5c9 Reviewed-on: https://chromium-review.googlesource.com/1188792 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> [modify] https://crrev.com/04211c61ef8d1f9d680ee9db5b30ad0855f4b99e/installer/chromeos-install
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/f03438013e1f87825effceb34ba754e1e5233a58 commit f03438013e1f87825effceb34ba754e1e5233a58 Author: Evan Green <evgreen@chromium.org> Date: Tue Sep 18 21:04:02 2018 installer: Fix another 4k-sector issue in copy_partition The copy_partition function had a condition that was both comparing source and destination block counts as if they were the same, and assuming 512-byte block sizes. Both parts of these condition do not work if one of the devices has a block size that is not 512 bytes. BUG= chromium:832160 TEST=Run chromeos-install on Cheza, observe sda12 now gets copied. Change-Id: I8d7855c8b610edf831e151869206f1d7648041d0 Reviewed-on: https://chromium-review.googlesource.com/1228606 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/f03438013e1f87825effceb34ba754e1e5233a58/installer/chromeos-install |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 Deleted