Tiny Core Base > Alpha Releases

Tiny Core 3.0 Alpha 4 Testing

<< < (6/14) > >>

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:

--- Quote from: ^thehatsrule^ on May 24, 2010, 01:46:52 AM ---@Sandras: try again with a fresh local?  It could be that some were loaded before copy2fs was set.

--- End quote ---

--- Quote from: maro on May 24, 2010, 03:20:31 AM ---@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.


--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version