Hi.
I tested socat years ago and removed the package after testing. But every time after the firmware upgrading, the socat package always comes back. I have to remove it manually every time.
I checked the /etc/backup/installed_packages.txt. There is nothing in it.
Is there any other files keeping the record? Thanks a lot.
Hello,
When the firmware is upgraded, custom-installed third-party plugins will be removed.
This is the current upgrade logic of GL firmware.
And you mentioned that the plug-in socat will appear again after the firmware upgrade, even if it is removed before.
May I know what router model you have? Is the GL firmware installed? When installing the firmware, did you check keep settings? I would like to reproduce it locally.
Hi bruce. Thanks for your reply.
The router is GL-MT6000. When upgrading, I use the default, not modifying anything on the upgrading wizard page. I guess “keep settings” is checked. All settings are preserved.
Hello,
I tested the plug-in locally and the issue did not reproduce.
Please let me know from which firmware version the plug-in socat was installed? I think the "keep settings" is checked always in firmware upgrading, and what firmware version is it now?
v4.8.2:
root@GL-MT6000:~# opkg list-installed | grep socat
socat - 1.7.3.4-2
Upgrade to v4.8.3, and checked "keep settings":
root@GL-MT6000:~# opkg list-installed | grep socat
root@GL-MT6000:~#
Hi.
My socat version is very same like you. I see the opkg process run in bash to install this package after the 1st boot after the firmware upgrading.
The firmware version is 4.8.3.
Do you use a usb connected device pointing to /overlay ?
This is your issue, this is normal behaviour because in linux it does what it says quite litterly overlaying the partition.
I have had this also on my Mochabin and my solution was first to make a very basic setup without the attached overlay, then when the disk was mount I actually divided into a second partition.
Everytime I wanted to upgrade I wiped this partition, just by unmounting the disk or disabling fstab and rebooting back to my basic setup, then there will no issues with transient packages or double packages and these crazy things.
I also had the same issue recently on debian mounting file containers, there I learned I could use attributes to not write on a folder when not mounted, but when the mount happen the chown owner is docker:docker because mounting overrides the perms, this way I had a fail proof design, however OpenWrt lacks this user concept because it doesn't have a proper user system, it is still possible but I won't trust on doing that especially since sysupgrade still wants write perms, when booting it will still try to run both packages which could break the boot sync with potential to soft brick, you want to be sure after upgrade no remnant package boots.
No.
I didn’t touch partition table, nor attach any devices.
But I have docker installed, which do use something based on overlay.
Sounds to me this could be your issue, although weird, I don't know a situation a docker mounting causing this kind of behaviour, I'm curious for what purpose do you run this image?, how is it mounted?
I use some docker images for mapping services, like “cloudflare/cloudflared”. All containers are not access any local volumes or paths.
In df -h, there is a overlay mounted on /opt/docker. I guess this is required by docker itself, not controlled by me.
This seem fine to me, not sure if OpenWrt changed logic of /opt, I'm aware there was a issue /opt was not present, making docker unable to start, users where required to make this themselves, but it is possible they have changed some of this logic which I'm not aware of, I remember just creating this path with mkdir.
/opt isn't overriding /overlay ?
After firmware upgrading, all files in /opt are kept correctly. And I can see that a process “opkg install” for docker and others (including socat) is running. After docker installed (automatically), docker is started without any issue.
No. The target of overlay is “/opt/docker”, not “/opt”. But there is another one mounted as /. Here is the full list of “df -h”:
/dev/root 57.0M 57.0M 0 100% /rom
tmpfs 494.7M 2.7M 492.0M 1% /tmp
/dev/loop0 7.2G 2.2G 5.0G 30% /overlay
overlayfs:/overlay 7.2G 2.2G 5.0G 30% /
tmpfs 512.0K 0 512.0K 0% /dev
overlayfs:/overlay 7.2G 2.2G 5.0G 30% /opt/docker
This is unusual for me, but i'd guess OpenWrt does this, I wonder what happen if you stop docker, umount /opt/docker and then do the sysupgrade?
I doubt the issue is a dependency problem like how I described this here:
But I think it is rather a case of:
Meaning sysupgrade misses the rights to wipe packages, i believe docker still uses the user docker or group in /etc/shadow so that means the rights are overridden aslong the mount is active.
I’ll try that next upgrading lol. So far, nothing is wrong with docker. Only I have to do is removing socat manually.