Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: StefanSch on March 07, 2014, 12:27:41 PM
-
I had to patch one the TC shell scripts in the core.gz.
Since I believe that my patch might be beneficial to the general public
and in the spirit of the GPL I'd like to ask how and where to send it in.
The patch is pretty trivial, but there you go.
Just in case some TC core team member is interested in advance,
I added the option "iso" to the restore keyword for the kernel commandline
in the file /etc/init.d/tc-restore.sh.
It will look at the first ISO9660 device to find the mydata.tgz.
Is it planned to make the Tiny Core sources more accessible, e.g.
by hosting them at one of the usual suspects? (github,code.google,sf)
TIA
Stefan
8)
-
http://git.tinycorelinux.net
-
Just in case some TC core team member is interested in advance,
I added the option "iso" to the restore keyword for the kernel commandline
in the file /etc/init.d/tc-restore.sh.
It will look at the first ISO9660 device to find the mydata.tgz.
Can you explain expected benefits of this modification?
-
Since you can't backup to an iso, I believe your custom data would be better loaded using a custom tcz, a second initrd, or a remaster.
-
I agree with gerald_clark. Loading the backup from an iso goes against the idea of a backup.
We also have a patch hosting service:
http://patches.tinycorelinux.net/
-
Same here. I do not see any benefits of the proposed change.
-
First of all, thank you for the link to the git repo and the patch-page. I wasn't aware of those. (Perhaps it would be nice to put those in the FAQ, under "How do I submit patches to Tiny core?")
Please let me explain what problem I was trying to solve with my patch. Perhaps there is a more idiomatic 'tiny corish' way of doing it.
I generate an ISO, that is typically run from a USB stick. It has in it's mydata.tgz a shell script that I put in /home/tc/.X.d/start.sh, to have it being started automatically, to launch the application that I want to run without any user interaction. I agree that I am kind of abusing the backup archive for another purpose, but it was the only way that I could think of.
I have tried to have the startup script as part of my extension (my main app is an extension), but I found no other way to get it started automatically with resorting to that start script in mydata.tgz. If there is a way to hook up a start script for an X11 application from _inside_ an extension, I'd be happy to learn about it. I wonder if the second initrd could solve that problem (mentioned by gerald_clark), but I don't know how that would be done. To boil it down to one requirement: I want to start an app in X, preferably without touching any of the core scripts. My app in the tcz is properly hooked up in /tmp/tcloop and also linked to the /usr tree, but it won't get started...
Kind regards
Stefan
???
-
I wonder if the second initrd could solve that problem (mentioned by gerald_clark), but I don't know how that would be done. To boil it down to one requirement: I want to start an app in X, preferably without touching any of the core scripts. My app in the tcz is properly hooked up in /tmp/tcloop and also linked to the /usr tree, but it won't get started...
http://wiki.tinycorelinux.net/wiki:dynamic_root_filesystem_remastering
See also:
http://www.perlmonks.org/?node_id=542341 ;)
-
Regarding XY problem: haha, didn't know about that one. Actually, I already _had_ solved my problem with my patch and I was trying to be helpful by submitting it. So my question wasn't really about Y, but X; solving Y more elegantly and idiomatic in the process is byproduct, that I'd be happy to integrate.
::)
-
Hi StefanSch
It sounds like you are saying your X application won't start prior to X being up. Try starting it from ~/.X.d. Place a file containing
the command to start the app in that directory. Be sure to put an & at the end of the line:
AppName Options &
-
Rich, that is what he is attempting in the backup file.
Instead of remastering with a backup file, just remaster with the startup script in the the initrd or in a second initrd to be loaded with the first.
Another option is to put all the custom stuff in a tcz and add it to the onboot.lst
-
Regarding XY problem: haha, didn't know about that one. Actually, I already _had_ solved my problem with my patch and I was trying to be helpful by submitting it. So my question wasn't really about Y, but X; solving Y more elegantly and idiomatic in the process is byproduct, that I'd be happy to integrate.
::)
Yes, I can see that, unlike the most common case of XY problem; just that other users could not see a use case where such a patch would be of benefit compared to already existing methods (not meaning to discourage submitting of patches in general) ;)
-
Converting mydata.tgz to an initrd is quite simple. As root:
mkdir /tmp/foo
tar -C /tmp/foo -xvf path/to/mydata.tgz
cd /tmp/foo
find | cpio -o -H newc | gzip > ../my-new-initrd.gz
-
Or to create a tcz:
mkdir /tmp/foo
tar -C /tmp/foo -xvf path/to/mydata.tgz
cd /tmp
mksquashfs foo mydata.tcz
-
I will try out the addition of the second Initrd. I have already tried to put my mydata.tgz into a tcz, but I found no way to put the startscript into it, such that it would be started.
Stefan
:D
-
The tcz would have to be listed in the onboot.lst.
It would install the /home/tc/.X.d/startup.sh.
The startup.sh would run when X is started.
-
Using the second initrd worked for me! Thanks for the helpful comments.
Now I'll think twice about suggesting to contribute patches. (No irony intended, it's a coincidence.)
:o
-
Patches are welcome if they solve a problem that cannot be solved using existing methods, and do not go against core's design philosophy.
Don't be afraid to make suggestions you think worthwhile, just be prepared to present your case.
We all had to defend our suggestions before they were adopted.