Rpi4 < $(community_build)

[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)
1 Like

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…

1 Like

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).

1 Like

is it possible to change the theme in your build ?

1 Like

The issues occurred again. Sadly I already did unplug/plug all USB connected to tpi but no luck there

1 Like

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...

1 Like

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

2 Likes

thankyou!!!
(looks like I owe malikshi a big apology probably... again)

1 Like

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...

  1. ROOTFSEXPAND_DATAPART automatically 'syncs' /boot/plog to your z drive...
  2. 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
1 Like

When I press run it says

**doCMD.sh sysupgrade -R "http:"** image:http: [invalid-nofile]

But the link is working

1 Like

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.

1 Like