search

freifunk-berlin / firmware

DEPRECATED: Build system for Berlin firmware. Please user the pinned falter-repos instead
https://berlin.freifunk.net
GNU General Public License v3.0
74 stars 34 forks source link

stale filehandles in /etc/config after running migration #641

Open pmelange opened 5 years ago

pmelange commented 5 years ago

There is a problem with the change uplink setup. After installing one image type (for example default) and running the wizard, there is a complete running system.

Then, after flashing (for example) tunnel-berlin, many of the files in /etc/config have stale filehandles.

:/etc/config# rm *
rm: can't remove 'alfred': Stale file handle
rm: can't remove 'batman-adv': Stale file handle
rm: can't remove 'dropbear': Stale file handle
rm: can't remove 'luci_olsr': Stale file handle
rm: can't remove 'openvpn': Stale file handle
rm: can't remove 'openvpn_recipes': Stale file handle
rm: can't remove 'profile_Freifunk': Stale file handle
rm: can't remove 'profile_altmark': Stale file handle
rm: can't remove 'profile_arig_arad': Stale file handle
rm: can't remove 'profile_arig_neot_semadar': Stale file handle
rm: can't remove 'profile_arig_tel-aviv': Stale file handle
rm: can't remove 'profile_augsburg': Stale file handle
rm: can't remove 'profile_bayreuth': Stale file handle
rm: can't remove 'profile_bergischesland': Stale file handle
rm: can't remove 'profile_berlin': Stale file handle
rm: can't remove 'profile_carbodebit': Stale file handle
rm: can't remove 'profile_cottbus': Stale file handle
rm: can't remove 'profile_demo': Stale file handle
rm: can't remove 'profile_duesseldorf': Stale file handle
rm: can't remove 'profile_erfurt': Stale file handle
rm: can't remove 'profile_evernet': Stale file handle
rm: can't remove 'profile_freiburg': Stale file handle
rm: can't remove 'profile_fuerstenwalde': Stale file handle
rm: can't remove 'profile_gadow': Stale file handle
rm: can't remove 'profile_guifibages': Stale file handle
rm: can't remove 'profile_halle': Stale file handle
rm: can't remove 'profile_hameln': Stale file handle
rm: can't remove 'profile_hannover': Stale file handle
rm: can't remove 'profile_hooge': Stale file handle
rm: can't remove 'profile_kiberpipa': Stale file handle
rm: can't remove 'profile_kyritz': Stale file handle
rm: can't remove 'profile_l59': Stale file handle
rm: can't remove 'profile_leipzig': Stale file handle
rm: can't remove 'profile_marburg': Stale file handle
rm: can't remove 'profile_oldenburg': Stale file handle
rm: can't remove 'profile_openwireless_bern': Stale file handle
rm: can't remove 'profile_piraten_dresden': Stale file handle
rm: can't remove 'profile_potsdam': Stale file handle
rm: can't remove 'profile_reihen': Stale file handle
rm: can't remove 'profile_rosbach': Stale file handle
rm: can't remove 'profile_schwarzach': Stale file handle
rm: can't remove 'profile_stuttgart': Stale file handle
rm: can't remove 'profile_tulumlibre': Stale file handle
rm: can't remove 'profile_vogtland': Stale file handle
rm: can't remove 'profile_weil': Stale file handle
rm: can't remove 'profile_weimar': Stale file handle
rm: can't remove 'profile_weinstadt': Stale file handle
rm: can't remove 'profile_wlanljubljana': Stale file handle
rm: can't remove 'rpcd': Stale file handle
rm: can't remove 'vnstat': Stale file handle

This is the major cause of issue #637 but also has potentially many other repercussions.

I have tested this on two devices from different architectures, both with the same result.

pmelange commented 5 years ago

I have tested tunnel-berlin -> default and default -> tunnel-berlin

Both have the same "Stale file handle" problem.

pmelange commented 5 years ago

I am building again locally without this line: https://github.com/freifunk-berlin/firmware-packages/blob/adf37cd41b2dd9c4cb8277502f787c5f6d5e5e26/utils/freifunk-berlin-migration/uci-defaults/freifunk-berlin-01-migration.sh#L477

pmelange commented 5 years ago

Commit https://github.com/freifunk-berlin/firmware-packages/commit/cd0e613192906b95dce11ffbeb654ca278036f8e solves this issue

SvenRoederer commented 5 years ago

I wonder, if this also happens on master? As on the upcoming Hedy-1.0.2 we do not touch e.g. profile_leipzig, but getting an error for this. I assume this also happens for other releases

pmelange commented 5 years ago

I have tested https://github.com/freifunk-berlin/firmware-packages/commit/cd0e613192906b95dce11ffbeb654ca278036f8e and this solves this issue.

pmelange commented 5 years ago

I checked to see if this was a problem in the past. So I installed 0.2.0, ran the wiz, and then upgraded to 0.3.0.

# rm profile_wlanljubljana 
rm: can't remove 'profile_wlanljubljana': Stale NFS file handle

Since this was always a problem, then my proposal is to no longer use this line in the migration script: https://github.com/freifunk-berlin/firmware-packageas/blob/adf37cd41b2dd9c4cb8277502f787c5f6d5e5e26/utils/freifunk-berlin-migration/uci-defaults/freifunk-berlin-01-migration.sh#L477

The drawback is that a few extra kb in the jffs2 filesystem is used. The impact will be seen only on the 4MB devices. And since the tunnel-berlin images don't fit on them anyway, then I think it's time to move on and do the sysupgrade the way the openwrt developers meant it to be.

pmelange commented 5 years ago

I added this commit to the for-Hedy-1.0.x branch. But I think that we should have a discussion about whether or not it is a good idea to continue this practice.

Even though there are no more error in the uci-defaults files, I still find this practice questionable. I don't know if there might still be problems with config files controlled by LuCI.

For example, /etc/config/dropbear will still have a stale file handle. If someone is security conscience and uses the web interface to restrict the dropbear settings, it won't work.

I would propose that we only delete the profile_* files from /overlay as they are only ever going to be read from. And if someone were to want to edit the files, they would do it manually, which seems to work.

I am also a proponent of never deleting files from /overlay. Maybe that is a good plan for 1.1.x since we will be dropping support for 4MB devices anyway. The need to save a few KB is small. And the biggest argument that I can think of, is that it is the way that openWrt does upgrades and restores config files.

pmelange commented 5 years ago

It would be nice to have some opinions about this. Otherwise, I will implement the version where only the profile* files are deleted from the overlay system.

SvenRoederer commented 5 years ago

I once prepared something for the profiles: https://github.com/freifunk-berlin/openwrt-luci/tree/luci/issue944 . The only thing I'm unsure: what happens when a profile is modified locally.

SvenRoederer commented 5 years ago

in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=20b23270b712ba0c22e204b1347f04b2206d7018 sysupgrade got the new option "-u" (add sysupgrade -u to skip unchanged files) this sounds also like this will address the problem we are trying to solve with the code that causes the problem. I feel we should patch sysupgrade to use "-u" be default.

pmelange commented 5 years ago

This would be fixed by https://github.com/freifunk-berlin/firmware-packages/pull/193

SvenRoederer commented 4 years ago

As we switched to OpenWrt-19.07 we have "sysupgrade -u" on board.

SvenRoederer commented 4 years ago

I feel we should patch sysupgrade to use "-u" be default.

Anyone expects problems from using "-u" by default?

Akira25 commented 4 years ago

I feel we should patch sysupgrade to use "-u" be default.

Anyone expects problems from using "-u" by default?

Did I get it right, that sysupgrade -b wouldn't include all files into a backup anymore, but only those with changes? I think we should definitely use -u by default then.

SvenRoederer commented 4 years ago

correct, sysupgrade will include all files in /etc/config by default. When using with the -u option is will remove a files, which are unchanged from /rom, from this list. -uwas added in OpenWrt-19.07, but is not the default.