Tiny Core Linux
General TC => General TC Talk => Topic started by: scfan on October 12, 2010, 07:58:23 AM
-
Hi everyone,
I've been playing with TC on a chroot, however, I'm having some problems.
I've followed the instructions from the Remastering Wiki page, however, when trying to install something, I'm not able to.
I've mounted proc with mount -t proc none working_folder/proc and I've edited resolv.conf to use DNS. I'm able to ping by IP and name, and even wget files, however, when using tce-load or ab, I can't install anything.
$ tce-load -wi xchat
Nothing happens. It just stays there. No output, no errors, nothing.
If I use Xnest and try and do it via appbrowser, the same thing happens. appbrowser just sits there, and nothing happens.
I'm able to connect to the repositories and get a listing, but no install anything.
Any tips?
-
TC was not designed to run extracted (scattered), and chroot is an additional complication on top.
Some initialization might be missing (things done on boot normally), like the location of the tce dir.
To trace a script's execution, add " -x" to the first line, ie "#!/bin/sh -x"
-
TC was not designed to run extracted (scattered), and chroot is an additional complication on top.
Some initialization might be missing (things done on boot normally), like the location of the tce dir.
To trace a script's execution, add " -x" to the first line, ie "#!/bin/sh -x"
I see. That's probably it, however, what other way do you recommend to "Remaster" it?
Any recommendations on what scripts to look at?
-
If you intend to include extensions in the image, it depends on the extension whether just unpacking is enough or if something else is needed. Doing a tce-load in the chroot, even successfully, would just download and loop-mount the extension.
If you're new in this, check out the ezremaster program first. There's a wiki walkthrough on it at http://tinycorelinux.com/wiki/Remastering+with+ezremaster
-
I've been playing with TC on a chroot, however, I'm having some problems.
I am drifting slightly off-topic, but I'd like to add some useful information. I build my extensions in a chroot. I had some problems as well, but I was able to resolve them for my use case. I use the following command within the chroot environment to mount the first four filesystems in /etc/fstab:
for m in /proc /sys /dev/pts /dev/shm; do mkdir -p $m; mount $m; done
Compiling in a chroot is nice because I just extract tinycore.gz, extract the compiler and other required extensions, extract the source, compile, then remove the tinycore.gz and extension files. Everything left over is part of the extension.
-
I've been playing with TC on a chroot, however, I'm having some problems.
I am drifting slightly off-topic, but I'd like to add some useful information. I build my extensions in a chroot. I had some problems as well, but I was able to resolve them for my use case. I use the following command within the chroot environment to mount the first four filesystems in /etc/fstab:
for m in /proc /sys /dev/pts /dev/shm; do mkdir -p $m; mount $m; done
Compiling in a chroot is nice because I just extract tinycore.gz, extract the compiler and other required extensions, extract the source, compile, then remove the tinycore.gz and extension files. Everything left over is part of the extension.
Hi there,
Thanks for the tip. I'm sure it's way better than what I was doing.
I like the idea of having tinycore inside chroot, makes it easier to script and make changes, however, even with your tip, I still can't install anything.
If was never able to do this, I would have quit by now, the problem is that it has worked before. I'm 100% positive. This is what makes me trying to make it work.
-
All of my extensions build successfully within a 2.x chroot. I've not tested with 3.x yet. Here is what I do:
1) Extract tinycore.gz
2) Extract extensions
3) Run this:
echo tc > /etc/sysconfig/tcuser
/sbin/ldconfig
for m in /proc /sys /dev/pts /dev/shm; do mkdir -p \$m; mount \$m; done
find /usr/local/tce.installed -not -empty -exec sh {} \; &/dev/null
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
# Run build script
Note that you won't see anything udev does in a chroot so might have to populate /dev yourself for anything which isn't included in tinycore.gz.
-
A while ago I did some analysis where I repeatedly set up chroot "jails" in which the "action" took place. By and large I did the same as danielibarnes has suggested. My final script contained everything what I deemed required, and it took a fair amount of trial-and-error to get it right. There are a few (minor ?) differences between my "hack" to what has already been suggested, but I'm not sure that those are substantial enough to justify the full publication of my script. In the end it was created for quite a different purpose.
The one thing that strikes me is that you might not be on the same page WRT how to prepare the chroot "jail" with the required extensions. Bear in mind that the boot process of TC involves more than just extraction of the initrd. I found I had to "emulate" to some degree the role that '/etc/init.d/tc-config' (and "friends") are playing. In my case that meant running (in the root of the "jail"):for DIR in usr/local/tce.icons usr/local/tce.installed usr/local/tce.menu \
tmp/tce tmp/tcloop ; do
[ -d "$DIR" ] || sudo mkdir "$DIR"
sudo chgrp staff "$DIR"
sudo chmod g+w "$DIR"
done
echo '/tmp/tce' > opt/.tce_dir
I believe that after copying the respective 'tcz' files (plus their 'dep' files) into the 'tmp/tce' directory of the "jail" I was able to use 'tce-load -i ...' when "inside". Maybe something along this line is missing in your approach.
A further point of note is what is required to allow for X clients to run from the "inside". That needed more tweaking, and as I'm not sure that you'll need such I'd rather hold back with discussing it here.
-
Thank you both very much for the suggestions. I'll give them a try in a few hours and report back here.
Regarding the graphical applications, I was able to use Xnest on my host and then just exported the DISPLAY variable and was able to start the windows manager and all applications. The problem is that I can't "remaster" anything without being able to install additions.
Once again, thanks for the tips.
-
for DIR in usr/local/tce.icons usr/local/tce.installed usr/local/tce.menu \
tmp/tce tmp/tcloop ; do
[ -d "$DIR" ] || sudo mkdir "$DIR"
sudo chgrp staff "$DIR"
sudo chmod g+w "$DIR"
done
echo '/tmp/tce' > opt/.tce_dir
Awesome. This made it work very NICELY! Along with the information about mount provided by danielibarnes I now have it fully working.
Thanks for the great tips guys!!
-
BTW guys,
I'm updating my scripts (I have one to create a new chroot and another one to build the ISO). What did you guys do on yours to have commands being done inside the chroot?
I mean, so far I've only done commands originating on my host system. How can I, on the script, make it run the script that maro posted.
Another question is related to a problem raised by curaga. I'm installing the applications on chroot, and they are still installed when I create the ISO, however, they all fail to start. In this case, with Firefox, is complaining with:
/usr/local/firefox-official/firefox-bin: error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory
-
Are you asking of how to execute a script that resides "inside" from the "outside"? In my case I created just a single script for chroot setup and test execution. It contained (using a here-document) the "worker" script which was to be run "inside".
Assuming '/tmp/jail' represents the root of the chroot, I was using something like cat > /tmp/jail/tmp/worker.sh <<EOF
#!/bin/sh
....
EOFto create the worker script and then finally called it with chmod +x /tmp/jail/tmp/worker.sh
sudo chroot /tmp/jail su -c "/tmp/worker.sh PARAMETERS" $USER
If you go down this path be aware that in a here-document you need to use backspace as escape character for characters like '$' and unquoted '\'. The alternative is obviously to copy a script from the "outside" to the "inside", which might be easier depending on the complexity of this "worker" script.
Edit: I forgot to add that the code snippet from reply #7 was run by the setup script after the initrd extraction. That means it was executed from the "outside" (after a 'cd /tmp/jail'). I could imagine that it it's possible to integrate it into the "worker" script (to be run fairly early on), but that was not how I did it. In principle all the setup and preparation was done from the "outside" and afer the execution of the "worker" script just a small amount of results were copied back to the "outside", followed by a comprehensive cleanup.
-
Are you asking of how to execute a script that resides "inside" from the "outside"? In my case I created just a single script for chroot setup and test execution. It contained (using a here-document) the "worker" script which was to be run "inside".
Assuming '/tmp/jail' represents the root of the chroot, I was using something like cat > /tmp/jail/tmp/worker.sh <<EOF
#!/bin/sh
....
EOFto create the worker script and then finally called it with chmod +x /tmp/jail/tmp/worker.sh
sudo chroot /tmp/jail su -c "/tmp/worker.sh PARAMETERS" $USER
If you go down this path be aware that in a here-document you need to use backspace as escape character for characters like '$' and unquoted '\'. The alternative is obviously to copy a script from the "outside" to the "inside", which might be easier depending on the complexity of this "worker" script.
Edit: I forgot to add that the code snippet from reply #7 was run by the setup script after the initrd extraction. That means it was executed from the "outside" (after a 'cd /tmp/jail'). I could imagine that it it's possible to integrate it into the "worker" script (to be run fairly early on), but that was not how I did it. In principle all the setup and preparation was done from the "outside" and afer the execution of the "worker" script just a small amount of results were copied back to the "outside", followed by a comprehensive cleanup.
Hi there,
Thank you so very much for all the helping you've been giving.
I'm getting really close to what I want to accomplish, thanks to all the help from this forum
The only "problem" I have now, is that after adding a couple more extensions (mostly to be able to build software from source), I'm now getting a "Kernel panic - not syncing: No init found".
The weird thing is that the script I made to create the .ISO was working before, and only after adding more software (compiled from source) and extensions, this error started appearing.
Any tips on why this is happening?
-
What is the size of your root filesystem? is it close to the amount of memory on the machine?
-
Hi,
No. The machine (Virtual), has 1024MB and the filesystem has 263MB. The resulting ISO is less than 150MB.
-
The only thing I can think of is to check each step the initialization process. The most common cause is that it can't load the rootfs. Since it definitely isn't an out-of-memory condition, we must look at the whole process. I gather you have advanced expertise; please forgive the simple questions.
Are you using grub or syslinux to load the iso? What is the value of the initrd parameter? Can you verify by loop-mounting the iso that the file exists at the specified location? I've had this problem happen when forgetting the leading slash.
If this checks out, verify the root filesystem. You should have /init:
# ls -l /init
-rwxr-xr-x 1 root root 370 Aug 16 20:21 /init
which requires /bin/sh:
# ls -l /bin/sh
lrwxrwxrwx 1 root root 7 Sep 19 22:25 /bin/sh -> busybox
I figure something has to be going wrong before this point, but I will elaborate on the rest of the sequence for completeness. /init executes /sbin/init:
# ls -l /sbin/init
lrwxrwxrwx 1 root root 14 Sep 19 22:25 /sbin/init -> ../bin/busybox
Busybox init will read /etc/inittab
# grep sysinit /etc/inittab
::sysinit:/etc/init.d/rcS
and execute /etc/init.d/rcS by default:
# ls -l /etc/init.d/rcS
lrwxrwxrwx 1 root root 9 Sep 19 22:25 /etc/init.d/rcS -> tc-config
# ls -l /etc/init.d/tc-config
-rwxr-xr-x 1 root root 15111 Aug 29 15:41 /etc/init.d/tc-config
-
Hi everyone,
Because of the help of everyone in the board, I'm 99% done. I have, however, a small problem.
I've used some development TCEs in order to compile software, which I would like to remove (and some other TCEs as well). However, and because of the nature of TC, this isn't as trivial as I thought.
Since appsaudit only marks the TCEs for removal, I need to reboot in order for them to be actually removed. Any tips or ideas on how to do this in a chroot environment?
-
just a raw thought...
what about exiting the chroot (umount everything which is mounted only for the chroot), then setting the chroot up again? No idea if this would work though...
-
Hi there,
I don't think that will work, because from what I can tell shutdown.sh is needed in order to make something happen. If that script is not run, no changes will be made. Running the script by itself, though, won't do anything either.
-
Maybe I'm thinking too simplistic here, but I'd remove entries from '.../tce/onboot.lst' and delete the respective .tcz files from '.../tce/optional' "by hand": e.g. via
sed -i '/EXT.tcz/d' $( cat /opt/.tce_dir )/onboot.lst ; rm -f $( cat /opt/.tce_dir )/optional/EXT.tcz*
(for an extension named 'EXT.tcz')