Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: booker on February 20, 2011, 02:20:39 AM
-
So, after spending time in OS X's terminal, I decided to dust an old machine that I could experiment with Linux on. I came across Micro Core and decided to do the hard drive install. But I've run into a few problems:
* I'm not sure where to get all the development tools for standard C/C++ development.
* I want to setup openssh to run on system startup, but messing around with grub either makes Micro Core forget where openssh is or forget openssh's config file (it has something to do with the local=hda1 when booting).
Many thanks, I hope to get a lot of Linux experience with this setup.
-
Hi booker
You want to download the compiletc extension for development. There are also a couple
of debuggers, I've played with the gdb-6.8_bin package a couple of times, it's light weight
and pretty capable. I'm currently running Dropbear on a TC Samba file server I set up a year
or two ago for SSH. I haven't done a hard drive install yet so I can't help there but if it makes
you feel better it seems a lot of people get confused with LOCAL=, HOME=, etc. settings and
when to apply each of them.
-
Thanks. I tried dropbear and its working great. Now I want to have persistence of my password (to be able to log-in with ssh) between boot but my /opt/.filetool.lst doesn't seem to be working properly. Here it is:
opt/bootlocal.sh
opt/bootsync.sh
opt/shutdown.sh
opt/tcemirror
opt/.filetool.lst
opt/.xfiletool.lst
home
etc/shadow
Maybe it has something to do with my grub menu.lst?
default 0
timeout 5
title Micro Core 3.5
root (hd0,0)
kernel /boot/bzImage quiet tce=hda1 home=hda1 opt=hda1
initrd /boot/microcore.gz
-
with opt= and home= bootcodes, you should not backup anything in /opt or /home.
-
How do mean that: "you should not backup anything in /home and /opt ?
Should the /home folder allways be empty?
I have a lot of stuff in /home/tc and I think that's the reason it takes so long at shut down?
-
Your .filetool.lst should contain no entries for opt or home.
Please read the wiki articles about using boot codes andbackup.
http://wiki.tinycorelinux.com/Backup
http://wiki.tinycorelinux.com/Backup+-+Restore
http://wiki.tinycorelinux.com/Persistent+Home
-
Hi booker
I just checked my server's filetool.lst and here's what I think you should add:
etc/passwd
etc/group
etc/shadow
etc/gshadow
etc/dropbear
@beerstein: Ok, this time in english. Booker's opt and home directory are on his hard
drive, not in memory and therefore don't need to be backed up. The etc directory
gets created in ram during the boot process and any files you modify in there need
to be backed up or those settings will be lost.
-
AHA - Thank you for this - So he has in addition to the /tce folder two more folders
namde /home and /opt.
OK I did not know that this can be done.
Would that speed up the boot- and shut down process?
-
Hi beerstein
Absolutely. Anything you have to back up has to be read, compressed into a file, and
written to your backup device. When you boot, the process is reversed. By having
them on the hard drive instead of in RAM you pay a tiny penalty in access time but
can reduce boot and shut down times.
-
with opt= and home= bootcodes, you should not backup anything in /opt or /home.
Perhaps this should be more explicitely stated in a prominent place in Documentation - as it is brought up again and again (though users using anything else than defaults always have a responsibility of understanding what they do before they do it...).
-
The boot codes sections of the FAQ would be a good place.
-
So, I'm still a bit unsure of what exactly to do. I want it to save my password but right it's not! Also, dropbear reconfigures every time on startup.
My menu.lst is unchanged, but my .filetool.lst now only has the etc/ entries and they're are still not backing-up. Exactly how should I set this up?
-
Microcore does not automagically perform a backup.
From command line use filetool.sh.
If you have specified a backup device it will be noted at /opt/.backup_device in which case you can use:
$ filetool.sh -b
If no backup device has been previously specified then use:
$ filetool.sh -b sdb1 where sdb1 is an example use your particular device.
-
Thanks! It's working perfectly now!
Summary of what I did for newbies:
1. I loaded microcore with home and opt on my hard drive (i.e., home=hda1 opt=hda1)
2. I modified /opt/.filetool.lst so that it only held directories relevant passwords and config (etc/shadow, etc/dropbear, etc/passwd, or see above)
3. I sudo filetool.sh -b to back-up all the stuff in those folders.
4. I added the line 'filetool.sh -r' (without quotes) to /opt/bootlocal.sh . (Not sure if this step is entirely necessary, but my system works so woohoo!).
Thanks again for all the help.
-
Step 4 is not necessary. The backup is restored before bootlocal.sh runs.
-
Hi: This posts are great and helped me a lot to understand the inner workings of the
backup and restore process.
Here is another question:
status: I boot TC 3.5 from CD and have a /tce with about 500 MB sitting on /hda1 FAT 32
waiting to be loaded during boot. This takes about 2 minutes. Not too bad. But when I
shut down and backup it takes about 10 - 15 miniutes until the system comes to a complete stop.
question: Would it help if I create two more directories on /hda1 named:
/home
/opt
and the copy the data from /tce/opt and /home/tc into this folders?
May I do that or is this a no-no?
If not is there any other way to speed up the shut-down process?
Thank you and have a ggod day
-
If you wish to do this, you should really boot from HD.
Then you need to add two boot options:
home=hdXN opt=hdXN
where XN are drive letter and partition number.
First time you boot with these options, home and opt
will automatically be populated from your backup.
You then need to edit /opt/.filetool.lst to remove any lines
for home or opt.
-
If I were you, before changing anything I would rather be keen to diagnose what on earth could cause a delay of 10-15'(!!) to shutdown :o
You are not mentioning many relevant details, e.g. what are the specs of your PC? What is the size of your mydata.tcz?
Do a backup and time it (not before shutdown) - to see to which extent backup per se is responsible for such a long shutdown time.
-
Hi again:
I have an "old" Celeron 775 MHz, 20 GB HD with some other Oses on it and
256 MB of RAM.
mydate.tcz is about 450 MB
The total /tce is about the same -
I installed several extensions and put a lot of work in it and I do not want to start from scratch again. I would like to keep that work I have done and put it on a hard drive - if necessary even onto another PCs hard drive in the network.
I just did that with this configuration a few days before- I copied the /tce over from another machine - I like to move with all my "fun baggage" to other PCs and have all my extensions available.
Sound weired but I love it
-
My usual mydata.tgz is only 1M (mainly browser settings/bookmarks). I recently installed a fairly large (non-TC) application to my home directory and even with that the mydata.tgz was only ~100 M (I later took it out of backup and saved it somewhere else). 450 M seems to me to be an enormous size. Is your browser creating files you don't really need to backup? Is there any static content in your home etc. directory you can put somewhere else? I created a directory under /mnt/sda1/tce (I boot and save from USB) for download files that aren't modified. Could you do something similar so you don't need the huge backup? Just a thought.
-
Hi beerstein
Tinypoodle is right, there is something seriously wrong here. Writing 450MB in 10 minutes
works out to 750KB/sec, if memory serves, even the old ST506 drives from 30 years ago
could do 5MB/sec. I noticed the word "network" in one of your posts. Are you mounting any
network drives in your home directory, or in any path included in your filetool.lst file?
-
Hi beerstein
Tinypoodle is right, there is something seriously wrong here. Writing 450MB in 10 minutes
works out to 750KB/sec, if memory serves, even the old ST506 drives from 30 years ago
could do 5MB/sec.
Not quite.
Write speed is close to negligible in relation to analogy of time used for gzipping the backup.
Achieving a 450MB gzipped tarball within 10-15' sounds about right to me.
This can easily be tested and verified by untarring one's mydata.tgz and then timing tarring and gzipping separately ;)
-
Hi again:
I have an "old" Celeron 775 MHz, 20 GB HD with some other Oses on it and
256 MB of RAM.
mydate.tcz is about 450 MB
By default there is no such case to be expected.
Default size of tmpfs mounted over / = 90% of RAM.
Please post output of
showbootcodes
free
P.S.: This thread, as much as it is particular to TC, as much it has gone astray from the original topic. Perhaps an admin could split it off.
-
@tinypoodle: My point was that he is running an internal hard drive yet quoting the type
of numbers I would get with my USB 1.1 pen drive. And while 10-15 seconds sounds
right he said 10-15 minutes.
-
@tinypoodle: My point was that he is running an internal hard drive yet quoting the type
of numbers I would get with my USB 1.1 pen drive. And while 10-15 seconds sounds
right he said 10-15 minutes.
I extrapolated based on timing my own backup, which is 4-5 secs resulting in 2152KB (done on internal SATA), so 450MB would 10-15' look within a similar rate to me.
-
Hi tinypoodle
That's interesting, I just timed the 10MB backup to my USB 1.1 pen drive and it took 26 seconds.
Based on that it sounds like your backups to SATA should be much faster.
-
I can't follow...
your backup is ~5x bigger in size than mine and takes ~5x in time, no?
-
I untarred my backup then tarred and zipped, it took 14 seconds. So in this case write
time is not negligible. Did not realize zip time was this long.
-
Backup is gzip'ed, not zip'ed.
-
You are correct and that is what I used, I got sloppy in writing the correct words.
-
Hi:
It almost takes forever to backup and shut down. Still.
During boot I can see error messages on the screen such as:
hdc command error: status 0x51
drive ready seek complete error aborted command LastFailed...
hdc possibly failed opcode
after these error messages the PC loads the extensions from hda1 relatively quick.
( I boot from CD and have /tce on hda1 FAT 32
I looked at the devices by:
$ df
and it shows about 87 devices up to /dev/loop87
Do you think ma hard drive is bad?
I thought that too and copied the /tce to another partition on the same hd (ext3) and copied the stuff
from the live CD onto it and booted via grub 0.97 . So this was basically a frugal install. Backup still takes too long (15 minutes or so)
do you have any idea what the problem could be?
-
During boot I can see error messages on the screen such as:
hdc command error: status 0x51
drive ready seek complete error aborted command LastFailed...
hdc possibly failed opcode
This looks like a cd/dvd drive error, which I guess is a result of booting from cd - you could set things up to boot from usb stick or hd?
and it shows about 87 devices up to /dev/loop87
This probably means you have 87 extensions loading "onboot" - you could set some of them to load "ondemand" or manually to speed things up.
Backup still takes too long (15 minutes or so)
This probably means that you're backing up a lot of static data that would probably be better stored on hd or usb stick rather than using tinycore backup.
-
HI Juanite:
Thank you so much for your quick response. The DVD was the problem. The mainboard
did not exactly recognize the DVD drive and caused error while loading other CDs too.
So I replaced it with another CD ROM and now it is 4 minutes to back up. The boot is also
faster now, because the DVD was slowed down too.
-
Even a 4 minute backup seems long.
Maybe your browser cache is the culprit.
-
beerstein,
you never replied to Reply #22.
Your description is incompatible with how TC works by design.
-
HI: Thank you for reminding me -
Now my problem is fixed - here is the output
tc@box:~$ showbootcodes
initrd=/boot/tinycore.gz quiet BOOT_IMAGE=/boot/bzImage
tc@box:~$ free
total used free shared buffers
Mem: 498620 263508 235112 0 15560
-/+ buffers: 247948 250672
Swap: 638684 0 638684
tc@box:~$
please take note, thsi is the output after fixing the problem.
Can you see a problem?
have a good day
-
This is totally different from the numbers in Reply #18.
No problem at all, as you got plenty of free RAM without any of your swap even being used.