[root@dca632 / 51°]# rpi4_eeprom.sh fetch
c1c19fd4ba380a3e3 [ <=> ] 17.52M 9.24MB/s in 1.9s
::: rpi4_eeprom.sh> download:c1c19fd4ba380a3e349791089701082cb51da39d[ok:0]
[root@dca632 / 52°]# rpi-eeprom-update
BOOTLOADER: [up-to-date] stable rpi4-rev1.1
CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)
VL805: [dedicated-EEPROM] [up-to-date] CURRENT:000138a1 LATEST:000138a1
[root@dca632 / 52°]# vcgencmd version
Aug 19 2021 12:27:01
Copyright (c) 2012 Broadcom
version ef2c018dccdeb94b0376db62a2ea4c882f9b500d (clean) (release) (start)
nope it's updated fine...
- looks like you might have been removing power a little too much...? and/or
- not allowing it to initialize fully? and/or
- some other sdcard / disk issue? ( which are sometimes caused by 'custom' fancy services in the shutdown phase )
- some intermittent network issue interpreted as failure to boot? and/or
- some issue on my end yet to be determined...
Good to know, maybe it was something like vpn connection handshake failing…I am using this rpi as WireGuard gateway.
Thank your for the fast support
I have the boot logs I think in the boot folder…
https://wiki.debian.org/RaspberryPi4#Using_EFI_Firmware_and_the_regular_Debian_Installer
That is a rather neat approach, especially for more general purpose distributions (not using any RPi myself, so no personal exposure to any of this).
is it possible to change the theme in your build ?
The issues occurred again. Sadly I already did unplug/plug all USB connected to tpi but no luck there
thanks for the update
hmmmm... reboot not working
i think based on what we've tried, we are left with something related to
- power, hardware
or - additional software
as there was intermittency involved, i'm leaning towards the hardware but it's almost 50/50...
at this point, the only real option is to try 'normal OpenWrt'... given an identical software stack, my gut feelings are that the issue will persist...
autorate note
(i think you've been using or previously used the newer non-build included autorate service... it is better than the build included one which was pretty hacky and quickly whipped up as a test - actually i dont think anyone is using it and its abit old so I will probably remove it...)
there is busybox reboot -f
(we didn't try -f)... that still doesn't work we are more on the hardware side... if it works... you can disable services one by one... until you find what's causing it...
( pswww
output requested earlier was not provided - which is fine, but leaves huntng down issues in that domain entirely up to you )
wildcard theory
gotta admit, compromise has crossed my mind once or twice as well (hence the busybox shasum we did), devices not rebooting or sporadically rebooting... and you've looked at the obvious things (which is difficult especially on a hardware level on these boards)... it's probably alarmist... but definitely something worth mentioning given the symptoms...
I don't use your images, I build my own raspberry pi 4 image from master, this week almost daily, when I first boot the image, I have a:
reboot -d 90 via a uci-defaults script
but today the reboot simply disappeared, I was unable to restart via the command.
I fast-checked the logs and saw something wrong with the time, but I'm not sure, and I was able to restart via reboot -f
so that problem maybe isn't exclusive to your images
thankyou!!!
(looks like I owe malikshi a big apology probably... again)
yeah... that's a good point... and it's well worth examining them for anything obvious...
the way those work is;
- a dmesg is saved early on boot
pdmesg*
- a logread is saved periodically (appended)
plogread*
so, if you quickly reboot, you'd possibly be missing all the logread stuff which will show you the later service related stuff..
and you'd need to leave the thing running for hmmmm... not sure if I do a logread save at the end of boot or every 6 hours or something... (edit: I think a 'clean' shutdown/reboot will also do a save)
point is... you may not have the service stuff there...
but worth scanning them for the times when you thought the device didn't boot to see if anything obvious shows up...
NOTE:
- we used to keep these semi indefinately... ( 3months plus )
they were starting to impact upgrade speed for long running build users, now they are trashed over a certain size ( probably around 11 upgrades worth but its sized based so I suppose if you never reboot and you have alot of logspam it can theoretically trash/move them all)
there are two ways you can 'keep' older ones without slowing down upgrade...
- ROOTFSEXPAND_DATAPART automatically 'syncs'
/boot/plog
to your z drive... - when files are trashed... they can optionally be moved
LOGPERSIST_DATA_DRIVE="/usbstick"
LOGPERSIST_DATA_SUBDIR="_zPREMOVED"
(second parameter is optional but defaults to the above subfolder afaik)
there is also a command logreadp
that is for dumping/searching the whole persistent log/logs but it's WIP / experimental...
[root@dca632 ../_WANSWITCHER 52°] logreadp --help
logreadp #dump full current persistentlog
logreadp -a #dump all saved
logreadp -F "<string>" #fgrep all saved aka show release and date of logfiles
logreadp info
[root@dca632 ../_WANSWITCHER 52°] logreadp info
dir: /boot/plog fnum:40 tlines:58312
current: /boot/plog/plogread-202202281432-boot-5.0.103-30.log
oldest: /boot/plog/plogread-202202091324-boot-5.0.77-139.log
Hi Wulfy: how do i update the eeprom of Rpi4 while using your latest build ?
i flashed your latest firmware and the very first popup was this one to update eeprom, but i didnt find a way on how to do it...
any help from your side ?
luci > system > custom commands > rpisupport
eeprom-update
[run]
I am having another problem since I update from 5.0.11-73 to 5.0.103-12 from web interface.
WireGuard interface goes down and never recover after few hours connected, if I am using a device with vpn it stays active, in the night that all devices are in standby the WireGuard interface crashes. A reboot bring everything to normal , and yes I’m using persistent keepalive = 25.
With old firmware I was with an uptime from almost 30 days without any problem.
thanks for the report... revert to
or try 21.02.2
Can I revert using web interface? Do you have the file? Or I need to flash again the micro sd card with that version?
luci > system > custom commands > doCMD
sysupgrade -R http://rpi4.wulfy23.info/builds/devel/rpi4.64-snapshot-27339-5.0.11-76-r18531-ext4-sys.img.gz
When I press run it says
**doCMD.sh sysupgrade -R "http:"** image:http: [invalid-nofile]
But the link is working
try the [tty] link in luci... login and paste the command...
or just download the file to your pc and upload it in luci
( luci > system > flash firmware > flash image )
Download to pc and flash using web interface restored perfectly. I will give feedback tomorrow if it fixed or not.