tl;dr Guy receives a CR48 with windows 7. Contacts google/google groups. No one has any real answer how this could have happened. Google product guy sends him an email with RMA details. Participant complies. But before sending it back he dumps the BIOS out. Some one from chromeOS forums successfully flashed their BIOS with this one. So this works.
I fully understand that one should use these CR 48 laptops for what they are intended to be for. That is testing purposes.
initrd is typically handled by the bootloader, which reads the specified image from the disk into RAM and passes the address to the kernel as it's invoked.
The Chrome OS BIOS is a modified EFI BIOS. The bootstub is a standard EFI Application, but it's embedded in the kernel image in a dedicated partition type, rather than accessible through a FAT filesystem. To decrease boot time, the BIOS does not discover or pass the standard disk drive handles to the bootstub, so the bootstub doesn't know anything about disks or filesystems. There is also no Compatibility Support Module in the BIOS. In theory elilo or grub2 could replace the bootstub, but they would have to reimplement some of the device discovery functions normally done by an EFI BIOS.
If you want to take this on, go for it. That would let us create a kernel partition that just contained an EFI bootloader, which could then chain-boot to external USB drives, etc. That might be kind of cool.
Oops. I reread what I wrote and now I am confused. Maybe you are right. In developer mode, self signed images work. But I will leave the post.
--------------------------------
If you are talking about developer mode, Yes. I am pretty sure they intend to have that option in production devices.
No. I think, even in developer mode the boot process checks for google signature.
From their site;
"The first time a Chrome Notebook boots in Developer Mode after leaving Normal Mode it will:
- Show a scary warning that its software cannot be trusted, since verified boot is disabled (press Ctrl-D or wait 30 seconds to dismiss).
- Erase all personal data on the "stateful partition" (i.e., user accounts and settings - no worries, though, since all data is in the cloud!).
Make you wait between 5 and 10 minutes to while it erases the data.
- Boot from any self-signed image on its SSD, negating the security of verified boot.
ok, I think the chromeos forums deleted the thread. They are not in any way affiliated with google btw. Here is the screenshot which has instructions from the guy who said he flashed.
http://imgur.com/TN21R
Ok, just got done with this. I can verify 100% working. Instead of installing another OS though, I just rebooted after the BIOS flash and surprisingly Chrome started up! It erased the stateful partition and then reboot and voila I am back in Chrome -- with the notable exception -- of now being able to get into the BIOS.
(Off-topic) On the last screenshot in Ubuntu section, the guy had accidentally photoed his own credit card, laying near CR48, with number and expiry date almost clearly readable. I don't know whenever this is secure (his bank may disallow CNP transactions), but, maybe, someone should notify him about this.
I fully understand that one should use these CR 48 laptops for what they are intended to be for. That is testing purposes.
ChromeOS forums: http://www.chromeoslounge.com/cr-48-chrome-notebook/607-wind...
Youtube link: www.youtube.com/?v=sy9JzYTP4xc
Right now google uses Verified Boot, meaning that only Google-signed images will be bootable. More info on this process here. http://www.chromium.org/chromium-os/chromiumos-design-docs/v...
CR48 doesnt have a regular bootloader like grub or lilo. Some more info on CR48 BIOS from their site. https://sites.google.com/a/chromium.org/dev/chromium-os/deve...
initrd is typically handled by the bootloader, which reads the specified image from the disk into RAM and passes the address to the kernel as it's invoked.
The Chrome OS BIOS is a modified EFI BIOS. The bootstub is a standard EFI Application, but it's embedded in the kernel image in a dedicated partition type, rather than accessible through a FAT filesystem. To decrease boot time, the BIOS does not discover or pass the standard disk drive handles to the bootstub, so the bootstub doesn't know anything about disks or filesystems. There is also no Compatibility Support Module in the BIOS. In theory elilo or grub2 could replace the bootstub, but they would have to reimplement some of the device discovery functions normally done by an EFI BIOS.
If you want to take this on, go for it. That would let us create a kernel partition that just contained an EFI bootloader, which could then chain-boot to external USB drives, etc. That might be kind of cool.