Use non-ChromeOS kernel on Lenovo Thinkpad X131e Chromebook

767 views
Skip to first unread message

Chris Seekamp

unread,
Mar 30, 2014, 9:53:11 AM3/30/14
to chromium-...@chromium.org
I have a Lenovo Thinkpad X131e Chromebook with stout 2817.52.0 firmware. I have read that you can sign your own kernel using vbutil_kernel. I have been able to sign and use Chrome OS kernel, but not a regular Linux kernel.  Is it possible to sign and boot from a non ChromeOS Linux kernel?

The stout firmware pre-dates the firmware on newer Chromebooks with Ctrl-L legacy boot support. There is a lot of documentation on using your own kernel on ARM-based Chromebooks and some of the early x86 models, but not on the Thinkpad. If it is possible to do what I am trying, can anyone point to documentation that might help?

Thanks in advance.

Mike Frysinger

unread,
Mar 31, 2014, 1:25:27 PM3/31/14
to grokf...@gmail.com, Chromium OS discuss
yes, you should be able to sign/boot your own kernels.  the process for stout is the same as all other devices.

i cannot comment on the status of the mainline kernel for stout though.  someone else will have to do that.

if you're just trying to deploy a custom kernel with a normal CrOS userland, the kernel faq has tips for simplifying that process:

Chris Seekamp

unread,
Mar 31, 2014, 2:14:10 PM3/31/14
to chromium-...@chromium.org, grokf...@gmail.com
Thanks Mike. Just to clarify, are you saying it is possible to take an existing 64-bit kernel like one used in a recent Ubuntu release and use vbutil_kernel to sign it and boot it on a chromebook?  Or do I have to start with Chromium kernel_next or something like that?  Or can I take a non-ChromeOS kernel, but I have to build it myself with stuff that turns it into what looks like a ChromeOS kernel?

I haven't found a post describing using anything but a ChromeOS kernel.

Also, do you know if there is any way to change the kernel mode to cros_efi or cros_legacy instead of cros_secure without changing the firmware?

Thanks again.

Mike Frysinger

unread,
Mar 31, 2014, 2:57:32 PM3/31/14
to Chromium OS discuss
speaking generally, yes, you should be able to take a stock kernel from e.g. Ubuntu and run it through vbutil_kernel to get something the CrOS firmware will recognize.

specifically to stout, i don't know the status of the drivers that stout relies on in Ubuntu/mainline kernels.  if all the drivers are in there, you should be able to get graphics/etc...  someone on the kernel team would have to comment as they keep track of these things.

i'm not sure why you want to change cros_efi/cros_legacy.  those are used to tell the kernel what kind of firmware the system has.  if you have stock CrOS firmware, lying to the kernel/userland that you have EFI or classic BIOS doesn't seem like a good idea.  what is it you actually want to do ?  note: those options really only make sense to a CrOS kernel/userland.  if you're booting stock Ubuntu, then the settings shouldn't matter.
-mike


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


Chris Seekamp

unread,
Mar 31, 2014, 3:33:01 PM3/31/14
to chromium-...@chromium.org
Thanks Mike. The reason I asked about about cros_efi and cros_legacy is because I found partition 12 on the main drive and I read those would be used with that kernel setting. What I am trying to do is boot a new linux kernel with Ubuntu on my chromebook. I can switch back and forth between Ubuntu and ChromeOS by changing the priority of the kernel partition (via cgpt command of course).  

I have tried using vbutil_kernel to sign the kernel by using vbutil_kernel --pack ...  I have tried various options. I read I had to specify --arch arm even though it is x86 (but I have tried --arch x86 as well).  I am using a flash drive (one that I have successfully been able to boot with ChromeOS from) with kernel in partition 1 and root fs in partition 2.  When I use Ctrl-U (after using vbutil_kernel with --arch arm) it reads the USB (the lights blink) and eventually the screen backlight comes on, I hear the fan come on and it just sits there. I can't tell what is happening. There are no logs in /var/log of the root fs.  If I don't use --arch arm with vbutil_kernel, when I boot it reads the USB but then goes back to the unverified boot screen (of course my chromebook is in developer mode).  

Do I need to specify kernel load address, or is that just an ARM specific thing?  Do I need to supply a bootloader via --bootloader argument to vbutil_kernel?  Like I said, I haven't been able to find examples of someone giving an example of signing an x86 kernel that is not ChromeOS. 
Unfortunately, from what I was told, it is not possible for me to capture the coreboot log using stock firmware.

Sonny Rao

unread,
Mar 31, 2014, 4:11:45 PM3/31/14
to grokf...@gmail.com, Chromium OS discuss
you shouldn't use --arch arm on an x86 machine or a kernel load
address so something is wrong there

you should be able to do something like this:

vbutil_kernel --pack <output blob filename> --config <path to file
containing kernel command line> --keyblock <path to
chroot>/src/platform/vboot_reference/tests/devkeys/kernel.keyblock
--signprivate <patch to
chroot>/src/platform/vboot_reference/tests/devkeys/kernel_data_key.vbprivk
--vmlinuz <path to kernel vmlinuz file> --arch x86

then dd the output blob onto the desired partition

in the config file, make sure that root= is specified as a specific
device or using the %U/PARNROFF=<number> format relative to the kernel
partition, where the firmware will substitute %u with the GUID for the
kernel partition.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-os-dis...@chromium.org.

Mike Frysinger

unread,
Mar 31, 2014, 4:31:18 PM3/31/14
to Chromium OS discuss
what you want to do wrt storing the kernel in partition 12 and tweaking the cros_xxx flags is not possible w/out building your own firmware and deploying it on the device.  the firmware in stout only recognizes CrOS formatted kernels, and that means they have to live in dedicated kernel partitions rather than read out of a FS.
-mike
Reply all
Reply to author
Forward
Message has been deleted
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages