+wonderfly, are you the right contact for lakitu? Could you help us test whether this change would break anything for you? Essentially, you should just have to:

 mount /dev/sda12 /media
 tar cjf /tmp/part12.tbz -C /media
 umount /media
 mkfs.vfat -S 4096 -n "EFI-SYSTEM" /dev/sda12
 mount /dev/sda12 /media
 tar xf /tmp/part12.tbz -C /media
 umount /media

and see if it still boots afterwards.

+Aditya

I'm heading out for the long weekend...

+cc edjee@
We use this partition to store certain things. But I don't think this change should break us. Edward can confirm.

(chromeos-install nuking this partition isn't great for us in the first place, but thats a separate issue).

Thanks. I'll do the experiment (described in comment 2) today.

A question: When does chromeos-install run "dd"? Is that for in-place auto update? Or installing the system from USB stick?

Are we going to change the partition 12 from 512b-sector VFAT to 4k-sector VFAT?

Lakitu runs on GCE VMs that may have UEFI firmware. So the first thing I need to verify is: whether GCE's UEFI firmware can access the 4k-sector formatted EFI System Partition.

> A question: When does chromeos-install run "dd"? Is that for in-place auto update? Or installing the system from USB stick?

AFAIK chromeos-install only runs when you reinstall the whole system (e.g. when you use a recovery USB stick, or by running it manually). For auto-updates, I think(?) update_engine just copies the relevant kernel and rootfs directly. The partition 12 file system should not get recreated during an auto-update.

> Lakitu runs on GCE VMs that may have UEFI firmware. So the first thing I need to verify is: whether GCE's UEFI firmware can access the 4k-sector formatted EFI System Partition.

Yes, that is exactly what I'm asking you to confirm. We've already checked that Linux itself can deal fine with 4K-sector FAT file systems.

I tried prototyping this up, but syslinux has 512-byte sectors hardcoded into it, so I wasn't able to get through the build_image phase. Given that I'm not actually trying to enable any scenarios, ripping through syslinux to add support for 4k sectors didn't seem worth it.

I also prototyped up a change that removes partition 12 entirely [1], but I worry that having a non-standard partition layout from the rest of Chrome OS is likely to invite trouble, and is more risk than it's worth. So I abandoned that.

Right now chromeos-install will dd a partition 12 onto the disk that is formatted for 512B sectors. The kernel cannot mount this partition, but update_kernel.sh has been patched up to ignore this error. (Side note: when we rebased to kernel 4.19, the kernel started printing an error message explaining exactly why it couldn't mount, which is nice.)

I am now proposing leaving things this way. One possible optimization we could do is to detect this mismatch and not bother copying partition 12 data over. But actually I think we shouldn't do this because 1) it again may invite problems in the future because it will be a fairly cold path, 2) the time savings in chromeos-install are minimal, and 3) the uninitialized data in partition 12 could be nasty and invite exploits.


[1] https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/1255455