| commit | 1a69c325a7962264744878191a1f8eb8e75c5609 | [log] [tgz] |
|---|---|---|
| author | Konrad Adamczyk <[email protected]> | Mon Dec 01 11:42:59 2025 |
| committer | Chromeos LUCI <[email protected]> | Thu Dec 11 17:47:08 2025 |
| tree | dfed7ffa924596f10232442ee5b6dae38a56c029 | |
| parent | d03924e45d4ddd1f6151e551b0847f1a04d091bb [diff] |
desktop: Enable dev_boot_usb by default as part of recovery process
On signed user builds, the `crossystem` utility is not accessible by
default (lack of `adb root`).
Nevertheless, to enable boot from USB devices, first users would need
to enable ADB (including over TCP), which may be not convenient.
Enable dev_boot_usb on every recovery.
BUG=b:456440148
BUG=b:457449610
TEST=DUT in normal mode. Disable dev_boot_usb. Use recovery image.
After successful boot, get back to Developer mode.
Observe "Boot from external drive" button on Developer mode screen.
Change-Id: I8c44374e863eb93ad92d3ee772c3539f65a83984
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/initramfs/+/7209220
Reviewed-by: Raul Rangel <[email protected]>
Tested-by: Konrad Adamczyk <[email protected]>
Reviewed-by: Jae Hoon Kim <[email protected]>
Commit-Queue: Konrad Adamczyk <[email protected]>
Build logic for creating standalone initramfs environments.
See the README files in the respective subdirs for more details.
Normally you wouldn't build in this directory directly. Instead, you would build the chromeos-initramfs package with the right USE flags. e.g.:
$ USE=recovery_ramfs emerge-$BOARD chromeos-initramfs
That will install the cpio initramfs files into the sysroot for you to build into a kernel directly. The various build scripts would then be used to make the right kernel/image using those (e.g. mod_image_for_recovery.sh).
You could build these by hand for quick testing. Inside the chroot:
$ make SYSROOT=/build/$BOARD BOARD=$BOARD <target>
That will create the cpio archives for you.
It is possible to debug few of the initramfs targets in QEMU. Read test/README.md for more information.
Also, here is a shortcut for developing/debugging graphical bits in initramfs, without having to create a full image for every iteration.
After emerge-$BOARD, find your initramfs package from chroot /build/$BOARD/var/lib/initramfs and copy to a running DUT, for example /tmp/recovery_ramfs.cpio, then do followings on DUT over SSH:
mkdir /usr/local/test/; cd /usr/local/testxzcat /tmp/XXXXXX_ramfs.cpio | toybox cpio -iv (Here we assume that the kernel is configured to use xz compression for its initramfs.)stop ui; kill $(pidof frecon)for d in dev proc sys tmp; do
mount --bind /${d} /usr/local/test/${d}
done
chroot /usr/local/test /initSince the initramfs is bundled into the kernel, and our read-only firmware loads the kernel, we cannot create kernel images that are too big for the firmware to load into memory. The current limit applies to the entire kernel+initramfs image and depends on the device. We cannot rely on the read-write firmware booting things as it might not be upgraded, might be corrupted, and might not even be loaded at all depending on the device.
Older devices had a 8 MiB or 16 MiB limit, but those are all EOL now, so we do not need to worry about them.
These devices have a 32 MiB limit and must be supported until they all go EOL (which is at least Jun 2025).
All other supported devices have a 512 MiB limit, although that limit is a little fuzzy. It's meant to be “nobody could ever possibly need this much, right?” rather than “you can def use all 512 MiB”. We could loosen our belts a bit from 32 MiB by going up to e.g. 128 MiB, but if we start getting anywhere close to 512 MiB, we should strongly reevaluate our choices, and make sure we finally have automated coverage to verify exact sizes for current devices.
In practice, for projects that are shared across devices (i.e. recovery), we need to stay within the smallest limit (32 MiB). For projects that are device specific (i.e. hypervisor), they may rely on that device-specific limit. For projects that are shared across devices but only launched on newer ones (i.e. miniOS), they may rely on the smallest limits those devices share.
The list of devices here is not 100% complete, but is meant for general guidance when making decisions. The device names are what depthcharge uses. Most map directly to $BOARD names, but some might be slightly different.