How to boot/install with extracted core.gz image ? Make boot Faster?

[Juanito]

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

[Juanito]

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.

[Crunch3D]

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

[Juanito]

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.

[Rich]

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:

Code: [Select]

cde/optional/and add their names to:

Code: [Select]

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:

Code: [Select]

tce/optional/and add their names to:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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.

[curaga]

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.

[Crunch3D]

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:

Code: [Select]

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

[curaga]

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.

[Rich]

Hi Crunch3D

... i use there bootparamters:

Code: [Select]

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:

Code: [Select]

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.

[nick65go]

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.

[curaga]

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).

[nick65go]

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.

[Juanito]

On my five year old laptop "make bzImage" takes about one hour..

[andyj]

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.

[nick65go]

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

Code: [Select]

# make ARCH=x86 allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
# make ARCH=x86 -j $(nproc)
# boot arch/x86/boot/bzImage