Skip to main content

google chrome - Can't boot to alternate OS or Live CD

I'm having trouble installing a new OS on a Toshiba Satellite Chromebook. I continue to encounter a message "The device you inserted does not contain Chrome OS".


I basically followed Chrome OS's Poking around your Chrome OS Device. The device wiped itself after I enabled developer mode. I can enter developer mode via ESC+F3+Power, and I get the message "Boot verification is OFF" and then I get a message "Chrome OS is missing or damaged". I'm fine with it because I'm installing a new OS.


However, when I insert the thumbdrive with debian-8.3.0-amd64-lxde.iso dd'd on to it, it results in the message "The device you inserted does not contain Chrome OS". I get the same message when I boot with the thumbdrive inserted. I also get the same message when attempt to boot debian-8.3.0-i386-lxde.iso.


According to Product Forums and Chromebook Central Help Forum, it could be a problem with the thumbdrive maker or the physical USB port. The forum question states there's a problem with ScanDisk dirves, but I tried both PNY and generic manufacturer called USB2.0 (according to dmesg). The forum post also states there can be problems with USB 2.0 and 3.0 ports. I tried both USB ports with no joy.


I also found a message that says to boot with CTRL+U (USB boot) and another for CTRL+L (legacy boot), but neither helped.


Any ideas what the secret recipe is to actually boot to another OS?



Below is the output of crossystem --all. I believe it was taken with only a USB boot; and not a Legacy boot.


arch                   = x86                            # Platform architecture
backup_nvram_request   = 1                              # Backup the nvram somewhere at the next boot. Cleared on success.
block_devmode          = 0                              # Block all use of developer mode
clear_tpm_owner_request = 0                              # Clear TPM owner on next boot
clear_tpm_owner_done   = 1                              # Clear TPM owner done
cros_debug             = 1                              # OS should allow debug features
dbg_reset              = 0                              # Debug reset mode request (writable)
debug_build            = 0                              # OS image built for debug features
dev_boot_usb           = 1                              # Enable developer mode boot from USB/SD (writable)
dev_boot_legacy        = 0                              # Enable developer mode boot Legacy OSes (writable)
dev_boot_signed_only   = 0                              # Enable developer mode boot only from official kernels (writable)
dev_default_boot       = disk                           # default boot from legacy or usb (writable)
devsw_boot             = 1                              # Developer switch position at boot
devsw_cur              = 1                              # Developer switch current position
disable_dev_request    = 0                              # Disable virtual dev-mode on next boot
ecfw_act               = RW                             # Active EC firmware
fmap_base              = 0xffe10000                     # Main firmware flashmap physical address
fwb_tries              = 0                              # Try firmware B count (writable)
fw_vboot2              = 0                              # 1 if firmware was selected by vboot2 or 0 otherwise
fwid                   = Google_Swanky.5216.238.5       # Active firmware ID
fwupdate_tries         = 0                              # Times to try OS firmware update (writable, inside kern_nv)
fw_tried               = A                              # Firmware tried this boot (vboot2)
fw_try_count           = 0                              # Number of times to try fw_try_next (writable)
fw_try_next            = A                              # Firmware to try next (vboot2,writable)
fw_result              = unknown                        # Firmware result this boot (vboot2,writable)
fw_prev_tried          = A                              # Firmware tried on previous boot (vboot2)
fw_prev_result         = unknown                        # Firmware result of previous boot (vboot2)
hwid                   = SWANKY E5A-E3P-A47             # Hardware ID
kern_nv                = 0x00000000                     # Non-volatile field for kernel use
kernkey_vfy            = hash                           # Type of verification done on kernel key block
loc_idx                = 0                              # Localization index for firmware screens (writable)
mainfw_act             = A                              # Active main firmware
mainfw_type            = developer                      # Active main firmware type
nvram_cleared          = 1                              # Have NV settings been lost?  Write 0 to clear
oprom_needed           = 0                              # Should we load the VGA Option ROM at boot?
recovery_reason        = 0                              # Recovery mode reason for current boot
recovery_request       = 0                              # Recovery mode request (writable)
recovery_subcode       = 0                              # Recovery reason subcode (writable)
recoverysw_boot        = 0                              # Recovery switch position at boot
recoverysw_cur         = (error)                        # Recovery switch current position
recoverysw_ec_boot     = 0                              # Recovery switch position at EC boot
ro_fwid                = Google_Swanky.5216.238.5       # Read-only firmware ID
sw_wpsw_boot           = 1                              # Firmware write protect software setting enabled at boot (Baytrail only)
tpm_attack             = 0                              # TPM was interrupted since this flag was cleared
tpm_fwver              = 0x00050001                     # Firmware version stored in TPM
tpm_kernver            = 0x00010001                     # Kernel version stored in TPM
tpm_rebooted           = 0                              # TPM requesting repeated reboot (vboot2)
tried_fwb              = 0                              # Tried firmware B before A this boot
vdat_flags             = 0x00002c54                     # Flags from VbSharedData
vdat_lfdebug           = Check A result=12
Check B result=0
Firmware index booted=0x00
TPM combined version at start=0x00050001
Lowest combined version from firmware=0x00050001
 # LoadFirmware() debug data (not in print-all)
vdat_lkdebug           = Calls to LoadKernel()=1
Call 1:
  Boot flags=0x01
  Boot mode=2
  Test error=0
  Return code=0
  Debug flags=0x00
  Drive sectors=30777344
  Sector size=512
  Check result=4
  Kernel partitions found=1
  Kernel 1:
    GPT index=2
    Start sector=20480
    Sector count=32768
    Combined version=0x00010001
    Check result=19
    Debug flags=0x00
 # LoadKernel() debug data (not in print-all)
vdat_timers            = LFS=190037224,270923042 LF=271933896,415021854 LK=0,30822665 # Timer values from VbSharedData
wipeout_request        = 0                              # Firmware requested factory reset (wipeout)
wpsw_boot              = 1                              # Firmware write protect hardware switch position at boot
wpsw_cur               = 1                              # Firmware write protect hardware switch current position

Comments

Post a Comment

Popular Posts

How do I transmit a single hexadecimal value serial data in PuTTY using an Alt code?

I am trying to sent a specific hexadecimal value across a serial COM port using PuTTY. Specifically, I want to send the hex codes 9C, B6, FC, and 8B. I have looked up the Alt codes for these and they are 156, 182, 252, and 139 respectively. However, whenever I input the Alt codes, a preceding hex value of C2 is sent before 9C, B6, and 8B so the values that are sent are C2 9C, C2 B6, and C2 8B. The value for FC is changed to C3 FC. Why are these values being placed before the hex value and why is FC being changed altogether? To me, it seems like there is a problem internally converting the Alt code to hex. Is there a way to directly input hex values without using Alt codes in PuTTY? Answer What you're seeing is just ordinary text character set conversion. As far as PuTTY is concerned, you are typing (and reading) text , not raw binary data, therefore it has to convert the text to bytes in whatever configured character set before sending it over the wire. In other words, when y...
Post a Comment
Read more

linux - Extract/save a mail attachment using bash

Using normal bash tools (ie, built-ins or commonly-available command-line tools), is it possible, and how to extract/save attachments on emails? For example, say I have a nightly report which arrives via email but is a zip archive of several log files. I want to save all those zips into a backup directory. How would I accomplish that? Answer If you're aiming for portability, beware that there are several different versions of mail(1) and mailx(1) . There's a POSIX mailx command, but with very few requirements. And none of the implementations I have seem to parse attachments anyway. You might have the mpack package . Its munpack command saves all parts of a MIME message into separate files, then all you have to do is save the interesting parts and clean up the rest. There's also metamail . An equivalent of munpack is metamail -wy .
Post a Comment
Read more

ubuntu - Why does my USB hdd returns SG_IO: bad/missing sense data?

I am able to boot and run commands from external USB hdd; the message in question appears for about 45 seconds then booting continues. GRUB2 is installed on internal HDD. When choosing to boot directly to /dev/sdb the message doesn't appear, however boot time is about the same as booting to internal HDD. /dev/sdb: Timing cached reads: 1018 MB in 2.00 seconds = 508.97 MB/sec Timing buffered disk reads: 80 MB in 3.03 seconds = 26.37 MB/sec pfeiffep@de:~$ sudo hdparm -i /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 10 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 HDIO_GET_IDENTITY failed: Invalid argument Gparted correctly identifies the drive as SAMSUNG MP0402H. Any ideas how to remedy the HDIO & SG_IO messages?
Post a Comment
Read more

Desktop reboots itself on sleep or hibernate

I have been using an ASUS M2NPV-VM motherboard for main home desktop workstation, operating Windows Vista x64. This computer has right from day one not been able to enter hibernate or standby; after Windows performs its final actions and brings the machine down, it would automatically revive itself for a reboot. Updating to the second latest BIOS (1201)has not helped (the latest BIOS revision would induce video refresh problems rendering it unusable). I have been reading related discussions on incidents similar to mine to no avail of a true workable solution. They appear to be more speculative guesses rather than actual knowledge on the inner workings of motherboard hardware. Does anybody have any electronic engineering experience on PC energy-saving standards to provide a more informed opinion how to go about getting this to work? More stories: this motherboard could not even reboot properly the first thing i used it. It was due to refresh rate of the onboard GPU, which had no influe...
Post a Comment
Read more