• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

file_md5sum_alloc: Failed to open file /mod/webif/html/favicon.ico: No such file or directory

C

Code is a Hole

Member
Due to some system failures over recent months, scheduled recordings not having taken place, or the Humax HDR Fox T2 entering a read-only state due to file system corruption, I have begun a new strategy of running maintenance mode during Saturday, thankfully there are fewer and fewer cases of [ Multiply-claimed block(s) in inode ] and other errors that can be highlighted when running [ fixdisk ] in maintenance mode

There have been other issues that seem to be fixed when a [ fix-flash-packages ] is performed from the [ Diagnostic ] page, though there was one area of concern

- - - - -
SMART: (PASSED)
startstop: 8808 realloc: 0 hours: 27661 spinretry: 0 pending: 0 offline: 0
Queue database is up-to-date.
Configuring webif.
Collected errors:
* file_md5sum_alloc: Failed to open file /mod/webif/html/favicon.ico: No such file or directory.
- - - - -

On seeing the above [ No such file or directory ] error, an FTP session was opened, logging in as root so as to see the entire filesystem, lo and behold, there is the file in the directory that is supposed to be missing

Concerned this is major, a search revealed a possible cause, which did not match my own configuration, my [ Webif ] is still fully accessible and functional

The same process was performed on my other units

Restart in maintenance mode
Delete epg data
Run fixdisk with option '-d'
Restart and perform a [ fix-flash-packages ]

All show the same collected errors
 
This message occurs for everyone and is nothing to worry about.

It would be nice if it could be eliminated but I don't think anyone has tried to work out how to avoid it.
 
This might help:
Code: 
# opkg files webif | grep favicon.ico
/mod/webif/html/img/fav/favicon.ico
/mod/webif/html/img/favicon.ico
/mod/webif/html/favicon.ico
# cat webif_1.4.8-9_mipsel/CONTROL/conffiles 
webif/html/css/EXTRA.css
webif/html/favicon.ico
webif/html/img/fav/57.png
webif/html/img/fav/72.png
webif/html/img/fav/114.png
webif/html/img/fav/144.png
#  find webif_1.4.8-9_mipsel/webif/html -name 'favicon.ico' -exec ls -l {} \;
-rw-r--r-- 1 root root 894 May 16  2011 webif_1.4.8-9_mipsel/webif/html/img/favicon.ico
-rw------- 1 root root 10307 Jun 24  2013 webif_1.4.8-9_mipsel/webif/html/img/fav/favicon.ico
lrwxrwxrwx 1 root root 19 Sep  5 15:07 webif_1.4.8-9_mipsel/webif/html/favicon.ico -> img/fav/favicon.ico
#
The problem file is a symbolic link that seems to confuse the venerable version of opkg used in the CF.

In this case, the age of the opkg version may not be the problem. Surely opkg is trying to resolve the relative symlink .../html/favicon.ico -> img/fav/favicon.ico from the wrong working directory: the symlink expects to be used from its own directory, but opkg won't be running there, and so won't be able to find the destination file.
 
/df said:
Surely opkg is trying to resolve the relative symlink .../html/favicon.ico -> img/fav/favicon.ico from the wrong working directory: the symlink expects to be used from its own directory, but opkg won't be running there, and so won't be able to find the destination file.
Click to expand...
If that's true, then why does index.shtml -> index.html not cause a similar problem?
So perhaps it isn't true.
 
My hypothesis (which is mine), derives from Holmesian principles given that failing to fopen(filename, 'r') must mean filename can't be opened. Unlike any other symlinks in the package, ../html/favicon.ico -> img/fav/favicon.ico is listed in conffiles.

I hypothesise (this is just laziness as one could check the source) that opkg calls the file verifier only for files listed as conffiles, to determine if the installed file is different from the package file: these are files that the package believes the user might wish to modify and to not be overwritten on update, which is avoided by installing the package file as filename-opkg if the installed file differs.
 
Last edited:
/df said:
My hypothesis (which is mine), derives from Holmesian principles given that failing to fopen(filename, 'r') must mean filename can't be opened. Unlike any other symlinks in the package, .../html/favicon.ico -> img/fav/favicon.ico is listed in conffiles.

I hypothesise (this is just laziness as one could check the source) that opkg calls the file verifier only for files listed as conffiles, to determine if the installed file is different from the package file: these are files that the package believes the user might wish to modify and to not be overwritten on update, which is avoided by installing the package file as filename-opkg if the installed file differs.
Click to expand...
So should symlinks be included in confiles?
Or does opkg need to check whether a symlink has been replaced with a real file?
 
/df said:
# opkg files webif | grep favicon.ico
/mod/webif/html/img/fav/favicon.ico
/mod/webif/html/img/favicon.ico
/mod/webif/html/favicon.ico

# cat webif_1.4.8-9_mipsel/CONTROL/conffiles
webif/html/css/EXTRA.css
webif/html/favicon.ico
webif/html/img/fav/57.png
webif/html/img/fav/72.png
webif/html/img/fav/114.png
webif/html/img/fav/144.png

# find webif_1.4.8-9_mipsel/webif/html -name 'favicon.ico' -exec ls -l {} \;
-rw-r--r-- 1 root root 894 May 16 2011 webif_1.4.8-9_mipsel/webif/html/img/favicon.ico
-rw------- 1 root root 10307 Jun 24 2013 webif_1.4.8-9_mipsel/webif/html/img/fav/favicon.ico
lrwxrwxrwx 1 root root 19 Sep 5 15:07 webif_1.4.8-9_mipsel/webif/html/favicon.ico -> img/fav/favicon.ico #
Click to expand...
I have tried each of the cli commands, here is the output

Humax# opkg files webif | grep favicon.ico
/mod/webif/html/img/fav/favicon.ico
/mod/webif/html/img/favicon.ico
/mod/webif/html/favicon.ico

Humax# cat webif_1.4.8-9_mipsel/CONTROL/conffiles
cat: can't open 'webif_1.4.8-9_mipsel/CONTROL/conffiles': No such file or directory

So I ran

Humax# opkg info webif
Package: webif
Version: 1.4.8-8
Depends: tcpfix, webif-channelicons (>= 1.1.27), lighttpd (>= 1.4.39-1), jim (>= 0.79), jim-pack (>= 0.79), jim-oo (>= 0.77), jim-sqlite3 (>= 0.77), jim-cgi (>= 0.7-2), jim-binary (>= 0.76), service-control (>= 2.3), busybox (>= 1.20.2-1), lsof (>= 4.87), epg (>= 1.2.8), hmt (>= 2.0.10), ssmtp, cron-daemon (>= 1.18.3-3), at (>= 3.1.18), anacron, trm (>= 1.1), openssl-command, nicesplice, id3v2, file, rsvsync (>= 1.1.13), webif-charts (>= 1.2-1), stripts (>= 1.4.2), tmenu (>= 1.21-2), ffmpeg (>= 2.8), id3v2, multienv (>= 1.6), tcpping (>= 1.1), e2fsprogs, wireless-tools (>= 29-1), dbupdate, recmon (>= 2.0.7), hwctl, nugget (>= 0.98), sqlite3 (>= 3.15.1), jim-xconv, zip (>= 3.0-1), wget
Provides:
Status: install user installed
Section: web
Architecture: mipsel
Maintainer: af123@hpkg.tv
MD5Sum: 761e18cc7ba8f3a999b321fdbbdcb286
Size: 2921742
Filename: webif_1.4.8-8_mipsel.opk
Conffiles:
/mod/webif/html/css/EXTRA.css
/mod/webif/html/favicon.ico
/mod/webif/html/img/fav/57.png
/mod/webif/html/img/fav/72.png
/mod/webif/html/img/fav/114.png
/mod/webif/html/img/fav/144.png
Description: An evolving web interface for the Humax.
Installed-Time: 1599299585

Humax# find webif_1.4.8-8_mipsel/webif/html -name 'favicon.ico' -exec ls -l {} \;
find: webif_1.4.8-8_mipsel/webif/html: No such file or directory

The version had to be changed from webif_1.4.8-9_mipsel to the version installed on my Humax webif_1.4.8-8_mipsel

My Humax HDR Fox T2 is set to keep installed packages up to date, is webif_1.4.8-9_mipsel a beta release
 
@Andrea, thanks, as @EP confirms, you have the mainline WebIf, whereas I'm looking at the beta version (which I downloaded and unpacked). This just shows that the status of this long-standing nit hasn't changed recently.
MymsMan said:
So should symlinks be included in confiles?
Click to expand...
I have trouble understanding why one would want that.
Or does opkg need to check whether a symlink has been replaced with a real file?
Click to expand...
If one did want it, then opkg should be checking whether the symlink as a file has changed, rather than whether its target has changed. Maybe current versions do that? -- no.

Without knowing why webif/html/favicon.ico is included as a symlink (historical?), I would suggest that this change might be effective when preparing version 1.4.8-10:
Code: 
--- webif/CONTROL/conffiles-1.4.8-9
+++ webif/CONTROL/conffiles-1.4.8-10
@@ -1,4 +1,4 @@
 webif/html/css/EXTRA.css
-webif/html/favicon.ico
+webif/html/img/fav/favicon.ico
 webif/html/img/fav/57.png
Or the file in webif/html/img/fav could be put in webif/html and replaced by a symlink to the moved file, without changing conffiles.

Whether either of these resolutions is satisfactory would depend on why webif/html/favicon.ico was included as a symlink, or indeed why any of these fav icons are included.
 
Last edited:
/df said:
indeed why any of these fav icons are included.
Click to expand...
I can understand why you might want to change favicom
Those with multiple humaxes might want to give each a unique icon to prevent confusion and ease identification
or you might just prefer something different
 
So, assuming the icon /mod/webif/html/img/fav/favicon.ico is not to be changed, the user requirement is this:
Let /mod/webif/html/favicon.ico default to the icon /mod/webif/html/img/fav/favicon.ico, but allow it to be customised and not overwritten by package updates.
Click to expand...
With any opkg from the CF version to the current one (see the linked repo code above), a solution is to ship two copies of the icon, one in each directory, leaving webif/html/favicon.ico in conffiles.

Or, if the requirement is:
Allow /mod/webif/html/favicon.ico to be customised and not overwritten by package updates, and let /mod/webif/html/img/fav/favicon.ico track its synonym two levels up.
Click to expand...
then make webif/html/img/fav/favicon.ico a symlink.

It looks as if the other files in /mod/webif/html/img/fav are for the iPhone interface.
 
Thank you for all the replies

I've had another look at the [ fix-flash-packages ] output text and spotted this

- - - - -
Re-installing newk
Removing package newk from root...
Not deleting modified conffile /mod/boot/newk.conf.
Installing newk (1.0.5-1) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/newk_1.0.5-1_mipsel.opk.
Configuring newk.
Collected errors:
* resolve_conffiles: Existing conffile /mod/boot/newk.conf is different from the conffile in the new package. The new conffile will be placed at /mod/boot/newk.conf-opkg.
- - - - -

I have a custom list of newk items, in addition to the remove 'New:' and remove 'New_'

It appears this bit of the process handles files that have been modified from those being reinstalled
 
My guess is that the Apple support was added at a later date and when it became necessary (why?) to add multiple sized icons it was decided to move them all into a new fav folder but to replace the old favicon file with a link instead of updating header.jim with the new location in case some one had already customised it,
The intent was probably that users could either update webif/html/favicon.ico or webif/html/img/fav/favicon.ico and the effect would be the same

In practice it doesn't work as intended
If you modify webif/html/img/fav/favicon.ico it is recognized as changed confile on package remove but not on install and is overwritten on install because it doesn't have its own confiles entry
Code: 
 # opkg --force-reinstall install webif
Removing package webif from root...
Not deleting modified conffile /mod/webif/html/favicon.ico.
Not deleting modified conffile /mod/webif/html/css/EXTRA.css.
Installing webif (1.4.8-9) to root...
Downloading http://hpkg.tv/hdrfoxt2/beta/webif_1.4.8-9_mipsel.opk.
Configuring webif.
SMART: (PASSED)
startstop: 14910 realloc: 0 hours: 42040 spinretry: 0 pending: 0 offline: 0
Queue database is up-to-date.
Collected errors:
* file_md5sum_alloc: Failed to open file /mod/webif/html/favicon.ico: No such file or directory.
* resolve_conffiles: Existing conffile /mod/webif/html/css/EXTRA.css is different from the conffile in the new package. The new conffile will be placed at /mod/webif/html/css/EXTRA.css-opkg.

If you modify webif/html/img/fav/favicon.ico it is recognized as changed confile on package remove and on install and is retained on install
Code: 
 # opkg --force-reinstall install webif
Removing package webif from root...
Not deleting modified conffile /mod/webif/html/favicon.ico.
Not deleting modified conffile /mod/webif/html/css/EXTRA.css.
Installing webif (1.4.8-9) to root...
Downloading http://hpkg.tv/hdrfoxt2/beta/webif_1.4.8-9_mipsel.opk.
Configuring webif.
SMART: (PASSED)
startstop: 14910 realloc: 0 hours: 42040 spinretry: 0 pending: 0 offline: 0
Queue database is up-to-date.
Collected errors:
* resolve_conffiles: Existing conffile /mod/webif/html/css/EXTRA.css is different from the conffile in the new package. The new conffile will be placed at /mod/webif/html/css/EXTRA.css-opkg.
* resolve_conffiles: Existing conffile /mod/webif/html/favicon.ico is different from the conffile in the new package. The new conffile will be placed at /mod/webif/html/favicon.ico-opkg.
As far as I can see the only use of /mod/webif/html/img/fav/favicon.ico is as the symlink target, there are no other uses that I could find

So my conclusion is that webif/html/img/fav/favicon.ico should be moved to webif/html/favicon.ico with no symlinks pointing back to it
Also we should delete unreferenced (AFAIK) file webif/html/img/favicon.ico (on my system this contains 1599398190020.png)
That way we wont have the confusion of multiple favicon.ico files and should solve the file not found problem

I will put that into a git pull request https://git.hpkg.tv/hummypkg/webif/pulls/17
 
Last edited:
Black Hole said:
Maybe because some of us use iPads and iPhones, including AF?
Click to expand...
The why was not questioning the need to support iphones but rhetorically asking why it was necessary to create multiple sized icon files,
It make customizing the icon much harder if you want to do it on your ipad.

We don't supply multiple sizes for other browsers - and it appears apple also allow a single file that the OS can scale as needed https://stackoverflow.com/questions/5110776/apple-touch-icon-for-websites however since I don't have an iPhone and it isn't broken I don't intend to change anything related to the apple support.
 
MymsMan said:
I can understand why you might want to change favicom
Those with multiple humaxes might want to give each a unique icon to prevent confusion and ease identification
or you might just prefer something different
Click to expand...
I have different favicons to identify different humaxes. However, I have little artistic ability, so my second humax just has a red 2 cludged in one corner. It is ok on a PC screen, but difficult to differentiate on android. Anyone got any nice ones to share?
 
So, to avoid the trivial but irritating diagnostic file_md5sum_alloc that we must all have seen, should the symlink be reversed?

webif/html/img/fav/favicon.ico -> ../../favicon.ico

Then webif/html/img/fav/favicon.ico is a symlink and not a conf-file, while webif/html/favicon.ico is an actual file and a conf-file that opkg will be able to verify against the package version.

Or if webif/html/img/fav/favicon.ico has a separate purpose, make webif/html/favicon.ico in the package a copy rather than a symlink.
 
You must log in or register to reply here.
Back
Top