Good day. Today I installed the latest updates via sudo openhabian-config on my RPI3, rebooted, but the openhab was unable to boot.I decided to perform a fresh installation. I downloaded the image, wrote it to SD. The installation lasted about an hour. After it, openhab try to reboot and again nothing
Is there a problem in updates or in rpi?
Problem is in the latest updates. RPI work fine on another distributive.
What puzzles me are the Exception stack messages this early on.
The Pi needs almost 2 seconds before it discovers the USB ports, let alone loading openHAB.
Is the other distribution running on the the same Pi installation?
Otherwise how can you tell the image you installed OH on is not corrupt?
[quote=“Max_G, post:3, topic:29354, full:true”]
What puzzles me are the Exception stack messages this early on.
The Pi needs almost 2 seconds before it discovers the USB ports, let alone loading openHAB.[/quote]
All USB ports are empty.
The img is not corrupt. I installed openhabianpi-ua-netinst-20170317-gitbd31755f-crc88a5ae46.img in April, Everything worked fine. At the beginning of the installation, RPI downloaded packages from the network, I think the problem in that packages…
@Estranged I do have the same issue. I did an upgrade of OPENHABIAN tonight. Since then RPI does not boot and shows the same exception stack?
What to do now and how can I access my config files on the sd card if I have to reinstall everything?
I dont know. I’ve had backups of my openhab2-conf folder.
OK, thanks!
There are solutions to mount the SD Card on a separate PC (preferably running Linux) and read the file-system contents from there to retrieve your config files.
You would need an SD Card reader and another working host (google some solutions on “how to read a raspberry pi sd card on windows”)
I set up a new openhabian fron scratch. After the download of all files i have the same exception stack. Did you manage to solve the issue @Estranged?
You must write to SD openhabianpi-raspbian-20170318-git9767b24-crc9616e8a1.img.xz not openhabianpi-ua-netinst-20170317-gitbd31755f-crc88a5ae46.img. Releases · openhab/openhabian · GitHub
Thanks, that seems to work …
I have exactly the same today. I rebooted y running OH2 on a RPI3 and it never returned checked what was going on and see the same kernel panic that you have indicated in your photo.
I backed up my image and then rewrote the SD using the network install, watched it install and then when it did its final reboot to bring up OH2 it did the same thing.
I currently cannot work out if OH2 is the cause or if its the underlying rspbian update that interferes with the OH2 image.
I am thinking I need to try another platform while this is resolved.
Paul
Use openhabianpi-raspbian-20170318-git9767b24-crc9616e8a1.img.xz instead of openhabianpi-ua-netinst-20170317-gitbd31755f-crc88a5ae46.img.
Until I understand what update causes this, OS or OH2 I am not so keen on spending effort on getting my system back up and working for it to update and on its next reboot panic.
I am actually downloading the image you suggested currently as I am interested in what changes so early on to cause the kernal to crash. so I figured it could be a good reference system to work out whats causing the issue.
I commented out some liens in the /boot/config.txt file when I had my SD mounted in my windows machine.
Upon reboot I was able to get to the login prompt and login.
I notice that my IP address was no longer that allocated by my DHCP as a psuedo static IPv4 address instead it was getting an address from the my default pool, the MAC address has changed on eth0???
This is why I could not see the web page or ssh into the box initially.
My /boot/config.txt file looks like this before my changes
[pi3]
kernel=vmlinuz-4.4.0-1-rpi2
initramfs initrd.img-4.4.0-1-rpi2 followkernel
# enable the serial console for the installed system
#enable_uart=1
gpu_mem=16
dtparam=audio=on
I commented out the following three lines,
#kernel=vmlinuz-4.4.0-1-rpi2
#initramfs initrd.img-4.4.0-1-rpi2 followkernel
#enable_uart=1
I finally reduced it to the last line (enable_uart) being commented out and I could still boot and login at the console.
.
That line needs to remain commented out otherwise it panic’s.
Can anyone confirm what I have above works for them too?
Well I have reached the position where I now have my RPi3 able to stay on its original MAC address which means it gets the same IP address dished out from the DHCP server based on its known MAC, prior to this I was seeing the MAC address change all the time.
I looked at a post regarding the serial number changing but that was an early hardware issue and was not our problem.
I think the issue is that the kernel was not being passed or not accepting the parameter for the MAC, still not sure is this is a debian/raspbian issue or a OH2 one.
I looked at multiple options to solve and finaly settled on the one below as it will work now and in the future and corrects the MAC parameter pasing early in the boot so rectifys the issue very early on.
edit the /boot/cmdline.txt file and insert the command
smsc95xx.macaddr=00:00:00:00:00:00
where 00:00:00:00:00:00 is the actual MAC you want to be used.
I inserted it after ‘elevator=deadline’ and before 'net.ifnames=0’
Space either side… see below for an example
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline smsc95xx.macaddr=00:00:00:00:00:00 net.ifnames=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
Hope that helps others.
Paul
Hey Paul that sounds good. I set up a new system but will try to fix it on the ‘old’ sd card. Many thanks!
Hi Paul,
you’re right. I experienced the same problems of having a new MAC address on every reboot after installing the newest updates. I applied the fixes you described and everything worked as before.
Thanks for your great help
Andreas
Hello,
I experienced the same problems after upgrading to the latest version.
I tried to implement idkpmiller’s fix but my /boot folder is empty …
Any suggestions?