| 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. 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. |
Yes, but there's a switch to turn it off. I hope that continues to be true with production devices.