Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: jonathanbrickman0000 on November 22, 2010, 08:40:35 PM
-
I'm certain I'm doing something wrong, but I don't know what:
- I have tce=, opt=, and home= persistence set up in 'grub', TCL installed to hard drive.
- I install kmaps (tce-load -wi kmaps), the files vanish at next reboot unless I add "usr/share" to /opt/filetool.lst and run "filetool.sh -b" beforehand.
- I install freerdp, and some of the files stick around, but xfreerdp won't run at next reboot because Xcursor.* libraries are missing from /usr/lib, and adding "usr/lib" to filetool.lst and doing "filetool.sh -b" doesn't help (I know that's overkill, but I had to try something).
Anyone know what is going on ????? And how do I fix it by command line or shell script? :-)
J.E.B.
-
Not having any knowledge about your particular setup but...
Are you very sure about those paths?
e.g. are they really usr/share resp. usr/lib and not usr/local/share resp. usr/local/lib?
Also, are you sure you backup the files you intend to, and not just symlinks to the files?
-
Thinking about your questions, I did the following:
1. tce-load -wi kmaps freerdp
2. Added to /opt/.filetool.lst:
usr/share
usr/lib
usr/local/lib
3. filetool.sh -b
This appears to have worked, xfreerdp now runs after reboot. All three lines added to /opt/.filetool.lst appear to be necessary. Concerning the symlinks, I checked the lib directories, and the symlinks all remain as they should.
I guess my big question is, is the filetool method really necessary? Is there something simpler I could be doing which is an accepted TC-standard?
J.E.B.
-
All this backup stuff sounds a bit "desperate". I'd suggest you keep a copy of 'mydata.tgz', remove the surplus entries from the "white-list" and re-do the backup.
Troubleshoot it step by step and make no assumption until a certain fact can be proven:
(1) Is the extension (i.e 'kmaps.tcz') in the '.../tce/optional' directory and does the MD5 checksum match?
(2) Is the extension listed in '.../tce/onboot.lst'?
(3) Boot with (temporary) boot codes 'showapps pause' and check that 'kmaps' is listed amongst the installed extensions.
(4) After booting look for '/tmp/tcloop/kmaps' and '/usr/local/tce.installed/kmaps'
My hunch is that at one of those steps an unexpected result will occur.
-
All this backup stuff sounds a bit "desperate". I'd suggest you keep a copy of 'mydata.tgz', remove the surplus entries from the "white-list" and re-do the backup.
Desperate is right :-) I do not yet know how to remove anything from the white-list (didn't know there was one?), but I tried your steps below just after tce-load -wi kmaps, and may have spotted an issue:
Troubleshoot it step by step and make no assumption until a certain fact can be proven:
(1) Is the extension (i.e 'kmaps.tcz') in the '.../tce/optional' directory and does the MD5 checksum match?
The hard drive is sda1, and kmaps.tcz is located in /mnt/sda1/tce/optional. There is an md5 file there, but how do I check it for a match?
(2) Is the extension listed in '.../tce/onboot.lst'?
There is no file named /mnt/sda1/tce/onboot.lst. Do I need to create one? Perhaps this is it??? If so, what exactly does this file do, and when? I was not able to find a wiki entry on it, but it looks like it is often set up by AppsAudit?
J.E.B.
-
(4) After booting look for '/tmp/tcloop/kmaps'
A foolproof way to do so may be
ls -R /tmp/tcloop/kmaps
as it can be observed under certain conditions that the mount dir would exist without any extension being mounted on it.
-
After reboot, /tmp/tcloop was empty.
J.E.B.
-
(a) What I started to call the "white-list" is '/opt/.filetool.lst'
(b) To check a MD5 checksum use md5sum -c EXT.tcz.md5.txt
(c) AppsAudit manages the '.../tce/onboot.lst', not having such a file mean that NO extension will be loaded at boot time
Question: What is in your '/opt/.tce_dir'?
-
After reboot, /tmp/tcloop was empty.
J.E.B.
Just to clarify, when I mentioned 'foolproof' I meant with regard to what I mentioned, not with the to path to tce_dir ;)
-
Gotcha, tinypoodle. I think I'm seeing a flicker of light at the end of the tunnel :-) Currently:
1. I have left /opt/.filetool.lst default.
2. The MD5 for kmaps.tcz does check out.
3. /opt/.tce_dir contains "/mnt/sda1/tce", which I think is exactly right.
I made just one change: I used AppsAudit to add "kmaps.tcz" to the onboot list. it added the single line "kmaps.tcz" to /mnt/sda1/tce/onboot.lst. I then rebooted...and the problem is repeated, /usr/share/kmap (which is the folder kmaps.tcz populates) is not populated except for the original us.kmap.
-
OK, so you've reported the results of checks (1) and (2) from reply #3. How about (3) and (4)?
And as an additional question: What happens when you just execute tce-load -i kmaps ?
-
I am understanding a bit more of what you're asking now, I think. I'm redoing from the start of your four-step process:
1. Booted to TC installed to hard drive.
2. tce-load -wi kmaps
3. kmaps.tcz is in onboot.lst, and it is in .../tce/optional, and the md5 does match.
4. Rebooted adding 'showapps pause' to the end of the grub line.
5. It rebooted, paused appropriately, but showed no extensions at all when it paused.
What is the best URL for a 'wget' for kmaps.tcz ?
J.E.B.
-
Also, by the way, my 'grub' kernel line is:
kernel /boot/bzImage quiet max_loop=255 waitusb=5 tce=sda1 opt=sda1 home=sda1 local=sda1
J.E.B.
-
Why limit to 255? Not needed in 3.x.
Why are you mixing Hybrid (local=) and Mount (tce=) modes?
If no extensions are loading then either your tce= is incorrect or you need to increase your waitusb amount.
I would not even use a tce= unless used with LABEL or UUID. But mostly it is not needed the system will find it on supported filesystems given enough time for it to be recognized.
Finally, what filesystem is on sda1? Are you trying to use a non-base supported filesystem, i.e., one that requires an extension for its support?
-
Besides from all the points roberts already commented on, if you are troubleshooting, why would you use 'quiet' as a kernel parameter?
-
I see my errors :-) Most of all, I was confusing local= with /usr/local, thinking that local= had to exist in order to persist /usr/local. I made quite a few tests, and all is now behaving predictably :-) I also removed the limit item. I'll probably leave the tce= item in, to prevent non-technical-user-related issues :-)
Many many many thanks!!!!
J.E.B.
-
... I'll probably leave the tce= item in, to prevent non-technical-user-related issues ...
I'd bet it will get you into a fair amount of trouble to use 'tce=DEV' (with DEV something like 'sdb1') if that installation ends up on a USB device. Because that's like saying "you'll always find the 'tce' directory on the first partition of the second SCSI (or SATA) device". Just assume a user has two USB pendrives and connects them at different times, or goes off and uses someone elses computer, or maybe even plugs them into a different USB connector of the same computer. The device name of this USB pendrive has the potential to be different every time (e.g. 'sda' one time 'sdb' the next).
It is for this very reason that the FAQ (http://www.tinycorelinux.com/faq.html#pendrives) puts a strong emphasis on using UUID (or LABEL) instead of a device name. Likewise the 'usbinstall' script uses UUID.
And one more thing: To be on the safe side without "waisting" wait time I'd suggest to use 'waitusb=X:UUID=...' (with a high value for 'X' like 20). This way TC will wait a maximum of 'X' seconds, but not longer then it takes for it to detect a device with the specific UUID.
-
Thoroughly agreed. I'm also not sure if /dev/sd** is really stable enough under SATA, especially eSATA situations. In the future I will set up for UUID, it sounds to me like a very good idea.
But a question: do you know how UUID's are created? I seem to remember an article by Linus Torvalds two or three years ago expressing some concerns about their reliability, but I did not understand why.
J.E.B.
-
... do you know how UUID's are created? ...
AFAIK there are several possible functions that are providing such a capability: In BusyBox there is 'generate_uuid()' (in 'libbb/xfuncs_printf.c'), but I'm pretty sure that it does not play much of a role in TC. AFAIK TC is not using the 'mkfs.ext2' from BusyBox, but the following settings indicates to me that 'mkswap' uses said function:
CONFIG_MKSWAP=y
CONFIG_FEATURE_MKSWAP_UUID=y
OTOH the BusyBox source contains a reference to a RFC (http://www.ietf.org/rfc/rfc4122.txt) plus some quote from the same, which might be of interest.
As TC uses the EXT2FS library (v1.41.11) for its 'mkfs.ext[2-4]' I have reason to believe that the 'uuid_generate()' function (see link to the source code (http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob_plain;f=lib/uuid/gen_uuid.c;hb=refs/tags/v1.41.11)) is instrumental in creating the UUID when one creates an EXT[2-4] file system with TC.
For other file systems created with other tools one would have to look for similar functions.