Multiple chrome os recovery partitions in a single USB card

[François Beaufort]

I've been asked if it was possible to have 3 different Chrome OS recovery partitions on one stick/card.

I don't think it is but I'd like to be sure.

Thanks in advance,

Francois.

[Mike Frysinger]

i don't know what it is you're trying to do. there is only one active
kernel (as dictated by the gpt settings), and that is the recovery
kernel. it boots with an initramfs which then copies the normal
kernel/rootfs to the device and that's it. whatever else is on the
device is completely ignored & unused.
-mike

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
>
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
>
>

[Bill Richardson]

It's possible, but you have to create the image manually. It would be quite a bit of work to change the scripts to create the image automatically, and the resulting image would be a good bit larger. We looked at it and decided it would be better to approach the problem another way.

We've been working on refactoring the vboot_reference code to let us make changes to the way things are signed so we could address this and other problems, but at the moment that effort has been stalled while we work on more urgent things.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
 
 
 

--

Art for Art's Sake

Engineering for Money

[François Beaufort]

Thank both of you for these answers!

François Beaufort | beaufort.francois@gmail.com

[Oliver Madden]

Hi Guys,

Thanks so much for the time and knowledge. This was for me.

I train people on the chromebook and as a result I have to work with different models - I sometimes need to recover machines and normally I carry a lot of usb sticks with the various recovery images on them and just wondered if I could have all the images on one USB/SD card for convenience (maybe creating 3 or 4 partitions?).

Thanks so much for your time

Olly

[Mike Frysinger]

that's not a bad use case

unfortunately, our firmware doesn't give you a choice. so when
switching between devices, you'd have to first plug the device into a
different computer (probably a Linux machine) where you could
reprogram the partition table to select a different active recovery
kernel and re-number the parts so that the ROOTFS/KERN targets had the
right hardcoded partition #s.
-mike

[Bill Richardson]

On Mon, May 13, 2013 at 9:34 AM, Mike Frysinger <vap...@chromium.org> wrote:

you'd have to first plug the device into a
different computer (probably a Linux machine) where you could
reprogram the partition table to select a different active recovery
kernel

No, that's not true. We've built multi-platform recovery and factory keys before - just dd the kernels and rootfs partitions from each image you want onto a USB stick and mark all the kernels as valid (P=1, S=1). The firmware only tries the ones with the keys that match the BIOS.  It won't reset kernels any that have the successful bit set. But for N machines, you need N kernels and N root partitions. The actual differences may be very minor (/etc/lsb-release, etc.), but our current signing mechanism doesn't let us sign one kernel or rootfs with multiple keys. You can boot a single rootfs from multiple kernels by changing the kernel commandline (identify it by the rootfs' uuid instead of the kernel's uuid + 1 partition), but that requires resigning the kernel, which means using dev-keys, so it won't work for recovery.

Of course, we could create a signed patch-applying rootfs to modify one generic rootfs to fit each target system so that the signatures are valid. That's mostly what the AU does already. It's just a Simple Matter Of Programming that would take a ton of work to implement. 

[Mike Frysinger]

On Mon, May 13, 2013 at 12:51 PM, Bill Richardson <wfri...@chromium.org> wrote:
> On Mon, May 13, 2013 at 9:34 AM, Mike Frysinger <vap...@chromium.org> wrote:
>> you'd have to first plug the device into a
>> different computer (probably a Linux machine) where you could
>> reprogram the partition table to select a different active recovery
>> kernel
>
> No, that's not true. We've built multi-platform recovery and factory keys
> before - just dd the kernels and rootfs partitions from each image you want
> onto a USB stick and mark all the kernels as valid (P=1, S=1). The firmware
> only tries the ones with the keys that match the BIOS. It won't reset
> kernels any that have the successful bit set. But for N machines, you need N
> kernels and N root partitions. The actual differences may be very minor
> (/etc/lsb-release, etc.), but our current signing mechanism doesn't let us
> sign one kernel or rootfs with multiple keys. You can boot a single rootfs
> from multiple kernels by changing the kernel commandline (identify it by the
> rootfs' uuid instead of the kernel's uuid + 1 partition), but that requires
> resigning the kernel, which means using dev-keys, so it won't work for
> recovery.

interesting, that solves the booting issue. but doesn't the recovery
hardcode the GPT partition numbers it loads things from ?
-mike

[Bill Richardson]

No. If you look at the kernel commandline, it has strings like "%U+1" in it. The %U is expanded by the BIOS to be the paritition UUID for the kernel that was loaded. The "+1" tells the kernel to look in the next partition for the rootfs. It could be +2, -3, etc., or you could just hard-code the rootfs' UUID directly (which wouldn't be portable). But if you change any of that, you have to resign the kernel, which requires knowing private root keys, and that's the auto-signing part that must be rescripted to create a universal recovery image.

[Richard Barnette]

Both the initramfs recovery script and chromeos-install have hard-coded
information about the partitions holding the payload kernel and root FS.
So, yes, we'd need more code changes before we could take advantage
of the firmware behavior.


> -mike
>

-- jrb

[Mike Frysinger]

i was referring to the scripts inside the recovery kernel's initramfs (which Richard confirmed)

the recovery kernel doesn't boot a rootfs, so i don't think the dmcrypt settings on the command line matter

-mike

[Bill Richardson]

Oh, okay. Any boot device (recovery or not) can have as many different kernels as you want. The BIOS will find all those with valid flags, versions, and signatures, try them in priority order, and ignore the rest (the usual Tries vs Successful rules apply). The BIOS can provide the selected kernel's partition uuid to the command line by expanding any "%U", and the kernel can use a signed offset from that uuid to identify the rootfs (with or without dmverity, I think) if desired. What happens after that is up to the kernel and its initramfs or rootfs. Sounds like it's changed since the last time I looked.