Oz 3.5.3 Bug List

[Psycona]

A mighty, showstopping, life-destroying problem:

SL-5500/Collie
3.5.3
Opie
All upgrades as at April 27.
________________________________
DESCRIPTION OF THE BUG(s) :
(bugtracker where bug is reported and bugnumber)

I haven't reported it yet, as I can't seem to get into the OE bugtracker at the moment.

Some time after flashing with 3.5.3, between an hour or most of a week, `ln -s` will suddenly stop working properly, preventing manual commands or ipkg-link from working. If using opie-packagemanager, ipkg-link seems to be called with `mount`, thereby destroying all packages on that media, ram or SD. installations to root will also fail.

Details: `ln -s` will create a link to itself. Example (edited for legibility):
  $ ln -s /media/card/etc/rsyncd.conf /etc/rsyncd.conf
  $ ls -l /etc/rsyncd.conf
  $ /etc/rsyncd.conf -> /etc/rsyncd.conf

Also, ipkg-install -dest root <package> will result in all files in <package> being replaced with symlinks to themselves. Thereby rendering them useless.

This will start occuring with any usage of `ln` or `ipkg-link` at a random time,  without any rhyme or reason that I can determine and without ever reverting to correct behaviour.

________________________________
SOLUTION (if found) :

No idea. Help!

Suggestion: Is it possible to make opie-advancedfm show symlinks that don't point to a valid destination? At the moment, messing around with the command line (although faster and easier for me anyway) is the only way to find redundant symlinks that may be upsetting ipkg-link or explaining program failures.

[Psycona]

A mighty, showstopping, life-destroying problem:

More information! Part way to a solution!

It's opie-embeddedkonsole.

I was just, half an hour after posting the report, carefully installing a couple of packages so that my Zaurus would still be useful for the two or three tasks I absolutely have to have it for. I don't like opie-console, so I always use opie-embeddedkonsole instead.

So I installed it, and IMMEDIATELY, I lost all packges installed to /media/ram. I checked /opt/QtPalmtop/bin as the easiest confirmation, and sure enough all links to files on /media/ram had been replaced by symlinks to themselves.

I uninstalled opie-embeddedkonsole, rebooted, and presto, ipkg-link restored all packages on /media/ram again. This is the first time I have been able to restore `ln` functionality, after having to reflash 4, maybe 5, times.

I have, however, absolutely no idea why. Or why it took up to a week on previous occasions.

[Psycona]

More information! Part way to a solution!

It's opie-embeddedkonsole.

I was just, half an hour after posting the report, carefully installing a couple of packages so that my Zaurus would still be useful for the two or three tasks I absolutely have to have it for. I don't like opie-console, so I always use opie-embeddedkonsole instead.

So I installed it, and IMMEDIATELY, I lost all packges installed to /media/ram. I checked /opt/QtPalmtop/bin as the easiest confirmation, and sure enough all links to files on /media/ram had been replaced by symlinks to themselves.

I uninstalled opie-embeddedkonsole, rebooted, and presto, ipkg-link restored all packages on /media/ram again. This is the first time I have been able to restore `ln` functionality, after having to reflash 4, maybe 5, times.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=77818\"][{POST_SNAPBACK}][/a][/div]

No, sorry, that's still wrong.

It was pure coincidence that it was opie-embeddedkonsole that caused the problem. I have since discovered more information, including this other symptom:

During ipkg operations, $DESTINATION/usr/lib/ipkg/status is copied to status.tmp, changes written to status.tmp, then status.tmp copied to status and deleted. When `ln` stops working properly, status.tmp remains, and status is not modified.

Doing it manually, `mv` returns a 'no such file or directory' error message, but `cp` and `rm` will still work. This suggests a file system or libc error to me.

So, at the moment, after doing a considerable amount of package removal and (re)installation, to configure things to my liking, I can uninstall multiple packages at once safely, but can only install packages individually. After each installation, I then need to check $DESTINATION/usr/lib/ipkg/status before proceeding with anything else. If there is an error, I need to cp/rm status.tmp to status, then *immediately* reboot, clean up by deleting and reinstalling the package I was working on, and check that before doing anything else. This will prevent permanent `ln`/`mv` errors.

[lardman]

ln is provided by busybox iirc.

Have you tried to upgrade or installed busybox to a storage card?


Si

[Psycona]

ln is provided by busybox iirc.

Have you tried to upgrade or installed busybox to a storage card?


Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78001\"][{POST_SNAPBACK}][/a][/div]

You do recall correctly.

I haven't tried to upgrade busybox, not having seen a busybox upgrade. There isn't one in the feed. I haven't tried to move it, as I firmly believe in keeping all the real fundamentals (busybox, bash, libc6, that sort of thing) installed to root, where fewer things should be able to go wrong, like symlinks no longer working.

I haven't tried to install root to SD, either, just a standard 40-24 kernel, and I flashed completely with 3.5.3 instead of using updater.sh

Do you think I should try it, or are you asking if I have?

[lardman]

I was only asking. I'm also of the belief that the essentials should be left on root.


Si

[ztep]

Zaurus SL-C3000
2.4.20-3.5.3-snapshot-20050428
Opie
28.04.2005

Bug description: CF automounting does not work.
More information: I have show that in OpenZaurus the external CF is /dev/hdc (so the first partition is /dev/hdc1) but in /etc/fstabs there is the following lines:
...
# Compact Flash memory cards
/dev/hdb1 /media/cf auto defaults, sync, noauto 0 0
...

So, I think that it expect that the CF is /dev/hdb1, not /dev/hdc1.

I have changed /dev/hdb1 with /dev/hdc1 on /etc/fstabs and the CF is automounted in /media/cf when I insert the CF.
I have found a problem to this solution. When I reset the device the /etc/fstabs is restored, and I have to change the file another time.

[toarney]

After installing OZ 3.5.3 on an SL5500 I've noticed that sometimes, after holding the cancel key to suspend the device, holding the same key to turn it back on doesn't work. To get the device to work again, I have to do a soft reset ... and that is annoying because it resets the system time to the time of the last manually requested reboot.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

5600
2.4.18-rmk7-pxa3-embedix
Opie 3.5.3
05/05/2005

[a href=\"http://bugs.openembedded.org/show_bug.cgi?id=1]http://bugs.openembedded.org/show_bug.cgi?id=1[/url]

Same problem.

Suspend/resume using the Cancel/On/Off button seems to work for several cycles, then will shutdown and require a reset to turn back on.

Can’t say for sure, but I think it is related to how long the Cancel button is held down to initiate the suspend.

[DrHyde]

Platform: SL-C3000
Version: 3.5.3
GUI: Opie

Several bugs here, some of which are show-stoppers.

1. The date/time applet in settings has no way of choosing whether you're using proper time or crazy daylight "saving", and when I choose London for my location it doesn't just Do The Right Thing automagically.  I'm using ntp.

2. networking is nowhere near as smooth as Sharp's version. I seem to get two entries in the networking applet, one for wifi and one for wlan, and for some reason it occasionally assigns my IP address (which was got over wireless using DHCP) to a non-existent eth0.

3. battery does not charge while OZ is running.  To charge battery, I had to suspend the machine.

4. on/off button doesn't work to suspend.

5. when unsuspending, the screen comes back to life as it was before, but the machine is unresponsive.  Need to take battery cover off and hit reset to get it back.

6. after doing that and booting up again, Opie doesn't start:

Starting Opie in 5 seconds... press a key to interrupt. 
You seem to already have a /home/root/Applications directory.
Assuming it is the Opie Applications directory. Exiting.
Starting Opie....
QPaintDevice: Must construct a QApplication before a QPaintDevice

[bladerunner]

Sl-5500/Collie
3.5.3
GPE

***** WARNING REFLASH REQUIRED *****
Watch out for installing libc6 onto a SD card ( CF card also affected but not confirmed )

When "ipkg-link mount /media/card/packages" is used to link from the SD card after installing a package everything goes OK until libc6 is attempted to be linked. The rug is pulled from under the system's nose and errors concerning the shared library libc.so.6 are everywhere. "ls" no longer works and the system is badly broken.

A reflash of the system fixes it. Clearly the symlinks for libc6 have badly gone wrong.

WORKAROUND ...

Modify the sh shell script /usr/bin/ipkg-link as follows
<snip>
list () {
        filelist=""
        files=`ls -1 $LOCATION/usr/lib/ipkg/info/*.list`
        for filename in $files; do
                filename=${filename##*/}
                filename=${filename%%.list}
                if [ $filename != "libc6" ]; then
                        filelist="$filelist $filename"
                else
                        echo "*** WARNING: libc6 detected and ignored ***"
                fi
        done
}
<snip>

This workaround causes libc6 to be ignored. So far, ipkg-link mount now works OK for me.

I hope this helps someone and saves a reflash or 2.
bladerunner

A mighty, showstopping, life-destroying problem:

SL-5500/Collie
3.5.3
Opie
All upgrades as at April 27.
________________________________
DESCRIPTION OF THE BUG(s) :
(bugtracker where bug is reported and bugnumber)

I haven't reported it yet, as I can't seem to get into the OE bugtracker at the moment.

Some time after flashing with 3.5.3, between an hour or most of a week, `ln -s` will suddenly stop working properly, preventing manual commands or ipkg-link from working. If using opie-packagemanager, ipkg-link seems to be called with `mount`, thereby destroying all packages on that media, ram or SD. installations to root will also fail.

Details: `ln -s` will create a link to itself. Example (edited for legibility):
  $ ln -s /media/card/etc/rsyncd.conf /etc/rsyncd.conf
  $ ls -l /etc/rsyncd.conf
  $ /etc/rsyncd.conf -> /etc/rsyncd.conf

Also, ipkg-install -dest root <package> will result in all files in <package> being replaced with symlinks to themselves. Thereby rendering them useless.

This will start occuring with any usage of `ln` or `ipkg-link` at a random time,  without any rhyme or reason that I can determine and without ever reverting to correct behaviour.

________________________________
SOLUTION (if found) :

No idea. Help!

Suggestion: Is it possible to make opie-advancedfm show symlinks that don't point to a valid destination? At the moment, messing around with the command line (although faster and easier for me anyway) is the only way to find redundant symlinks that may be upsetting ipkg-link or explaining program failures.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=77807\"][{POST_SNAPBACK}][/a][/div]

[lardman]

Don't try to upgrade libc.

If you need to do this something is wrong (and something will go wrong as you've seen).


Si

[bladerunner]

I installed a package which for some reason required libc6 to be installed. The libc6 version on the SD card is the same as the libc6 version installed as root.

In ipkg.conf I commented out all destinations except the SD card. Is this a mistake by me ?

Anyway, I think ipkg-link should contain definesive code to prevent libc6 being linked by default. Otherwise the system becomes trashed.

bladerunner

Don't try to upgrade libc.

If you need to do this something is wrong (and something will go wrong as you've seen).


Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78713\"][{POST_SNAPBACK}][/a][/div]

[lardman]

I installed a package which for some reason required libc6 to be installed.

Everything, unless statically linked (and not many things are as they become rather large), requires libc to be installed.

In ipkg.conf I commented out all destinations except the SD card. Is this a mistake by me ?

Quite possibly - I'm not sure, but I expect ipkg looks for installed deps on the dest locations listed in ipkg.conf - if you've commented out 'root' then it won't see most of the stuff which is installed.

Anyway, I think ipkg-link should contain definesive code to prevent libc6 being linked by default. Otherwise the system becomes trashed.

I'm surprised it linked over the top - ipkg normally attempts to symlink, but fails if the file it's trying to link to already exists.


Si

[jantar]

If I insert my GPS CF card BC-307 I noticed in the kernel log file, that the system tools setserial and fuser were missing. After installing them, the serial interface of the card was correctly recognized. I think this tools should be included  in the system installation of the collie (SL5500).

[Psycona]

Interesting, but irrelevant to my case. As I stated above, I will _never_ install something as fundamental as libc6 to anything other than root, and haven't done so in this case. So I still don't know why these errors occur.

Nor have I upgraded libc6, incidentally.

Sl-5500/Collie
3.5.3
GPE

***** WARNING REFLASH REQUIRED *****
Watch out for installing libc6 onto a SD card ( CF card also affected but not confirmed )

When "ipkg-link mount /media/card/packages" is used to link from the SD card after installing a package everything goes OK until libc6 is attempted to be linked. The rug is pulled from under the system's nose and errors concerning the shared library libc.so.6 are everywhere. "ls" no longer works and the system is badly broken.

A reflash of the system fixes it. Clearly the symlinks for libc6 have badly gone wrong.


[div align=\"right\"][a href=\"index.php?act=findpost&pid=78712\"][{POST_SNAPBACK}][/a][/div]