I had similar 'screen symptoms' with 0.6.57 ...
That's good to hear, I mean in not-a-faulty-hardware sense.
I had similar 'screen symptoms' with 0.6.57 ...
That's good to hear, I mean in not-a-faulty-hardware sense.
You can clone your installation on SD card to eMMC
Thank you for the outline I was so lost.
It's good to know I can use Etcher to burn an image to eMMC. I have also purchased USB-eMMC adapter hoping it would, but was not sure because at Pine64 forum they usually talk about a jumper trick to prevent eMMC booting and then DD cloning after SD booting.
Just to check I understood this right,
- using Etcher to burn eMMC with current 0.6.44 stable image is not yet bootable right? (The changelog states eMMC booting is supported with 0.6.53 or newer)
- apt-get upgrade and DD cloning would enable me to replace SD with eMMC at some point in the future but not now, - cf. when new stable version is released - even if I started with 0.6.44 SD)
- Since latest pre-release(0.6.57) is not functioning('screen symptoms'), there is no (easy) way to use eMMC with OMV images for Rock64 for now.
Is this all correct?
And I am testing apt upgrade for fun, to see what happens, It's odd that bellow command stated on the ayufan-rock64 release page only seems to update arm64 components even though I am using stretch-openmediavault-rock64-0.6.44-armhf.img.xz with pre-release repository enabled. Anyway it fails to boot with "screen symptoms" after bellow command.
Surprisingly stretch-openmediavault-rock64-0.6.44-239-armhf.img on eMMC boots fine.
I used eMMC-USB adapter and Etcher to burn eMMC with the image.
I guess the Changelog on the Release page is somewhat misleading whatever the actual meaning is.
0.6.x
0.6.57: Make HDMI a first audio device for rockpro64,
0.6.57: Remove some of the failures from bootlog,
0.6.57: Temporarily disable GPU,
0.6.56: Remove dma plat init to have bigger buffers everywhere :)
0.6.55: Make rockchip phy drivers to be built-in,
0.6.54: Rebase 4.4 kernel on rockchip-linux/kernel@6a9bb29,
0.6.53: Support eMMC booting,
You can add this command to /etc.rc.local to be executed on every reboot.
In my setup /etc/rc.local is missing. I've heard about it being deprecated, not sure about the alternative way on armbian.
Should I write a systemd unit to run something like rc.local?
systemd unit file. "After=network.target" was chosen for no reason, probably there is a better place for it.
[Unit]
Description=Set Keyboard Log Level to 4
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/sbin/stopkeylog
[Install]
WantedBy=multi-user.target
Alles anzeigen
Let's call this stopkeylog.service. copy this to /etc/systemd/system/
"systemctl enable stopkeylog.service" to install.
stopkeylog
Yes. It's a bit too much for a single line of code.
Good to know rc.local works by just creating it. Some Stretch distribution has systemd service unit file to run rc.local (because it doesn’t run by itself anymore), some doesn’t. That’s current situation in Raspian land any way.
I have several scripts run by systemd unit files from Pi’s, like Pushbulleting IP to me when booted and yes I currently have them on Rock64 and they work. I prefer rc.local way though, it’s simpler.
Anyone got docker working for Rock64? My Docker Container keep automatically getting Exited.
Anyone got docker working for Rock64? My Docker Container keep automatically getting Exited.
Works on my renegade and rockpro64. Are you using an arm-specific docker image?
Solved it, had to run container in "Privileged mode" for some reason.
the rock64 with 1 ssd on usb3 works fantastic. Would like to test TVheadend (which works perfect with libreElec) on OMV
Question:
- the x86 releases of OMV are very sensible against power loss and corrupted systems after that. How is this release? I would make it part of my caravan media system and dont want to kill the system in the case the power is off accidently.
- how do I install TVHeadend?
apt-get -y install coreutils wget apt-transport-https lsb-release ca-certificates
wget -qO- https://doozer.io/keys/tvheadend/tvheadend/pgp | sudo apt-key add -
echo "deb https://apt.tvheadend.org/stable $(lsb_release -sc) main" | tee -a /etc/apt/sources.list.d/tvheadend.list
apt-get update
apt-get install tvheadend
ends with
Thanks and Regards,
Michael
got it installed with
apt-get -y install coreutils wget apt-transport-https lsb-release ca-certificates
wget -qO- https://doozer.io/keys/tvheadend/tvheadend/pgp | sudo apt-key add -
echo "deb http://apt.tvheadend.org/stable raspbian-stretch main" | sudo tee -a /etc/apt/sources.list.d/tvheadend.list
apt-get update
apt-get install tvheadend
TVHeadEnd.Problem: Scanning the Muxes is not working, even when I download the firmware:
cd /lib/firmware/
wget https://github.com/LibreELEC/dvb-firmware/raw/master/firmware/dvb-demod-si2168-b40-01.fw
Is there something I can do about that?! Thanks!
Regards,
Michael
Help please?
Help please?
This would probably be a good question for the tvheadend forum.
Well, it might be a driver or firmware Problem, since the device works perfectly on librelec, coreelec and omv3, so it is not a Tvheadend problem? Anyway, following someone is trying to help me inside the tvheadend Forum:
https://tvheadend.org/boards/5/topics/37295
Well, it might be a driver or firmware Problem, since the device works perfectly on librelec, coreelec and omv3, so it is not a Tvheadend problem?
I didn't say it was a tvheadend problem. I just thought you might get better help there since no one had answered you.
yes, dont worry, I did not intend to sound mean
in the TVheadend Forum they conclude that the driver is incompatible:
"driver is in kernel, but your driver is not dvbapi v5 compatible. So no information can be taken."
When I make check "dmesg |egrep "firmware|dvb|frontend|usb" " and "dvb-fe-tool && dvb-fetool -g" with the odroid n2 and coreelec (where the stick is running well), then I get different results, for example:
CoreElec on Odroid:
OMV
on rock64
Supported delivery system:
[DVBT]
FREQUENCY = 626000000
MODULATION = QAM/64
BANDWIDTH_HZ = 8000000
INVERSION = AUTO
CODE_RATE_HP = 2/3
CODE_RATE_LP = 1/2
GUARD_INTERVAL = 1/4
TRANSMISSION_MODE = 8K
HIERARCHY = NONE
DELIVERY_SYSTEM = DVBT
Alles anzeigen
That's why it doesn't scan DVB-T2 muxes....what I want to, it is not available
Is there a Debian release with newer kernel for the rock64. I would be able to install omv manually after.
Or is there a possibility to use Backport Kernel's or whatever?
Hmm, noone interessted to solve a failure / problem in Openmediavault?
- It is a OMV Problem, since the very same Hardware works on other OS-Releases
- how many people are using OMV with TVH as TV-streaming Server and recorder? I think pretty much, I use a very common chipset
Hmm, noone interessted to solve a failure / problem in Openmediavault?
I guess most people don't use tvheadend on arm boards.
It is a OMV Problem, since the very same Hardware works on other OS-Releases
No, it isn't an OMV problem. It is an Armbian issue. You would have this problem with an Armbian Stretch image without OMV.
how many people are using OMV with TVH as TV-streaming Server and recorder? I think pretty much, I use a very common chipset
Much less than in the past. And as I mentioned, you are the first I have seen try to use it on an arm board.
thought many would use it, as many used raspberry and the rock64 is an raspberry with good lan
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!