While I was working on a Linksys e6450 with the KoD issue, I decided to update my Raspberry Pi Travel router that uses OpenWRT. I was looking at some of the utility files I like to have on my builds and was going to replace wpad-basic-mbedtls with just full wpad. I lost my WLAN/wifi connection to my home network in the process. I had just installed openssh-sftp-server so I can move files to it via my LAN/ethernet port on the Pi..
Is there any way to manually reinstall wpad-basic-mbedtls (or at this point just install full wpad) without being able to update the package lists?
Yes, that's always a possibility, if only slightly inconvenient because you may need to do a bit of back-and-forth for the package dependencies.
Download the package(s) to your local machine, transfer them to the device's /tmp via SCP, install them via console with opkg install /tmp/<package_filename.ipk>. If it's missing any dependencies it will tell you right there, then you do the same dance for the dependency packages.
Alternatively, if it's a squashfs image, you can delete the placeholder files in /overlay/upper that serve as deletion entries for the filesystem. They show up as magenta under ls --color.
Once deleted, the files in /rom will once again appear in the overlayfs at /.
Thanks, Takimata
I have no doubt this would work... but I'm caught in one of those "chicken or the egg" conundrums. On these travel routers based on a raspberry pi, the onboard wifi becomes the WLAN and provides the user connection outside the local connections. Locally I can get both a USB wifi and the onboard ethernet connection. Right now, neither of the wifi connections work because there is no wpad to authenticate (both show "wireless not associated" I can talk to the OpenWRT instance on the RPi via the ethernet port either via LuCi or SSH. I have attempted to place the wpad file in the /tmp directory, but without some level or sftp in place (openssh-sftp-server) I can't get a filezilla or winscp connection. I played around with my debian laptop but still cannot get a working scp transfer? Is that also dependant on sftp being present. I don't know, I'm still not WELL versed in linux. I thought with the RPi being loaded from a microSD I could do the file transport that way... but again, I got skunked... may be possible, but I haven't figured it out.
OpenWrt's default dropbear supports SCP. Just use WinSCP to connect to the device with the same host, the same port, and the same credentials as your SSH connection.
No. Although somewhat distantly related, SCP is not the same as SFTP, that's why in WinSCP you have a dropdown to choose between them.
Cthulhu88, Thanks for the reply. Yes, both the install and the sysupgrade versions on the "Table of Hardware" show as SquashFS downloads. However I show six sub directories under "overlay/upper" and none of those show as Magenta (either under windows ssh or debian terminal). I checked each sub directory and no magenta files their either. I'm tempted to just rebuild... but the auto VPN whil on a remote connection was a real pain. It may come to that if I can't figure out which files to delete. Any ideas if the colors don't present appropriately?
You are right... I wasn't paying attention. For some reason, WinSCP starts in sftp mode. Choose the right mode and it connects. But it doesn't like the files you pointed to.
root@Travel_Pi:/tmp# opkg install /tmp/wpad-basic-mbedtls_2023-09-08-e5ccbfc6-8_aarch64_cortex-a53.ipk
Unknown package 'wpad-basic-mbedtls'.
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for wpad-basic-mbedtls found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package wpad-basic-mbedtls.
After I saw that I thought the RPi 4b was a Broadcom BCM2711... which is a Cortex-A72? Now I need to dig a bit deeper because the Cortex-A72 files also error with "incompatible with the architectures configured".
Yes, it is. I misread your initial post and gave the package directory for the Linksys e6450. (Which coincidentally, but not excusing my mistake, is the same as for some RPis, the version of which you initially did not mention.)
I'm trying get where you are going but I really don't understand what you are driving towards. I want to, I just don't get it yet. Can you explain it a bit more in depth? Here is what I see, but what do I do? There is no magenta data. Tried using cmd, powershell or a debian terminal.
My fault, I should have left that part out, but I was doing two things at once and clicked on the wrong screen.
Anyway, we know it's not 53. I thought the RPi 4 was a BCM-2711 which the specs I found say is Cortex-A72. But that says it is the wrong architecture? Do you (or anyone) know which package list I should pull from?
To see which files a package includes (and which ones you need to delete from /overlay/upper), go to /rom/usr/lib/opkg/info and view the *.list file of those packages.
In your screenshot above, these are the list files you need to go through and delete the mentioned files from /overlay/upper:
#!/bin/sh
for list in "wpad-basic-mbedtls.list ucode-mod-uloop.list ucode-mod-rtnl.list ucode-mod-nl80211.list"; do
cat "/rom/usr/lib/opkg/info/$list" | while read -r entry; do
rm -f "/overlay/upper$entry"
done
done
The color magenta applies to device entries, not normal files or directories. These deletion entries are character "devices". The terminal displaying them as magenta depends on your ls using --color automatically (if you don't pass it yourself) and the terminal software in question (PuTTY shows them as magenta by default).
The advice to remove the delete markers from /overlay/upper is complicated...
You do not actually need to edit the package management related entries (like .list files), but instead the actual executable binaries and scripts etc. (wpad, hostapd, wpa_supplicant, ...)
Based on screenshot, at least everything in /usr/share, /usr/sbin and /usr/lib/ucode
(More normal than removing delete markers, would be to copy the same files from /rom. Eg. From /rom/usr/share to /usr/share. Then you avoid manipulating overlayfs internals.)
Easiest would be to install the correct .ipk with opkg.
As dependencies are not automatically removed, you likely have all dependencies intact.
I didn't say to edit the list files, I mentioned looking at the files referenced by them to figure out what to delete, in fact, the script above does exactly that.
Copying from /rom to /overlay/upper is bad. It creates a new copy of the file, wasting disk space (this is a lot worse on models with limited disk space). Also, there is really no difference from copying and removing the entries other than the command and path.
Finding those entries are a lot easier too, because they are special and can be specified to other tools, such as find.
Sorry for the delayed response... but since I got in this predicament by not having a valid backup (stupid), I decided not to proceed until I had a valid backup of what I still have and with the nature of the RPi I can make a couple of duplicate microSD cards before I jump back on this. Looks like both directions have merit and I am trying to learn more... so I'll probably attempt both methods once I have the microSDs later this week.
You do not need a backup for deleting the deletion entries from /overlay/upper. The result of the / overlayfs partition is the combination of the /rom (squashfs) partition and the /overlay (jffs2) partition, with /overlay/upper overriding any files in / that also exist in /rom.
Deleting those entries mean the overlayfs partition will go back to referencing the original /rom files, which is akin to a partial factory reset (only for those files).
You can however make the script extra safe by checking if files exist and what kind of file they are (comments added to explain what it's doing).
#!/bin/sh
# opkg list files; reference path(s) for file(s) contained within packages
LISTS="wpad-basic-mbedtls.list ucode-mod-uloop.list ucode-mod-rtnl.list ucode-mod-nl80211.list"
# read every list file defined above
for list in "$LISTS"; do
# combine the rom opkg's path with the list's filename
list="/rom/usr/lib/opkg/info/$list"
# check if list is a regular file, is readable and has a nonzero size
if [ -f "$list" -a -r "$list" -a -s "$list" ]; then
# go through every line (file) referenced in the list file
cat "$list" | while read -r entry; do
# combine the /overlay/upper path with the file entry path
entry="/overlay/upper$entry"
# make sure it's a deletion entry before actually removing it
[ -c "$entry" -a ! -s "$entry" ] && rm -f "$entry"
done
fi
done
If you do rm by hand, you will know exactly which entries you will be deleting from /overlay/upper, so there is that aswell.
If you need an anecdotal example, I've done it multiple times between two routers in order to test some drivers and then revert back to the image's default drivers.
If those files were previously cached by the kernel, you will need to remount the overlayfs partition for it to take effect, which is probanly easier for you to just sync && reboot.
Once you've restored them back to default, you want to clean up the deletion entries from /overlay/upper/usr/lib/opkg/info and add the package sections back to /overlay/upper/usr/lib/opkg/status so opkg knows they're installed. If you haven't installed any packages that didn't come with the image, you can just delete /overlay/upper/usr/lib/opkg/status, otherwise just copy the relevant sections from /rom/usr/lib/opkg/status to /overlay/upper/usr/lib/opkg/status and you are done.
Sorry it went that route... I was just trying to fix and learn.
After I got some more microSD cards and a better USB writer I was able to make a backup image and a few duplicates of the current broken microSD configuration.
I wanted to try both methods and once I finally found a source fileset (there was a mix of (arm-cortex-a7-neon-vfpv4 and aarch64_cortex-a72) files that were needed I was able to get the "incompatible with the architectures configured" to go away and recovered the build. Thank you!!
Roberto, I wanted to give your method a try too. I used one of the duplicates but wasn't able to get squashfs to recover the files... You seem to understand what you are talking about and I'm sure it should work but I tried 2 times more but couldn't get it to work. I'm either misunderstanding or didn't remove the correct entries or both. But, I have a few other RPi 4s and will write a few more duplicates of the broken image so I can work on them. Thank you, seriously!
I may revisit this after my trip.
Could you expound on this a bit more? I do want to make Roberto's method work, but I'm missing a concept.
For now I have a working RPi travel router based on OpenWRT with onboard VPN.
Both me and @Cthulhu88 are refering to the typical OpenWrt filesystem usage in OpenWrt, where you have the flashed firmware image's files in /rom as read-only, and then all your modifications in a read-write partition as /overlay, and the overlayfs combines them into the final filesystem in a running system, like @Cthulhu88 explained in
In that scenario, the original files stay in /rom and "deletion" is just adding a 0-byte marker file into /overlay. Original file can be accessed in /rom, and copied from there like I suggested, or the deletion marker could be removed like @Cthulhu88 suggested (and the router rebooted just in case).
Note that copying a file from /rom creates another copy of the file (wasting flash, bad if that that is scarce) but is simple. Manipulation of the delete marker would be more neat, but can be tricky like the discussion above about kernel caching implies. Personally I have usually went by the copy route, as there has been enough free flash and it is simple.
That ROM+overlay filesystem strategy is used with most traditional routers with permanent flash. But I am not sure how the exact filesystem usage goes with your SDcard based router.
We have not seen the exact directory contents and what exact commands you are trying, so really hard to guess why it has not worked for you.
