Since the update of usm via usm again not worked for me (sometimes it works, but most times it fails and I have not found out why) another even stranger thing now happened:
I downloaded usm from
http://sourceforge.net/projects/usm/fil ... rce=navbar , renamed the xzm to reflect the version number and activated it:
Code: Select all
rava@porteus:/mnt/live/memory/images$ file usm-3.1.9-noarch-1.xzm/
usm-3.1.9-noarch-1.xzm/: directory
Then I asked usm which version it now has, and it told me: still 3.1.7!
Code: Select all
root@porteus:/mnt# usm -v
You are using USM version: 3.1.7
Then I asked the files itself aka usm's own version.txt what version they are and this is where it gets weird:
Code: Select all
rava@porteus:/mnt/live/memory/images$ grep USMVERSION usm-3.1.9-noarch-1.xzm/etc/usm/version.txt
USMVERSION=3.1.9
rava@porteus:/mnt/live/memory/images$ grep USMVERSION /etc/usm/version.txt
USMVERSION=3.1.7
When I activate a module, the existing file, here
/etc/usm/version.txt should be "overwritten" by a same file with the fully qualified file name, in this case, /etc/usm/version.txt should be the same as
/mnt/live/memory/images/usm-3.1.9-noarch-1.xzm/etc/usm/version.txt, and both should have USMVERSION=3.1.9; but as you can see in the code above, it is not.
Why is that so? How can that happen at all?
//Update
I now checked with md5sum not only the version.txt, but also usr/bin/usm itself, and it is even more strange:
Code: Select all
rava@porteus:/mnt/live/memory/images$ md5sum USMVERSION usm-3.1.9-noarch-1.xzm/usr/bin/usm /usr/bin/usm
md5sum: USMVERSION: No such file or directory
5abb90e28f7eddf6ea7cdba9bf48d6f8 usm-3.1.9-noarch-1.xzm/usr/bin/usm
5abb90e28f7eddf6ea7cdba9bf48d6f8 /usr/bin/usm
rava@porteus:/mnt/live/memory/images$ md5sum usm-3.1.9-noarch-1.xzm/etc/usm/version.txt /etc/usm/version.txt
0492f3be27b597f5bcf566901a022d68 usm-3.1.9-noarch-1.xzm/etc/usm/version.txt
9d06a0c2811d2b89f7c5a36793d04e4a /etc/usm/version.txt
See? For some very weird reason, the version.txt in /etc was not updated by activating the usm module, but usm itself was, and I presume all other files
or at least some have been updated as well.
But why was etc/usm/version.txt omitted from being updated?
Me thinks I finally caught the reason why usm acts so weird on my system, but the question remains: How can that even be possible at all?
Here the file permissions:
Code: Select all
rava@porteus:/mnt/live/memory/images$ ls -l usm-3.1.9-noarch-1.xzm/etc/usm/version.txt /etc/usm/version.txt
-rw-r--r-- 1 root root 160 Dec 14 12:35 /etc/usm/version.txt
-rw-r--r-- 1 root root 166 Sep 25 00:26 usm-3.1.9-noarch-1.xzm/etc/usm/version.txt
I now will check if the file is immune against changes, I will update soon.
//UPDATE2
Seems, lsattr is not possible on the files in the live system:
Code: Select all
root@porteus:/mnt# lsattr /etc/usm/version.txt
lsattr: Inappropriate ioctl for device While reading flags on /etc/usm/version.txt
Then I just tried copying the version.txt from the activated module to its live system file:
Code: Select all
root@porteus:/mnt# cp /mnt/live/memory/images/usm-3.1.9-noarch-1.xzm/etc/usm/version.txt /etc/usm/version.txt
cp: overwrite ‘/etc/usm/version.txt’? y
root@porteus:/mnt# md5sum /mnt/live/memory/images/usm-3.1.9-noarch-1.xzm/etc/usm/version.txt /etc/usm/version.txt
0492f3be27b597f5bcf566901a022d68 /mnt/live/memory/images/usm-3.1.9-noarch-1.xzm/etc/usm/version.txt
0492f3be27b597f5bcf566901a022d68 /etc/usm/version.txt
root@porteus:/mnt# usm -v
You are using USM version: 3.1.9
That worked, but that is not what should be needed to do, now is it?
When I create a module for
any updated or new program, then
all files, including all setup files need to be updated in the live system as well.
There was no usm or usmgui running while I did all that, and as you can see, as simple cp was able to replace the outdated version.txt.
But why was activate not able to do so?