Tiny Core 3.0 Alpha 4 Testing

[althalus]

Problem with openbox on alpha 4: obconf segfaults.

[u54749]

Another case of application breakage: galculator

Base Tinycore + fresh install of galculator via appbrowser

-  works normally in Alpha3
-  doesn't work in Alpha4:  "Segmentation fault"

[maro]

@u54749: Have a look at this post. I have just done a quick install of 'galculator' with my re-build 'libxml2' library and it appears to not crash with that one.

@althalus: I imagine it could be the same reason for your reported issue.

Since 'gtk2.tcz' depends on 'libxml2.tcz'  there could be many other problems. I can't attach the library I've compiled here in the forum (it's too large with ca. 533k), but I'm sure you could either follow my steps (in building your own temporary library) or you just wait until an "official" update has happened.

[u54749]

I have recompiled libxml2 myself and can confirm that it solves both the ROX and the galculator issue

[althalus]

Since obconf would have to parse openbox's XML config file, I think you're right in that obconf is just one more casualty of libxml2.

[Jason W]

rebuilding libxml2 as we speak, will be uploaded shortly.

EDIT:
Done.

[Jason W]

Juanito-

For the desktop file entries, I think we are now at the point where we can deal with them individually as they are found.

[sandras]

used boot code local=hda1 and there was  acopy2fs.flg in my tce. after TC booted up, there were a bunch of symlinks that would usually point to files in .tcz's mounted on /tmp/tcloop/* , but there were no .tcz's mounted. should this be fixed? I thought this way I would get a persistent /usr/local on my hard. you know, the traditional -install-like mount of /usr/local.

one more thing. i think i saw checkfs option when I pressed f2 or f3 at boot prompt. but there doesn't seem to be such option in /etc/init.d/tc-config.

[maro]

Another small observation: Booting just the TC 3.0alpha3 ISO I thought I saw an additional error message in the terminal from which the X server got started. So I did an 'Exit to Prompt' and could read (apart form the familiar xauth:  creating new authority file /home/tc/.Xauthority) the new
   ls: /usr/local/share/applications: No such file or directory

Well I guess those files are now in '/usr/share/applications' so a couple of scripts (e.g. 'flwm_topside_makemenu', 'ondemand', 'startx', and 'wbar_icon_upd.sh') are not yet aware of that change.


Edit: small correction and removal of a false claim

[roberts]

I already have that fixed. The message is harmless.
It appears when there are no extensions that have menu items, which I wasn't too interested in at the time.

[maro]

@roberts: Thanks, I was not suggesting for this to be a real issue.

@Sandras: I guess your are correct the code for 'checkfs' boot code seemed to be "gone". I had a look through my archived files and I found it last in TC 2.3.1

Regarding your other problem I'm not quite sure what your are trying to achieve, so I attempted something myself to see if I could find anything "outrageously" wrong (I was using QEMU since that allows easy testing of such scenarios, but I dont' think that "real" hardware will behave differently):
(1) First boot from CD-ROM with an freshly formatted hard disk, using boot code 'tce=hda1' to create the required directories. I've installed a small number of extensions and took a "snapshot" of '/usr/local'. This showed all the expected links from '/usr/local/...' into '/tmp/tcloop/...'. Then created the "flag" with touch /mnt/hda1/tce/copy2fs.flg
(2) Next boot from CD-ROM with the prepared hard disk (but not using any boot code). Due to the 'copy2fs.flg' no files were present in '/tmp/tcloop' but all were extracted into the (in-memory) root file system -> exactly as expected.
(3) This time the system got booted with the boot code of 'local=hda1'. The booting took a bit longer and the hard disk got "busy". There was an additional (and entirely expected) mount of '/usr/local' from '/dev/hda1' to be found (binding '/mnt/hda1/tclocal' to '/usr/local'). By now the files had been extracted from the *.tcz files into '/usr/local' (i.e. '/mnt/hda1/tclocal'). I'm not sure what that is meant to achieve, to have the squash-fs files and the extracted content on the same disk. So I assume my test is not what you had in mind. Nevertheless I believe it all worked as it should have done.
I've done a few more tests and none of them showed anything unexpected. So maybe you could describe what result you are after.

[sandras]

@Sandras: try again with a fresh local?  It could be that some were loaded before copy2fs was set.

@Sandras: I guess your are correct the code for 'checkfs' boot code seemed to be "gone". I had a look through my archived files and I found it last in TC 2.3.1

Regarding your other problem I'm not quite sure what your are trying to achieve, so I attempted something myself to see if I could find anything "outrageously" wrong (I was using QEMU since that allows easy testing of such scenarios, but I dont' think that "real" hardware will behave differently):
(1) First boot from CD-ROM with an freshly formatted hard disk, using boot code 'tce=hda1' to create the required directories. I've installed a small number of extensions and took a "snapshot" of '/usr/local'. This showed all the expected links from '/usr/local/...' into '/tmp/tcloop/...'. Then created the "flag" with touch /mnt/hda1/tce/copy2fs.flg
(2) Next boot from CD-ROM with the prepared hard disk (but not using any boot code). Due to the 'copy2fs.flg' no files were present in '/tmp/tcloop' but all were extracted into the (in-memory) root file system -> exactly as expected.
(3) This time the system got booted with the boot code of 'local=hda1'. The booting took a bit longer and the hard disk got "busy". There was an additional (and entirely expected) mount of '/usr/local' from '/dev/hda1' to be found (binding '/mnt/hda1/tclocal' to '/usr/local'). By now the files had been extracted from the *.tcz files into '/usr/local' (i.e. '/mnt/hda1/tclocal'). I'm not sure what that is meant to achieve, to have the squash-fs files and the extracted content on the same disk. So I assume my test is not what you had in mind. Nevertheless I believe it all worked as it should have done.
I've done a few more tests and none of them showed anything unexpected. So maybe you could describe what result you are after.

I wasn't actually trying to achieve anything with the particular setup, I was just experimenting. It was my first time using the local=* bootcode, so i decided to explore it a bit more.  Once I manually copied extensions to a partition on my hard drive and made TC mount it via bootlocal. And that gave me a very fast boot, it took practically the same time too boot as a base norestore boot. The thing is, it was very sluggish and that was an expected downside. I just wanted to see how much slower would it be. And I repeated that same experiment with the alpha4. Not that I'm going to go for a traditional type of /usr/local. The thing is it didn't seem to work properly. But anyway, I'll repeat the experiment and check if maybe I did something wrong.

[althalus]

With the libxml2 update, alpha4 now seems to be running perfectly on my machine.

[curaga]

@Sandras, if you load extensions in the background, using nice would help the interactivity during loading.

[u54749]

Does anybody see (very rare) mount problems, like one extension out of many that does not mount on /tce/tcloop the first time?

Repeating the mount or tce-load command solves the problem.

I see these rare mount problems from time to time in the Alpha releases.  The mount fails with a "Cannot allocate memory" message, even when there is ample memory available.  I didn't see this behaviour in the 2.x releases.

I can not reliably reproduce this problem.  It happens randomly.