This thread is for chromeOS. Please bugs related to Chrome Browser in https://code.google.com/p/chromium/issues/list

The bug was filed correctly under Chromium OS issues.  It has nothing to do with the browser.  Why was it closed?

Yeah, this is a Chromium OS bug, not Chrome (nor Chrome OS), this is the right place for it.

Most people use a dedicated drive for CrOS, and it's possible that some startup scripts require it. So I'm not sure if this is a use case that many have even tried.

I see this on ARM, too.

It has been a while since I synced up.  (Since Oct 25?)
Installed image on SD card.
Booted it in recovery mode.
Hangs just as reported here.

I have a serial console through a mini servo connected to the debug port.  Console tty is alive.
No /var/log/ directory.

chromeos-install fails:
(none) ~ # chromeos-install 
*** glibc detected *** rootdev: free(): invalid next size (normal): 0x000fee48 ***
Aborted
/usr/sbin/chromeos-install: 145: 1: parameter not set


My office mate has a similar ARM system correctly running a build from 11/4.  3.0.3 kernel.
I am running today's 3.0.8 kernel.  But it does not feel like a kernel problem.

Build issue?  I have a lot of cros_workon stuff to clean up.

I can boot from SD with a 2.6.38 kernel but not a 3.0.8 image.
I can boot from USB with a 3.0.8 image (and I suspect with a 2.6.38 image, too).

I was able to get some strace output for the failing 'rootdev':
open("/sys/block/mmcblk0/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/mmcblk0boot1/device/subsystem/loop0/subsystem/subsystem/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I see a new directory /sys/block/mmcblk0/mmcblk0boot1 that has a symlink "device -> ../../mmcblk0" that can cause an infinite loop for functions that search sysfs and follow symlinks without loop detection.
Rootdev loops here if booting mmcblk1, but it does not loop here if booting sda or mmcblk0.

Doesn't this have to do with the OS not bein able to find the stateful partition?

Note that I am not booting from external media.  I've simply cloned two partitions to the main system hard drive with GRUB pointing to the root partition.

> Doesn't this have to do with the OS not bein able to find the stateful partition?

Not sure.

Bigazz, do you know if you are running the new 3.0 kernel?  Can you get to VT2 (via ctrl-alt-F2) and login to run 'uname -a'?  Can you run 'rootdev'?

On my ARM system, booting the unmodified 3.0.8 kernel gets me to the "repairing itself" screen that soon hangs.  This should not be a stateful partition issue for me since my SD card provides everything.

Noting that my 'rootdev' fails in an infinite loop on /sys/block/mmcblk0 hierarchy, I commented out the mmc_blk_alloc_parts() call in mmc_blk_probe().  This is the code that creates the mmcblk0boot0 subdirectory that contains the "device -> ../../mmcblk0" symlink.
A new SD card image with that kernel boots fine to the chrome login screen.  No "repairing itself" screen, no hang.  And rootdev works.

I will try fixing this in rootdev rather than the kernel to see if that works.  That would imply my chrome hang is caused by the rootdev failure rather than some other application failing similarly.

This happens both on 2.6 and 3.0 kernels.  rootdev runs fine.

Here are some notes from our investigation and discussion over irc.

Hexxeh's tweet indicates he transitioned to the 3.0 kernel on 11/8, basically a day after we did.  I checked a couple images from his site (http://chromeos.hexxeh.net/) and found that Version.1270 of 11/5 has 2.6.38.3, and Version.1290 of 11/10 has 3.0.8.
Steps:
1. Download and extract.
2. cgpt show ChromeOS-Vanilla-1270.0.2011_11_05_1711-r8250acb2.img
 :

   3940352     32768      12  Label: "EFI-SYSTEM"
                              Type: EFI System Partition
 :
3. mount -o loop,ro,offset=$((512 * 3940352)) ChromeOS-Vanilla-1270.0.2011_11_05_1711-r8250acb2.img tmp
4. file tmp/syslinux/vmlinuz.*
tmp/syslinux/vmlinuz.A: Linux kernel x86 boot executable bzImage, version 2.6.38.3 (chrome-bot@build3-m2), RO-rootFS, root_dev 0x802, swap_dev 0x3, Normal VGA
tmp/syslinux/vmlinuz.B: Linux kernel x86 boot executable bzImage, version 2.6.38.3 (chrome-bot@build3-m2), RO-rootFS, root_dev 0x802, swap_dev 0x3, Normal VGA


Our problems appear to be genuinely different.
Knocks was able to login (chronos/facepunch) and successfully run 'rootdev'.

It looks like knocks is using a custom partition layout.  His sda1 is a Windows partition, but /sbin/chromeos_startup expects to find the stateful partition there.
If it fails to mount the stateful partition there, it fails into repair mode.

If he really wants to get his USB stick working with Windows on partition 1, he needs to modify chromeos_startup to mount his correct stateful partition.

# In repair mode, after logging in as chronos on vt2:
# Get root access.
$ sudo bash
# Look for a stateful partition of about 1GB.  cgpt of the 1270 image here shows it to be 2097152 sectors, so 1048576 1K blocks.
$ cat /proc/partitions
# We see a match at sda3, but chromeos_startup appends '1' to the device name.  Let's change that.
$ mount -o remount,rw /
$ sed -i -e 's/}1/}3/'  /sbin/chromeos_startup
# Make sure it is written.
$ sync
# reboot
$ reboot

Knocks reports this works.

Closing this WontFix as the original report is not a bug.

My notes on the ARM side are copied to  issue 22855 .

Just to clarify, no USB sticks were involved at all.  Everything is working from a single notebook hard drive, Windows is dual booting great with Chromium OS.  Thanks for your help!

This has to be the most definitive article in reference to dual booting chrome and Windows 7.  After many hours of searching a Web on how to fix this issue I found this page, and I am dual booting seamlessly now.  May others find this link and enter dual/triple boot bliss.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)