This repository has been archived by the owner on Feb 28, 2021. It is now read-only.
Kernel error after deployment on RPi 4 and Raspbian Buster #35
Comments
|
Exact same issue for me since I performed some updates on the Raspberry Pi yesterday. During normal boot I see messages from the kernel like your ones and after some time the WebUI is accessible. However none of my devices can be controlled or accessed. If I rerun I think especially the lines
are part of the problem. I have to note this happens on my Raspberry Pi 3 with Raspbian Stretch. |
|
Hi @andreheuer , did you reboot after running deploy.sh ? The docker log shows that the /dev/raw_uart was not detected. You should get: Without this the multimacd daemon does not start due to the missing HM_HOST_GPIO_UART. The eq3loop device does not seem to handle well that the slave device is open without the master running (multimacd): this leads to the kernel becoming unstable. |
|
Ok, my problem seems to be fixed. I used the tip in #33 (comment) and added Although now it is not clear to me whats need to be in |
|
Hi @angelnu, I did a restart and the container stucks at the same point as @m-rossi ( My last lines in On my host and in the container, I have a |
|
Hi @angelnu, As the HMIPServer did not start, I stopped the execution of the script. As you can see BR |
|
Ok, next step: I tried to load the multimacd daemon directly in the container. It terminates with the following errors. It seems that there is a problem that no "Coprocessor" is present!? |
|
@m-rossi - if you install all the pivccu it should take care of the DTD and config files. pivccu-raspberrypi is added by the pivccu and should work in all situation. I removed the instructions instucting how to manually change the DTD to avoid confusions. @andreheuer - could you please append the If this works then you can make the module to load automatically with If with fake_rf does not work it would you can still start the rfd by editing /etc/config/rfd.conf and removing the reference to the uart interface and adding the LAN adapter (I did this in the past before switching to pivccu). |
|
Hi @angelnu, thank you for your suggestions. Here is my As you can see, there is no As this did not wok, I have modified But even though, the start of the container did not went through and stopped at the same spot. Then, I did the following: I copied the As you can see in the log, In So, a bit progress, but still not reached the final goal...:-/ |
|
I think the problem is that it loads the real uart driver pl011_raw_uart
and therefore it does not use the the fake one. Please try to remove it and
check that the generic uart driver has the fake as dependency.
If this works I think it would be good to make the he selection explicit
over the config used by deploy.sh. Pivccu has a helper tool to select that
might be reused.
…On Mon, Sep 9, 2019, 23:30 andreheuer ***@***.***> wrote:
Hi @angelnu <https://github.com/angelnu>,
thank you for your suggestions. Here is my lsmod output:
***@***.***:~ $ sudo lsmod
Module Size Used by
xt_nat 16384 1
xt_tcpudp 16384 3
veth 24576 0
ipt_MASQUERADE 16384 3
nf_conntrack_netlink 40960 0
nft_counter 16384 26
nft_chain_nat_ipv4 16384 4
nf_nat_ipv4 16384 2 nft_chain_nat_ipv4,ipt_MASQUERADE
xt_addrtype 16384 2
nft_compat 20480 11
nf_tables 122880 96 nft_chain_nat_ipv4,nft_compat,nft_counter
nfnetlink 16384 4 nft_compat,nf_conntrack_netlink,nf_tables
xt_conntrack 16384 2
nf_nat 36864 2 xt_nat,nf_nat_ipv4
nf_conntrack 135168 6 xt_nat,ipt_MASQUERADE,nf_conntrack_netlink,xt_conntrack,nf_nat_ipv4,nf_nat
nf_defrag_ipv6 20480 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
br_netfilter 24576 0
bridge 135168 1 br_netfilter
overlay 106496 1
8021q 32768 0
garp 16384 1 8021q
stp 16384 2 garp,bridge
llc 16384 3 garp,bridge,stp
rtc_rx8130 20480 0
rtc_ds1307 24576 0
sg 28672 0
vc4 176128 0
drm_kms_helper 184320 1 vc4
v3d 61440 0
gpu_sched 28672 1 v3d
brcmfmac 311296 0
brcmutil 16384 1 brcmfmac
drm 442368 5 v3d,vc4,gpu_sched,drm_kms_helper
sha256_generic 20480 0
snd_soc_core 192512 1 vc4
snd_compress 20480 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
drm_panel_orientation_quirks 16384 1 drm
cfg80211 614400 1 brcmfmac
syscopyarea 16384 1 drm_kms_helper
bcm2835_v4l2 45056 0
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
bcm2835_codec 36864 0
raspberrypi_hwmon 16384 0
hwmon 16384 2 rtc_ds1307,raspberrypi_hwmon
fb_sys_fops 16384 1 drm_kms_helper
v4l2_mem2mem 24576 1 bcm2835_codec
videobuf2_dma_contig 20480 1 bcm2835_codec
bcm2835_mmal_vchiq 32768 2 bcm2835_codec,bcm2835_v4l2
snd_bcm2835 24576 1
rfkill 28672 4 cfg80211
v4l2_common 16384 1 bcm2835_v4l2
videobuf2_vmalloc 16384 1 bcm2835_v4l2
videobuf2_memops 16384 2 videobuf2_dma_contig,videobuf2_vmalloc
snd_pcm 102400 4 vc4,snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
videobuf2_v4l2 24576 3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
videobuf2_common 45056 4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
snd_timer 32768 1 snd_pcm
snd 73728 7 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
i2c_bcm2835 16384 0
videodev 200704 6 bcm2835_codec,v4l2_common,videobuf2_common,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
media 36864 2 videodev,v4l2_mem2mem
pl011_raw_uart 16384 0
vc_sm_cma 36864 1 bcm2835_mmal_vchiq
generic_raw_uart 20480 1 pl011_raw_uart
rpivid_mem 16384 0
fixed 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
eq3_char_loop 20480 0
ip_tables 24576 0
x_tables 32768 7 xt_nat,ip_tables,nft_compat,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_conntrack
ipv6 450560 47 bridge
As you can see, there is no fake_hmrf. Then, I loaded the module by sudo
modprobe fake_hmrf and validated this by sudo lsmod. After that, I have
redeployed the container (before, I deleted all volumes, the container, and
rfd.conf symlink) and redeployed the container by sudo ./deploy.sh
However, the container start still stucks at the same point as before: Starting
/etc/init.d/S11InitRFHardware. But one step further: I did not receive
any Kernel panic.
As this did not wok, I have modified /etc/config/rfd.conf as follows:
/usr/local/etc/config # cat rfd.conf
# TCP Port for XmlRpc connections
Listen Port = 32001
Log Destination = Syslog
Log Identifier = rfd
Log Level = 1
Persist Keys = 1
# PID File = /var/rfd.pid
# UDS File = /var/socket_rfd
Device Description Dir = /firmware/rftypes
Device Files Dir = /etc/config/rfd
Key File = /etc/config/keys
Address File = /etc/config/ids
Firmware Dir = /firmware
Replacemap File = /firmware/rftypes/replaceMap/rfReplaceMap.xml
Fire NACK Error Events = true
Improved Coprocessor Initialization = true
[Interface 0]
Type = HMLGW2
Name = LAN Adapter
Serial Number = JEXXXXX5
Encryption Key =
IP Address = 192.168.XXX.XXX
#[Interface 0]
#Type = CCU2
#ComPortFile = /dev/mmd_bidcos
#AccessFile = /dev/null
#ResetFile = /dev/ccu2-ic200
But even though, the start of the container did not went through and
stopped at the same spot.
Then, I did the following: I copied the entrypoint.sh to another name
removed the for-iteration in which the init scripts are called.
Obviously, the container could start. Then I "consoled" into the container
and executed the copy of the entrypoint.sh which produced the following
output:
/ # ./entrypoint-on.sh
Copying from /mnt to /usr/local/
sending incremental file list
sent 905 bytes received 22 bytes 1,854.00 bytes/sec
total size is 8,208 speedup is 8.85
Starting CCU services
Starting /etc/init.d/S00InstallAddon
Starting /etc/init.d/S00watchdog
S00watchdog - skipping
Starting /etc/init.d/S01InitHost
S01InitHost - defaults
Checking device
Detected piVCCU kernel module
Starting /etc/init.d/S02InitRTC
S02InitRTC - skipping
Starting /etc/init.d/S03InitURandom
S03InitURandom - skipping
Starting /etc/init.d/S04CheckFactoryReset
Checking for Factory Reset: not required
Starting /etc/init.d/S04CheckResizeLocalFS
S04CheckResizeLocal - skipping
Starting /etc/init.d/S05CheckBackupRestore
Checking for Backup Restore: not required
Starting /etc/init.d/S05avahi-setup.sh
Starting /etc/init.d/S06InitSystem
Initializing System: OK
Starting /etc/init.d/S07DisableHdmi
./entrypoint-off.sh: line 21: /etc/init.d/S07DisableHdmi: Permission denied
Starting /etc/init.d/S07logging
Starting logging: OK
Starting /etc/init.d/S10udev
S10udev - skipping
Starting /etc/init.d/S11InitRFHardware
Identifying Homematic RF-Hardware: BidCos-RF: none, HmIP: none, OK
Starting /etc/init.d/S12UpdateRFHardware
Updating Homematic RF-Hardware: no GPIO/USB connected RF-hardware found
Starting /etc/init.d/S13irqbalance
S13irqbalance - skipping
Starting /etc/init.d/S21rngd
S21rngd - skipping
Starting /etc/init.d/S30dbus
Starting system message bus: dbus-daemon[153]: Failed to start message bus: The pid file "/var/run/messagebus.pid" exists, if the message bus is not running, remove this file
done
Starting /etc/init.d/S31bluetooth
S31bluetooth - skipping
Starting /etc/init.d/S40network
S40network - skipping
Starting /etc/init.d/S45ifplugd
S45ifplugd - skipping
Starting /etc/init.d/S48MigrateSecuritySettings
Starting : OK
Starting /etc/init.d/S48ntp
Starting ntpd: OK
Starting /etc/init.d/S49hs485d
Preparing start of hs485d: no Hm-Wired hardware found
Starting /etc/init.d/S49xinetd
Starting xinetd: OK
Starting /etc/init.d/S50eq3configd
Starting eq3configd: OK
Starting /etc/init.d/S50lighttpd
Starting lighttpd: OK
Starting /etc/init.d/S50ssdpd
Starting ssdpd: OK
Starting /etc/init.d/S50sshd
Starting /etc/init.d/S55InitAddons
Initializing Third-Party Addons: OK
Starting /etc/init.d/S58LGWFirmwareUpdate
Starting LGWFirmwareUpdate: ...OK
Starting /etc/init.d/S59SetLGWKey
Setting LAN Gateway keys: OK
Starting /etc/init.d/S59snmpd
Starting /etc/init.d/S60hs485d
Starting hs485d: no Hm-Wired hardware found
Starting /etc/init.d/S60multimacd
Starting multimacd: .....ERROR
Starting /etc/init.d/S60openvpn
Starting /etc/init.d/S61rfd
Starting rfd:
Waiting for rfd to get ready.rfd is ready now.
Starting /etc/init.d/S62HMServer
Starting HMIPServer: (/dev/mmd_hmip) ..................................................................................................................^C
/ #
As you can see in the log, S11InitRFHardware could be started (without
any hardware as desired) and rfd could also be started. But S60multimacd
still fails. Also, the HMIPServer could not be started (I interrupted the
start after a while).
In /var/log/hmserver.log, the following error is recurring:
Sep 9 23:29:01 de.eq3.cbcs.vertx.management.VertxManager WARN [vert.x-eventloop-thread-6] SYSTEM ADVICE:
pre-conditions for deployment of LanRoutingWorker still not met - check deployment
configuration (still unfulfilled: [connector.open])
So, a bit progress, but still not reached the final goal...:-/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35?email_source=notifications&email_token=ABBTZA3IM7WVXGYEYDTADPDQI26AXA5CNFSM4IURL2QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JDHLA#issuecomment-529675180>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABBTZAYUBEIKVM6FIBCFY3DQI26AXANCNFSM4IURL2QA>
.
|
|
Hi @angelnu, I extended your deploy.sh as follows:
These lines add the fake_hmrf Kernel module as "autoload" on startup, then receives the Major & Minor Version, and last, it created the raw-uart module. During startup, the fake HMRF is discovered as HM-MOD-RPI-PCB and everything starts well. The LAN Adapter can then be registered in the settings. Also my import from a pivccu instance is working out of the box. Thank you for your support!! Maybe you can add those lines/settings to the image? I will for sure be a tester for this :-) |
|
Congratulations for getting it working!
I think it would be useful to have a HW-TYPE variable in the settings,
being the default "autodetect". Would you be be able to contribute a PR?
…On Mon, Sep 16, 2019, 11:16 PM andreheuer ***@***.***> wrote:
Hi @angelnu <https://github.com/angelnu>,
after a few days of studying the pivccu bash files and several tries, I
finally managed to get it working without any attached hardware, but a
HM-CFG-LAN adapter.
I extended your deploy.sh as follows:
1. I added a new config variable, which could also be moved into
settings file: FAKE_HMRF=1
2. Then, I added a line to load the fake_hmrf Kernel module:
if [ "0$FAKE_HMRF" -eq 1 ]; then
echo "Load Fake HMRF"
modprobe -a fake_hmrf || true
echo fake_hmrf>/etc/modules-load.d/fake_hmrf.conf || true
echo "Create /dev/raw-uart fake HMRF..."
UART_MAJOR=`cat /sys/devices/virtual/fake-hmrf/fake-hmrf/dev | cut -d: -f1`
UART_MINOR=`cat /sys/devices/virtual/fake-hmrf/fake-hmrf/dev | cut -d: -f2`
mknod -m 666 /dev/raw-uart c $UART_MAJOR $UART_MINOR
fi
These lines add the fake_hmrf Kernel module as "autoload" on startup, then
receives the Major & Minor Version, and last, it created the raw-uart
module.
During startup, the fake HMRF is discovered as HM-MOD-RPI-PCB and
everything starts well. The LAN Adapter can then be registered in the
settings.
Also my import from a pivccu instance is working out of the box.
Thank you for your support!! Maybe you can add those lines/settings to the
image? I will for sure be a tester for this :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35?email_source=notifications&email_token=ABBTZA5VEK47KYPZQAHRXLLQJ7ZS5A5CNFSM4IURL2QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62ROZY#issuecomment-531961703>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABBTZAY4ADZYJVBANZ2NSF3QJ7ZS5ANCNFSM4IURL2QA>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi @angelnu ,
first: thank you for providing this great docker image and providing regular updates!
Issue
After buying a new Raspberry Pi 4 with 4GB, I checked your image for any updates concerning the virtual devices issue and was happy to see the solution from last December by using the PivCCU Kernel extensions #23 . So I made a fresh Raspbian Lite (Buster) installation on my brand new RPi:
On Raspbian Buster:
and Docker CE 19:
My cmdline.txt and boot.txt
After starting the container:
And shortly after deploying the docker image, Kernel errors are shown on the console. Thereafter, dmesg shows the following errors:
This Kernel errors are raised during the start of the HM Server (
Starting /etc/init.d/S62HMServer,). Thereafter, the start continues:If try thereafter to open the CCU website, I´m getting a 404 error:
After this, I tried to restart the container. However, this completly crashes the RPi and I have to powercycle the RPi to get it restarted. And even then, the container will not start but crash my RPi.
My first thought was about the pivCCU Kernel extensions. But based on this post of the pivCCU developer, it is compatible with the Raspberry Pi 4.
Do you have any idea?
The text was updated successfully, but these errors were encountered: