tce-load broken in 3.3 for persistence bootcodes?

[jonathanbrickman0000]

See attached screenshot.  I have TC 3.3 installed with all three standard persistence bootcodes, but then when I try a tce-load -wi, errors.  Perhaps I have got something wrong? 

J.E.B.

[maro]

First I thought: How rather strange, as I guess the only piece of the script that could be responsible for those messages is:

Code: [Select]

    [ -z "`busybox ls /tmp/tcloop/${APPNAME}`" ] && busybox umount -d /tmp/tcloop/"$APPNAME"
(which was actually added in TC 3.3rc2 with a comment like "Updated tce-load to un-mount meta (empty) extensions")

Are you sure that you have no '.../tce/copy2fs.flg' file or a 'Xvesa' entry in '.../tce/copy2fs.lst'? Because that would be a way how I can reproduce such messages. It probably means that this piece of code will need to be moved a few lines further up in the script (I guess moving it into the 'else' branch should resolve it).

OTOH I don't think that this is going to create any problem just because a kind of housekeeping task is failing. I believe your extension will still be installed (albeit extracted to the file system instead of being loop mounted).

[jonathanbrickman0000]

I do in fact have a .../tce/copy2fs.flg file.  Sorry for the persistent ignorance -- can you explain to me why this is bad?  is it made irrelevant by the boot codes?

J.E.B.

[roberts]

Nothing wrong using copy2fs.flg if you know that in fact is what you wish to use and have a persistent local. Persistent local is not recommended and not used by any team member AFAIK.

This issue operationally has no effect and can be safely ignored.

Adjustment to tce-load has been made per maro's post for clean up.

[jonathanbrickman0000]

Got it.  I am not using persistent local anymore either, but that file is apparently a remnant in my installer; I'll remove it.

J.E.B.

[roberts]

Without persistent local then every tcz would load entirely into ram.
It could quickly exhaust your ram and will boot much slower.

Sometimes, I think Tiny Core has too many options and combinations of options.
Tiny Core is highly configurable.

[jonathanbrickman0000]

Options are often helpful -- but confusion is not :-)  And confusing options are not. 

I have been thinking about improving this via documentation on the wiki, but I realized rapidly that I don't know enough myself to do it yet.  I settled for waiting on some more learnings in development of my easy install script, which more or less solves the problem in a different way.

The way most distros handle the problem, is by setting up a very few quite specific "default install" scenarios which are supported by setup routines (scripts, GUIs, step-by-steps, and/or all three), and not supporting the rest.

I read a large amount of TC writing, wiki and site and forum, before I got to 1.0 on my installer -- and found that I was still not completely clear, because in order to produce "simple single PC with persistence" I had had to add things to the "standard" installer instructions which were scattered in the forums...and I later found that I had added too many things because of confusion, mixing PPR and 'local'.  And then I read, in more than two or three places, that 'local' is not supported at all.  And then I read that it is supported :-)

Robert, if the 'standard' installation instructions reflected a fully persistent PC install in PPR, that would probably help a lot. 

Some real-world clarification on the 'local' situation would be a very good idea too.  I would like to try building a real-time audio workstation out of TC, but until I have something to work with concerning 'local', it doesn't seem to make sense to try.

J.E.B.

[roberts]

The usbinstall script does reflect what I consider to be a standard installation.
I would not presume to make other persistent decisions. Such options IMHO should only be attempted after one has become familiar with the standard. I realize that many do not want to address file management in their own home directories thereby bypassing the default backup. They choose instead to use some level of persistence. That then becomes a hybrid installation and anchors one to a specific machine. Again all of these are user options. That it why I chose the new logo spelling out that this is a toolkit. Trying to code and support all the options in this toolkit is not an easy task. Documenting all permutations and combinations of using any toolkit is also not an easy task.

[tinypoodle]

Without persistent local then every tcz would load entirely into ram.
It could quickly exhaust your ram and will boot much slower.

Note: tmpfs is not necessarily kept in RAM, it uses virtual memory and can thus be swapped out to disk as well.

[curaga]

When on machines with 2gb+ ram, the usability skyrockets when everything is in ram

[roberts]

I am in the case where the shoemaker has no shoes.

[jonathanbrickman0000]

Do you have a PayPal account :-)

J.E.B.