tinycore_v2.11rc2

[jur]

To make upgrading from previous versions smoother, may I suggest /.X.d also be included in xsetup if it does not exist?

[meanpt]

Hi,

1. installed applications are not shown under the Applications heading menu
2. midori did not installed correctly, despite the icon being shown in the dock
3. shiretoko installed on the third attempt
4. Vboxadditions is not working - when trying file sharing with the Windows system with the shared vbox folder with "mount .-t vboxsf -rw windowsSystemFileFolder TCDirectory, keeps responding "No such device". Currently using VBox 3.1.4

Regards,

Mean

[roberts]

Hi,

1. installed applications are not shown under the Applications heading menu
2. midori did not installed correctly, despite the icon being shown in the dock
3. shiretoko installed on the third attempt
4. Vboxadditions is not working - when trying file sharing with the Windows system with the shared vbox folder with "mount .-t vboxsf -rw windowsSystemFileFolder TCDirectory, keeps responding "No such device". Currently using VBox 3.1.4

Regards,

Mean

What does showbootcodes display?

[maro]

As I was surprised to read

4. Vboxadditions is not working

I did a re-test with TC 2.11rc2 along the lines of what I did here and have to report that all mounting attempts appeared to have worked without an issue for me. Could it be that the required module was not loaded (with sudo modprobe vboxvfs) as mentioned in the .info file?

I'm also not quite sure what is supposed to be wrong with 'midori': The installation works fine for me and the application is usable. The only (in my view entirely cosmetic) issue might be the fact that at the very first start a bit a garbled message might appear ("Error - %u    The page '%u' couldn't be loaded.    URL cannot be shown"). It appears that this happens when midori gets started via the wbar icon, and does not happen when started from the command line. A quick look into '/usr/local/tce.wbar' shows that indeed 'c: exec midori %u' appears to be the "culprit" here. I guess that OTOH might be a consequence of the 'Exec=midori %u' entry in '/usr/local/share/applications/midori.desktop'.

Likewise 'shiretoko' worked OK for my test. It's "just" fairly memory-hungry (ca. 23M downloaded extensions lead to ca. 50M extracted extensions). So running it on a system with only 128M would be pretty much pointless. But I fail to see what could be the issue re. TC 2.11rc2.

What I can confirm is the reported issue about applications not "showing up" via '~/.wmx/Applications'

I believe I've spotted one yet un-reported issue: the ownership of the files in '/home/tc/.wmx/SystemTools' is 'root:staff' even though a command in '/usr/bin/flwm_topside_initmenu' (i.e. chown tc.staff -R /home/"$USER"/.wmx) tries to change this. I guess that command might have to be moved after the loop over the files in '/usr/share/applications/tinycore-*' to have the desired effect.

[roberts]

I believe I've spotted one yet un-reported issue: the ownership of the files in '/home/tc/.wmx/SystemTools' is 'root:staff' even though a command in '/usr/bin/flwm_topside_initmenu' (i.e. chown tc.staff -R /home/"$USER"/.wmx) tries to change this. I guess that command might have to be moved after the loop over the files in '/usr/share/applications/tinycore-*' to have the desired effect.

I am curious how you are getting root.staff on System Tools.

Using base norestore the permissions are OK. In fact I now recommend, as posted in the announcement, that .xfiletool.lst contain home/tc/.wmx therefore my .wmx is recreated upon each boot. I cannot reproduce the permission issue. System Tools should have no effect on Applications. I have tested with typically home in ram (base norestore) and with persistent home on ext2 filesystem.

Have you changed .xfiletool.lst to include home/tc/.wmx ?

What happens if you exit X and
rm -rf .wmx and then startx

Check permissions.

What filesystem is hosting /home ?

For user, meanpt, I again ask to see the output of showbootcodes, as I would like to know what window manager you are using and what  persistent options if any.

[roberts]

I'm also not quite sure what is supposed to be wrong with 'midori': The installation works fine for me and the application is usable. The only (in my view entirely cosmetic) issue might be the fact that at the very first start a bit a garbled message might appear ("Error - %u    The page '%u' couldn't be loaded.    URL cannot be shown"). It appears that this happens when midori gets started via the wbar icon, and does not happen when started from the command line. A quick look into '/usr/local/tce.wbar' shows that indeed 'c: exec midori %u' appears to be the "culprit" here. I guess that OTOH might be a consequence of the 'Exec=midori %u' entry in '/usr/local/share/applications/midori.desktop'.

Yes, I will have to stip and trailing % options for wbar. I was not aware of such data, Good find. Thanks!

[maro]

Robert, the 'root:staff' appears for me when booting from the "plain" TC 2.11rc2 ISO image. I don't use any form of persistence, have no backup, and no extensions whatsoever. As I'm using TC so far more as a study object I operate most of the time in "cloud" mode. My private TCZ mirror allows me to reasonably quickly test a variety of test cases without having to consider the impact of previous activities. Most of the time I just boot a new VM (using VirtualBox or QEMU) and TC is better than any other distribution for this due to the minimalistic concept.

The ownership of 'root:staff' is also appearing after removing '~/.wmx' and a restart of X. I've even done a re-boot just with the plain ISO, and used boot codes 'base norestore' (which I guess is the same thing twice over) and the ownership of those files is again 'root:staff'.

I tend to agree that the (initial) ownership of those files is probably not critical, since I guess in the case of a persistent '/home' after the next re-boot the 'chown' command will change things to 'tc:staff'.

The way I explain the finding to myself is: In '/usr/bin/startx' the command sequence of [ `which "$DESKTOP"_initmenu` ] && sudo "$DESKTOP"_initmenu leads to the execution of '/usr/bin/flwm_topside_initmenu' in which the following code snippet can be found:
    chown tc.staff -R /home/"$USER"/.wmx
    TARGET="$SYSMENU"
    for D in `ls /usr/share/applications/tinycore-*`; do
       writeFLWMitem "$D"
    done
At the first run of this code block on a "plain" system there are no files in '~/.wmx/SystemTools' and the 'chown' command has no effect. After the loop has run the files in '~/.wmx/SystemTools' have been created, but due to the execution as super-user the files are owned by 'root'. Moving the 'chown' command after the loop should lead to the desired outcome.

[roberts]

No problem to change the code. I just like to reproduce the reported condition so to better understand the actual envirments in which it occurs.

[meanpt]

Hi,

1. installed applications are not shown under the Applications heading menu
2. midori did not installed correctly, despite the icon being shown in the dock
3. shiretoko installed on the third attempt
4. Vboxadditions is not working - when trying file sharing with the Windows system with the shared vbox folder with "mount .-t vboxsf -rw windowsSystemFileFolder TCDirectory, keeps responding "No such device". Currently using VBox 3.1.4

Regards,

Mean

What does showbootcodes display?

a) Bootcodes

Showbootcodes on terminal only displays "quiet", although during the booting I can see the "kernel /boot/bzImage quiet" and "initrd /boot/tinycore.gz" lines.

b) wm
I'm using the default wm/desktop - suppose it's flwm ...


c) Other things / Live session
During the a live session (this one, from where I'm posting) could install shiretoko which was shown on the dock but not on the Applications menu label. But if I install Xfe.tcz, the later is both shown on the dock and listed in the Applications menu.

[meanpt]

Hi

I installed TC again on the virtual hd and I'm having more trouble in downloading and installing. Moreover, when even not choosing to backup, it stills backup something.

I tried to download firefox, leave it during the night to download it and it froze, despite letting it installing all night.

Tried to download shiretoko, it seems it was installed (shiretoko.tcz ok under the yellow background) but when clicking on the docked icon nothing happened. Then tried to call it from the terminal and it was "not found".

Tried to install epiphany, it froze somwhere and I pushed again the Install button. Then, installation  seemed to continue and I got a "epiphany.tcz ok" but didn[t get the docked icon. Again, when calling epiphany in the terminal, it was "not found".

Unthicked the back-up for the logout, logged out and after booting again I found epiphany.tcz was still available in "local". When  tried to mount it, there was a dependency missing (expat2.tcz. not found).

The awkward is that I can install and run shiretoko as well as firefox in live mode but usually on a second or third installation trial.

[maro]

@meanpt: You are reporting problems with the "installation" that are a bit difficult to investigate. It is (at least for myself) not easy to differentiate what is a "download" (e.g. networking) and what is an "installation" issue.

May I suggest that you use the command line next time and post all messages of your failed attempts back here. The command to use would be tce-load -wi shiretoko (or choose any other extension name instead).

[althalus]

Tried to install epiphany, it froze somwhere and I pushed again the Install button. Then, installation  seemed to continue and I got a "epiphany.tcz ok" but didn[t get the docked icon. Again, when calling epiphany in the terminal, it was "not found".

I'll let others try and assist you with your other problems, however this particular one is a problem I've been meaning to mention myself.

Start downloading an extension, click Install or Download a second time before the first operation has finished, and you end up with missing dependencies. I think this is caused by recursive dependencies.

A.tcz depends on B.tcz depends on C.tcz.

The pattern SEEMS to go like this: Start downloading A.tcz, it realises it needs B.tcz. Installation of B.tcz is interrupted, and installation of A.tcz starts again. It thinks B.tcz is already there, and fails to check that B.tcz is missing one of IT's dependencies.


And as maro pointed out, it is always helpful for people to be able to see the entire error message.