(2015-02-04, 04:14)BBock727 Wrote: I'm Getting it much more frequently than you. I'll have to test a few files but with one one file I tried to play, it happened 4 times after reboot. I kept trying in the same location of the video

(2015-02-04, 03:38)Matt Devo Wrote:

(2015-02-04, 02:44)kupochu Wrote: Hi, this script is amazing, I've been using XBMCBuntu for the past few months with 0 problems. However, when trying to update it today, it seems to have picked up the version from 2015-01-29, not the most recent one.

The script has nothing to do with updating XBMCbuntu/Kodibuntu. If you're referring to the standalone coreboot firmware, the change log in the first post tells you it was last updated on 2015-01-29, so there's no issue. The only change for today was the version of OpenELEC used for dual booting or standalone install media creation.

Quote:Error in check_disks: could not repair filesystem, dropping to debug she'll, try to run 'fsck' manually: ***
### Starting debugging she'll... Type exit to quit ###
sh: can't access tty; job control turned off

Quote:The boot process checks the disk for errors and if detected boot stops so you can fix them, e.g. "fsck /dev/sda" ..runs a filesystem check on /dev/sda. You will need to figure out the /dev/device for the partitions on your boot disk (ls /dev/sd*, and ls /dev/mmc*). Once fixed "reboot" should get things working again. This will probably be seen most on systems with no power management which are inherently more prone to filesystem issues.

(2015-02-04, 08:58)nickr Wrote: /dev/sda*

(2015-02-04, 06:23)kupochu Wrote: Wait, so if I installed OpenElec over Kodibuntu, I wouldn't have to update the firmware to support OE 5.0.1? This is why I asked, in the first place, on why the coreboot firmware wasn't getting that update from earlier.

(2015-02-04, 07:08)carlson.v Wrote: Hi I am wanting to know how to install standalone ubuntu on my chrome box? I apologize if this is the incorrect place to bring it up but I thought I may get pointed I'm the right direction. I have the device in developer mode and the write protect screw removed. I have been unable to find guidance on Ubuntu standalone all that I have found is references to install whatever Linux distro you want but no clear instruction on how it's done. I know that I need to put the OS on a usb stick and then hit the esc key when the device boots up and then install from the stick but there is so many files for Ubuntu I don't know which one to choose for this particular purpose. Thanks in advance to whoever can help me

(2015-02-04, 08:13)Manic D Wrote: I need to know what the partition names on the Chromebox might be so I can fix this.

(2015-02-04, 08:13)Manic D Wrote: I need to know what the partition names on the Chromebox might be so I can fix this.

Quote:RTFW. This exact issue and the resolution are listed in the troubleshooting section.

(2015-02-04, 10:20)Matt Devo Wrote: not sure, I'd try the suggestions it listed (ie, run e2fsck -b 8193 /dev/sda2), but sounds like the filesystem might be hosed, and a fresh install might be the path of least resistance.

(2015-02-04, 04:14)BBock727 Wrote:

(2015-02-03, 23:59)naloj Wrote:

(2015-02-03, 23:32)crimper Wrote: Same problem. Nothing interesting in kodi logs when this happens. Hoping Openelec 5.0.1 brings more stability.

I had a total freeze w/Asus Chromebox + OpenELEC 5.0.1 about 2.5 minutes into playing a 720p mp4 video. Totally frozen; wouldn't respond to pings (ethernet).
Rebooted to see if I could reproduce and video playback was fine for 30 minutes straight.

Not sure how to debug such a thing, maybe connect a second display and direct kernel messages to it?

I'm Getting it much more frequently than you. I'll have to test a few files but with one one file I tried to play, it happened 4 times after reboot. I kept trying in the same location of the video

Quote:commit 587a7ba37c5c1e53731b6b48dcde7b17a682b5ac
Author: Alex Williamson <[email protected]>
Date: Thu Jan 15 18:17:12 2015 -0600

PCI: Mark Atheros AR93xx to avoid bus reset

commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.

Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.

[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]

[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/[email protected]
Reported-by: Andreas Hartmann <[email protected]>
Tested-by: Andreas Hartmann <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <bhelgaas@Google.com>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b01f14468da12c2e548dc965d522b12d51d4be9b
Author: Alex Williamson <[email protected]>
Date: Thu Jan 15 18:16:04 2015 -0600

PCI: Add flag for devices where we can't use bus reset

commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.

Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <bhelgaas@Google.com>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

(2015-02-03, 15:00)fritsch Wrote: Concerning VC-1: https://dl.dropboxusercontent.com/u/55728161/OpenELEC-Generic.x86_64-5.0.1-vc1.tar

Does that make the VC-1 issues better, worse or no difference. Please pastebin a complete log with component logging audio and video enabled.