Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: Crunch3D on October 15, 2020, 08:33:06 AM
-
Hi
I need tc for a project and it should boot really fast. Now the boot time is around 10-11 seconds. I have only one extension openssh. I dont need gui so i use text interface (i think this should boot faster than 10 seconds shouldnt it ?). I tried installing it with the tce installer onto a virtual hard disk (frugal mode) and it worked but boot takes that long. After some looking around i think this is because of two tings:
1. The system is not actually installed into the system instead its the core.gz and a squashfs filesystem wich needs to be extracted on boot. On top of that the extensions needs to be loaded.
2. Extension loading needs time.
What i want: An uncompressed system on the hdd (like any other linux like arch etc)(size does not really matter here, i just need speed and low ram useage)
I know I can remaster the iso to include the openssh extension but how can i install the system really onto the hdd without the sqashfs extraction so it would boot faster ?
My goal is to boot it in 2-3 seconds to tty of tinycore. Is this doable ?
I already read some other threads here and added te boot flags and this helped. But the extraction of the os and the loading of the extension would at least shave of 3-4 secnds I belive.
How would you proceed to boot that fast, if that is even possible ?
Thanks for your help and time
-
Which version of tinycore are you using and for which architecture?
Are you using tinycore in a vm and, if so, which one?
Note that tinycore loads the root filesystem into ram.
-
Yes i try to install it in VMWARE Fusion.
TinyCore64 11.1 the newest one
Can i install it normaly to make it boot faster or are there other methods in booting faster. Would the x86 version help ?
Is the 3 second goal achivable to tty ?
Another thing is that searching for hardware takes like 1-2 seconds. How can i deactivate the search or givse some default answers. Im already using flopy=none, cdrom=none, sda2=none etc.... Any other command lines that would help speed that up ?
Thanks a lot for the support i appreciate it :-)
BTW: I used the Install in VMware guide in the wiki in addition to the install guide.
-
Hi Crunch3D
Welcome to the forum.
... 1. The system is not actually installed into the system instead its the core.gz and a squashfs filesystem wich needs to be extracted on boot. On top of that the extensions needs to be loaded. ...
This is by design. If something gets messed up or infected, rebooting will likely fix that since the file system gets rebuilt
from scratch from files containing read only file systems.
Be aware, attempting a fully persistent installation may (or may not) clash with some of the systems scripts:
1. /etc/init.d/ # Contains scripts used for booting.
2. /usr/bin/tce* # Scripts for installing, removing, and updating extensions.
3. ???????????? # Other scripts I haven't thought of.
Support may be very limited since Tinycore was never intended for this type of installation.
-
If you don’t need a gui, CorePure64 will boot faster than TinyCorePure64.
-
Hi Rich,
Well thats good to know. In the end, i dont need to make it a regualr install. It just needs to boot lightning fast.
I read on other threads that bootet it with X and firefox and stuff in 10 Seconds. So i think it should boot faster than that without X.
To achive this im here. How it is done is not so much a prioritiy for me.
Any Tipps ?
Thanks!
PS: Good to see that the forum is so active :-)
-
If you don’t need a gui, CorePure64 will boot faster than TinyCorePure64.
I used tinycore to install it without gui. Is this the same than CorePure64 ? Does x86 boot faster than x64 ?
-
Yes, without gui is the same as CorePure64.
I don’t notice a difference between booting 32-bit and 64-bit.
-
Ok. Thanks, what is your boot time to Core ? Just to get me feeling if i can come under the 10 seconds or if this is not possible at all.
Thanks
And if you boot faster, please share how you do it :-)
-
I studied the opening delay in depth.
The whole problem is that the file verification process takes a long time.
http://forum.tinycorelinux.net/index.php?topic=24364.msg154382#msg154382
-
In some quick and dirty testing with CorePure64
* 2-3s base norestore with waitusb
* 7-8s loading 80 extensions, but no backup
both on a 5-year old laptop without vm
-
..4-5s booting the CorePure64 iso with a qemu vm
-
OK if i would remaster the iso with the stuff i need inside, i could use norestore to just boot the iso without the hard drive stuff correct ?
For the extensions i would have to extract them and put them into the /usr/local/ folder correct ?
7-8 seconds is rerally good. I need like 10 seconds for one extension.
Can we deavticate validation of tces at startup ?
-
Hi, guys!
@Juanito
Sorry for the dummy question: does "waitusb" bootcode has some sense in virtual machines?
-
Hi Crunch3D
You can get a better view of where time is being spent If you add these boot codes:
printk.time=1 syslog
After the system comes up:
dmesg > dmesg.txt
If you look through dmesg.txt you will find all of the kernel events along with timing.
If you look through /var/log/messages you will see those same events interleaved with operations being performed by
various scripts. If /var/log/messages overflowed, the earlier stuff will be in /var/log/messages.0.
-
Sorry for the dummy question: does "waitusb" bootcode has some sense in virtual machines?
I don't believe so, I was only using it on an actual machine to boot from a usb stick
-
OK if i would remaster the iso with the stuff i need inside, i could use norestore to just boot the iso without the hard drive stuff correct ?
I have the feeling that booting an iso, both with or without a vm, would be slower than booting a normal installation.
-
OK if i would remaster the iso with the stuff i need inside, i could use norestore to just boot the iso without the hard drive stuff correct ?
I have the feeling that booting an iso, both with or without a vm, would be slower than booting a normal installation.
Ok but if i use the new made iso with the vm to install it on a hard disk, then it should be faster because the extensions dont have to be loaded (and verified) correct ?
Also what boot codes would help with skipping hardware detection ? like unnesseray hdds and mouse etc (NOTE: I need USB detection)
Would you be willing to share your fast booting vm/quemu vm ? Maybe i could use it as a base.
I will report back later with the timeing.. of dmesg
Thanks
-
Would you be willing to share your fast booting vm/quemu vm ? Maybe i could use it as a base.
I booted the stock iso using the qemu extension.
-
Hi Crunch3D
... For the extensions i would have to extract them and put them into the /usr/local/ folder correct ? ...
If you remaster the ISO place the extensions in:
cde/optional/and add their names to:
cde/onboot.lstcde tells the system it's a read only directory. It is for ISOs only.
If you install to a virtual disk place the extensions in:
tce/optional/and add their names to:
tce/onboot.lst
Can we deavticate validation of tces at startup ?
Sure, delete all of the .tcz.md5.txt files in the tce/optional/ directory. However, that also means you can't check for
and perform any updates since the MD5s are used to check if newer versions of extensions are in the repo.
I suppose you could rename them all from .tcz.md5.txt to .tcz.md5.text:
for f in Path/To/tce/optional/*.txt; do mv -- "$f" "${f%.txt}.text"; doneThat way you could always name them back if you wish to check for updates.
By the way:
tc@E310:~$ sudo cache-clear
tc@E310:~$ time md5sum > /dev/null /mnt/sda1/tce/optional/*.tcz
real 0m 8.59s
user 0m 1.82s
sys 0m 0.81s
tc@E310:~$ ls -l /mnt/sda1/tce/optional/*.tcz | wc -l
482
tc@E310:~$Calculating 482 MD5s only took 8.6 seconds on my old Dell Dimension E310.
-
I think the majority of openssh's loading time comes from generating the host keys. If so, OP's issue is not with extensions but with not having the host keys saved.
-
Hi all
Sorry for not responding so long, got sick and had much stress at work...
I just wanted to let you know i managed to remaster pureCore64 and make it boot in 4 seconds to text console in vmware. With the whole Vmware startup it takes about 6-7 seconds to be useable.
I managed to use UEFI boot to cut down on like 4 second boot time time traditional vmware bios. I used this thread here: http://forum.tinycorelinux.net/index.php?topic=22410.15
This worked like a charm. With syslinux.
Also i remasterd the ssh keys into the image so ssh will start a bit faster i hope.
i use there bootparamters:
APPEND tce=sda1/tce blacklist=pcspkr noswap embed noapm hdb=noprobe hdc=noprobe hdd=noprobe noisapnp nofirewire nopcmcia no_debug_objects i8042.noaux logo.nologo nohibernate sdb=noprobe sdc=noprobe sdd=noprobe floppy=0 noisapnp nofirewire nopcmcia cdrom=0 tce=UUID="5B61-DAC0" quiet
However i would like to cut down the boot time even further:
- Is it possible to deactivate the extension loading ? Like this takes nearly a second at boot time. As all extensions are remasterd in the base image is it possible to skip the search for exensions ?
- After tty appears it takes roughly another 2 seconds for ssh to be functional. Is it possible to load it earlier in the boot process ? where would i need to put it ?
- Also the detection of hard disks takes like 1 second but there is only sda1 to detect so.... Can we deativate HardDrive detection completely and only detect USB-Devices ?
- Is the tce= boot parmater corretly set ?
You can try it out here if you want: https://drive.google.com/file/d/15fuFOqoqN30yRkp8eijphxtdUAoAyZ7I/view?usp=sharing
[EDIT]: Added code tags. Rich
-
You're getting to the point where achieving further gains needs deep surgery. As such we can't really give you step by step instructions.
-
Hi Crunch3D
... i use there bootparamters:
APPEND tce=sda1/tce blacklist=pcspkr noswap embed noapm hdb=noprobe hdc=noprobe hdd=noprobe noisapnp nofirewire nopcmcia no_debug_objects i8042.noaux logo.nologo nohibernate sdb=noprobe sdc=noprobe sdd=noprobe floppy=0 noisapnp nofirewire nopcmcia cdrom=0 tce=UUID="5B61-DAC0" quiet
... - Is the tce= boot parmater corretly set ? ...
1. You have 2 tce= boot codes listed, tce=sda1/tce and tce=UUID="5B61-DAC0". I would remove the first one.
2. I don't think these are valid boot codes "hdb=noprobe hdc=noprobe hdd=noprobe". Where did you find them?
3. I don't think these are valid boot codes "sdb=noprobe sdc=noprobe sdd=noprobe". Where did you find them?
4. Where did you find this "cdrom=0" ?
5. Using "floppy=0" is not necessary. It's not scanned by default.
If you unpack core.gz you will find etc/init.d/tc_noscan.lst:
tc@E310:~$ cat /etc/init.d/tc_noscan.lst
cdrom
swap
pts
fd
ntfs
sr0
sr1
sr2
sr3
tc@E310:~$You will see cdrom and fd (floppy) are already on the list of items not to scan. You could add the unwanted hard drives
to the list and repack core.gz.
-
IMHO: how hard (knowledge, time consuming) could it be to just compile a new TC kernel specificaly for a minimal VM (qemu or vmware) with just the necesary drivers USB/SATA, virtual network, UEFI frame bufer etc? Does it take more than 20-30 minutes, starting with make noconfig?
If I remember corectly, the defunct aboriginal linux boot in less than ONE second. So your play range is 1-3 seconds gain for booting. Eficiency focused, the max 3 seconds/boot, booting 4 times/day, then your max posible gain will not be "recovered" in 600 days, so near 2 years! If you devoted just 2 hours in total, to tune-up it: 3600 sec/h * 2 h/day / (3 sec/boot x 4 boots/day) =600. Q.E.D.
-
It's not very hard, but can take time if you haven't done it before (or if the machine you're compiling on is slow).
-
Maybe not many TC entusiants / users have fast hardware to compile (I don't have it). And yes, the "S"- shape curve to learn about kernel configuration is too sharp for common TC users.
So maybe TC TEAM could think about a kernel optimized for Qemu. The kernel will be small (fast to load) because it does not need firmware, the VIRTUAL drivers lot is limited (chipset, HDD, network, sound) in options. The drivers can even be compiled inside the kernel, not loaded as modules. The rest is just the same, root + tcz. And I think i386 (i686?) is just enough for a VM/qemu.
Just saying. Why should 1000 users waste time and resurces, when an emeritus TC team can do it in minutes (results remain for life!). We talk about just kernel. If you do not belive this is in demand, for small/ optimized TC kernel for qemu, then lets vote for it.
-
On my five year old laptop "make bzImage" takes about one hour..
-
Not really said, or I didn't catch it, is what is the ultimate hardware target for this. Is it ESX, VMware, or some actual hardware and we're just tuning it in a VM first? Also, to complicate things a little more, somewhere in the kernel config is an option for an initrd. It is possible, because I've tried it, to use the TC core.gz image as the initrd instead of the default. It makes the kernel bigger obviously, but then there isn't a second step during the boot process of loading additional files. Your best hope for quickest boot is a kernel with the TC ramdisk and all the hardware modules you will need compiled and no extraneous ones. If you need USB support you will need to decide if you need it a boot, or if it can wait until after boot to load those modules when something is plugged in.
-
On my five year old laptop "make bzImage" takes about one hour..
Is this maybe because you tried to compile the kernel together with all its 1000 drivers?
from http://landley.net/toybox/downloads/binaries/mkroot/0.8.4/
it seams that for kernel version 5.9, bzimage size is 2.6 MB (not so big), but the trick is how to compile the kernel with just the drivers that you/qemu needs: see file x86_64.miniconf# make ARCH=x86 allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
# make ARCH=x86 -j $(nproc)
# boot arch/x86/boot/bzImage