[Matt Devo]

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

send me a PM with more info on the file if you have something that's reproduceable

[kupochu]

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.

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.

[carlson.v]

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

[nickr]

Same as installing any other OS. When you choose to install from a ubuntu boot medium, it actually doesn't give much option. Just go through the install gui, and it will be there.

[Manic D]

OpenELEC updated to the latest, and on boot I get:

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

Saw a few posts at the OE forums about it :

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.

I need to know what the partition names on the Chromebox might be so I can fix this.

[nickr]

/dev/sda*

[Manic D]

/dev/sda*

D'oh! I thought the asterisk was where I needed to enter something specific.

Now it says need terminal for interactive repairs.

[nickr]

You do really need to enter something specific. But tab completion will show you all the options. ie type

fdisk /dev/sda<tab><tab>

you should be able to see all the options. I don't think you'll be able to do any harm trying to repair a partition that is not damaged, so do them all.

[Manic D]

I get invalid syntax with that.

I give up for tonight. I will check back tomorrow and see if I can figure it out.

[Matt Devo]

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.

you're confusing two unrelated things. If you have the standalone firmware flashed, you can install any OS you want (other than ChromeOS and Windows prior to 8.1). The firmware and OS are not coupled in any way.

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

1) follow steps for standalone setup
2) install Ubuntu instead of OpenELEC

Info on creating the Ubuntu USB installer is on Ubuntu's site, and is no different than on any other 64-bit x86 PC.

I need to know what the partition names on the Chromebox might be so I can fix this.

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

[Manic D]

I need to know what the partition names on the Chromebox might be so I can fix this.

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

Thanks. Sorry I forgot to check the wiki.

I get this result after running fsck on sda2:

Bad magic number in super-block
superblock invalid, trying backup blocks
bad magic number in super-block while trying to open /dev/sda2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. etc...
...you might trying running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

[Matt Devo]

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.

[Manic D]

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.

I'm gonna do a fresh install. Thanks again.

[naloj]

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

I just got my Chromebox on Saturday and setup on Sunday so I haven't had much time to mess with it.

Last night:

720p h264 mkv via smb played ok for 42 mins.
720p h264 mkv via smb had to buffer twice and was a tad slow about it but was otherwise ok for 42 mins.
Tried to play something via ServerWMC and connection failed. Pretty sure ethernet dropped again. GF played back show via xbox 360 fine.

This morning:

Tried to play a show for my daughter; network down. Verified network was up according to the openelec interface but couldn't ping.
Rebooted, played 480p h264 mp4 ok for 7 mins.
Played second 480p h264 mp4 show; froze after 2 mins.

UI was unresponsive to mouse/kbd input for a few minutes. Was about to reboot it when I saw that the default 3 min screensaver dim kicked in. UI was responsive again. Network came back on it's own.

I did ssh in after the network came back on it's own and no errors or messages of any kind in the dmesg buffer. So it's not the link going up/down I don't think (still need to verify link lights on switch/NIC).

I had an i5 NUC (D54250WYKH1) connected to the same switch with the same cable and it never had any network playback issues. (ServerWMC, Netflix, Amazon Prime Video). Decided to downgrade since it was so overpowered for what I was doing.

I'm at work now and couldn't ssh or ping it. Then tried again a few minutes later and it's up. Really weird.

I saw there's a fix for Atheros 93xx cards freezing the whole system in the kernel changelog for 3.8.15.

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/20140923210318....c.maya.org
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/20140923210318....c.maya.org
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <bhelgaas@Google.com>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Card in my Asus Chromebox is a 9462 though but I still find it very suspicious.

Going to pull the card and see if that helps any. If not will try to load Arch on there so I can mess around a bit when it happens again.

EDIT: Forgot to mention the USB devices I have attached which may be relevant in finding some sort of commonality:

- Logitech unifying receiver (via usb extension cable for K400)
- FLIRC (not setup/used yet)
- Turtle Beach soundcard (not setup/used yet)

[bhampton]

Concerning VC-1: https://dl.dropboxusercontent.com/u/5572....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.

Hi,... I loaded up this version on my chrome box and tested.

With Vaapi acceleration on I got blocky artifacts in at least 2 of my VC1 movies. Deep Blue Sea starting at 6:11 and Jurassic Park starting at 3:11. Both of these scenes can be difficult to process as in the Deep Blue Sea scene people are speaking behind a spinning plane prop and in the Jurassic Park scene lights are flashing like strobes everywhere.

When I turn Vaapi acceleration for VC1 off - Both these scenes play back without the artifacts.

This is no different ... no better or worse than it has always been. I would leave Vaapi for VC1 off at all times but other VC1 encodes seem to need it. The Dark Knight is an example and Fast Times at Ridgemont High.... Both of those are choppy without Vaapi for VC1.

If you still would like a log posted, then I will go read how to do it and do it because I want to do my part... however, would you want that with the Vaapi for VC1 on or off at the time and with the blocky movie or the choppy movie?

Unless I find other movies with trouble I think my plan would be to just leave Vaapi for VC1 on most of the time and try to remember to turn it off for those 2 movies.


Again.... thank you for all help....


-Brian