Ah, nuts. I did reboot after upgrading. I wanted to double-check my settings and make sure it wasn't a user error before I posted. The only thing dmesg | logread) ... is telling me now is
Wed Jan 27 15:20:20 2021 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/sqm
I don't feel the need to downgrade. I'll keep an eye on the releases & upgrade when the next becomes available.
Hi, complete newbie here.... failing at [nearly] the first hurdle.
Got up and running OK with rpi4.64-snapshot-25261-2.7.15-2-r15599-ext4-fac and logged in at 192.168.1.1 luci & ssh working on a standalone pc.
First thing I need to do is change LAN ip to 192.168.0.254/24 On my network I have quite a few devices with fixed ips which know this is the netmask & gateway and it would be a real hassle to have to change them all.
I managed to do a change in luci, and get it to save - however, when I now go to 192.168.0.254 the page /cgi-bin/luci/ is blank because it is returning a 403 forbidden.
So there is obviously more to changing the lan ip on this build than meets the eye.
Could someone tell me how to do it please? - Starting from a new virgin snapshot, perhaps I can get ssh working and then there's a script I can run?
Thanks
Richard
This is not a build specific issue though.
First verify that the PC you are connecting to the router got the correct IP in 192.168.0.0/24 subnet. Try to clean the browser cache, use a different browser or use private browsing mode.
Can you login with ssh using the new IP?
I already knew I could login by SSH to 192.168.0.254 fine which is what was so mysterious, but you prompted me to have another go in browser incognito mode - and bob's my uncle.
So thankyou - it was a browser caching problem - solved.
Thankyou so much
Richard
Recently I started receiving some weird errors from the RPi, which turned out to be due to rootfs mounted ro. A reboot didn't fix it, nor could I enable the fsck on boot. Eventually it was faster to plug the sd card in my pc and check the fs there.
Maybe it would make sense to enable the filesystem check on boot by default in the image?
when enabled... you'd see something like this in dmesg;
[ 6.809436] 79_move_config> fsck-bootpart:/dev/mmcblk0p1 [clean]
[ 6.555143] 80_mount_root> fsck-rootfspart:/dev/mmcblk0p2 [clean]
edit: could be years before anyone reports back... so it's done...
#on by default... only parsed->cmdline.txt at firstboot to disable user needs to comment out this line for the next upgrade and remove from their cmdline.txt
RPI4CMDLINEOPTS="fsckparts"
just pushed a usb_testing beta fw...
not for the average user (yet)...
when I last updated my official-pi-firmware ( to the usb-boot support stable release ) I set my pi-firmware-BOOT_ORDER=0xf14 ... which means try usb first...
my mmc card is hard to get to... so this is better for me... with the default boot order ( 0xf41 ) you'd have to remove (or not have an OS on) the mmc for it to try the usb...
[root@dca632 /usbstick 46°]# rpi-support.sh -b | grep -Ei '(root|boot)'
################################# root-dev: /dev/mmcblk0p2:02010729-02 boot-dev: /dev/mmcblk0p1
root@boot: PARTUUID=02010729-02
root@cmdline: PARTUUID=02010729-02
console=ttyAMA1,115200 root=PARTUUID=02010729-02 rootfstype=squashfs,ext4 rootwait fsckparts brcmfmac.debug=0x100000
boot_delay=3
BOOTORDER: usb mmc
Anyone else try to use two tp-link UE300 usb3 adapters and get stuck in some kind of weird boot loop until one is unplugged when you reboot?
seems the latest build ( 2.7.33-x ) has some statistics cpu alt confs that probably wont get migrated... ( shows per cpu info ... really nice ), may have been on earlier builds but I always migrated my config.
luci_statistics.collectd_cpu=statistics
luci_statistics.collectd_cpu.enable='1'
luci_statistics.collectd_cpu.ReportByCpu='1'
luci_statistics.collectd_cpu.ReportByState='1'
luci_statistics.collectd_cpu.ShowIdle='0'
luci_statistics.collectd_cpu.ValuesPercentage='1'
config statistics 'collectd_cpu'
option enable '1'
option ReportByCpu '1'
option ReportByState '1'
option ShowIdle '0'
option ValuesPercentage '1'
more CVE's... ( < r15599 )
https://openwrt.org/advisory/2021-02-02-1
https://openwrt.org/advisory/2021-02-02-2
wolfssl afaik only effects curl on this build... anyways... will probably pull down the repo's ( < r15599 ) within the week...
as with dnsmasq... in place updates (from offical repo) are possible, if minimal disruption is absolutely required... and you choose to stay on an 'older' build... ( pity they are not so old tho' ) used to update my router every 6-12months!
should i update to this version?
rpi-4_snapshot_2.7.15-2_r15599_extra_testing
up to you... if you have your migration stuff ( sysupgrade.conf ) all setup well... OR you think you might want to install packages... possibly...
the builds are in a little bit of limbo at the moment... due to CVE's / development+testing of usb support...
yesterday I removed the last 'stable' build... ( 2.3.656-15_r15323 ? ) due to the netifd/odhcp6c/dnsmasq/libwolfssl24 bugs... if you have this build ( or earlier 2.3 ) and patched dnsmasq then the other issues are not so 'critical' imho unless your having ppp issues... but only you can really assess how critical you deem them to be...
the current 'testing' (which is by default 'current' due to no other well tested options ) build you mention is 97% stable with just the mentioned sqm starting issues on boot mostly... this may need patching or updating soon also... ( ppp - newer masq )
despite all the warnings, the usb builds are probably 95% fine... ( but imply a user has a dd backup or knows how to edit files in case of issues... )
so the simplest answer is make sure your dnsmasq is up to date or upgrade...
I'm undecided about how to handle all this package update business... longer term... ( suppose it's to be expected tracking master... hope someone makes a 21.x-community which is more basic than this when it's released... there is definitely scope for it )
suppose i'll just keep going and see what pans out... ( potentially less build users... after 21.x ) depending on who's using it and what they need/feedback...
for my needs the 'just-flash-the-next-version' is working well...
Just tried to run the sysup-online script and am seeing a checksum issue
root@PiRouter /39# /bin/rpi-sysup-online.sh -R current
flavour:current online:2.7.15-2[newer] onsys:2.3.656-15
Downloading... current
shasum-chk-issue
Not sure if it's related to you pulling the last 'stable' build
thankyou very much for that... fix ed ing
that build is the first with 'image-signing'... when you upgrade from it... you should see a line that says 'key check ok' or similar...
as i'd added the logic post-build... forgot to adjust / regenerate the new sums...
what a new-sum they can be!
Hah, no worries. Give this a thumbs up when the checksums make sense and I'll give it another shot.
well that is unusual...
you can try again... some other points... if it does not succeed again...
rpi-sysup-online.sh -v dlonly
sysupgrade -R /tmp/rpi4.64*img.gz
is an equivalent workaround ( without the shasum check )
made minor fixes to rpi-sysup-online.sh that come down in the next upgrade ( cosmetic only )... if you wanted to refresh...
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/rpi-sysup-online.sh > /bin/rpi-sysup-online.sh
Worked first try
root@PiRouter /40# /bin/rpi-sysup-online.sh -R current
flavour:current online:2.7.15-2[newer] onsys:2.3.656-15
Downloading... current
ibbuildinformation.txt: OK
rpi4.64-snapshot-25261-2.7.15-2-r15599-ext4-sys.img.gz: OK
Thu Feb 4 22:34:07 GMT 2021 upgrade: Reading partition table from bootdisk...
Thu Feb 4 22:34:07 GMT 2021 upgrade: Reading partition table from image...
Thu Feb 4 22:34:07 GMT 2021 upgrade: AUTORESTORE [ok]
Thu Feb 4 22:34:10 GMT 2021 upgrade: Saving config files...
Thu Feb 4 22:34:11 GMT 2021 upgrade: [MULTILOGIC]v off
Thu Feb 4 22:34:11 GMT 2021 upgrade: [sync and drop_caches]
Thu Feb 4 22:34:11 GMT 2021 upgrade: Commencing upgrade. Closing all shell sessions.
Connection to router.lan closed by remote host.
Connection to router.lan closed.
Many thanks. Really enjoying this build.
Edit: to note this was without pulling the updated script
anyone on that build should also probably grab this;
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/rpi4-official-opkg.sh > /bin/rpi4-official-opkg.sh; chmod +x /bin/rpi4-official-opkg.sh
it's a wrapper for official-opkg repos... and has a mitigate command... so if new official bugfixes become available you can;
rpi4-official-opkg.sh mitigate wget-ssl dnsmasq-full
etc. or search too;
rpi4-official-opkg.sh list-upgradable
#single rpi4-official-opkg.sh upgrade wpad-openssl
rpi4-official-opkg.sh mitigate wpad-openssl hostapd-common hostapd-utils wpa-cli
Smoothest update so far, haven't had to tweak a single thing.
SQM came up with no issue on first boot (using ctinfo_4layercake_rpi4.qos), seems collectd even logged data for almost the entire process.
that's the goal... and that is truly great news!!!
if your making use of ctinfo_4layercake_rpi4.qos ... as its in heavy development ( and i'm not really keeping track of versions properly )... i'd suggest you do;
cp /usr/lib/sqm/ctinfo_4layercake_rpi4.qos /usr/lib/sqm/ctinfo_4layercake_rpi4_v1.qos
echo '/usr/lib/sqm/ctinfo_4layercake_rpi4_v1.qos' >> /etc/sysupgrade.conf
that way... if the next variant has issues or you want to compare versions you can toggle back to 'v1' the next time you upgrade...
( note: it also dumps a 'qosdebug.sh' which dumps some sketchy state values )
( note2: it will likely handle voip poorly in it's current state... i'm not running voip at the moment... so unable to test much or tweak ... but if you add a voip device into the RPI4QOS_GAMING_MACS="11:33" in wrt.ini it should bump it up a little in the short term )