Overlay initrd files using cat

[frimical]

this is what I meant. what's made for tc {even the init script) and what is not.
busybox and all other libs and so apart.
At the first glimpse, my suggestion may sound like a total nonsense.

[gerald_clark]

You cannot extract out the progrms that are needed to load the programs.

[maro]

Robert, sounds like a good plan. I guess the boot time should not really suffer too much from having to uncompress multiple gz-files before extracting the cpio archives. Or have you already done a comparison? If it makes a difference there is always the option to remaster again an "old-style tinycore.gz".

One thing I'm personally not sure about is the name of the boot code: Whilst "nogz" is short and I'm always in favour of typing fewer keystrokes that I could get wrong, the name is maybe not a good representation of what it means. Sure those are gzip-ed cpio archives, that form together an initrd. But the fact that gzip was used to create them does not really point towards what might be achieved by using this boot code. AFAIK there are alternative compression formats (e.g. bzip2 or LZMA) that could have been used. In light of this I wonder whether something like 'core', 'micro' or 'nox' (as in "no X server") are more to the point.

[roberts]

I agree micro is a better choice for the new boot code.

As I see it the benefits, as I have enumerated, out weight the slight performance hit on booting. And If, as you said, the user can always repack ala remastering and with just the components required.

[gerald_clark]

I just used nogz as an example ( do not load any gz files ).
I think 'micro' or 'mc' are quite descriptive of the intent.

[curaga]

In my measurements, the effect of catted initramfs was 6% longer cpio extraction time.

[roberts]

The 6% represents the following average time:

extract single tinycore.gz cpio 1.234 seconds
extract multiple cpio 1.312 seconds

We are talking on average a difference of 78ms.

[Michael Wells]

After having time to reflect on Gerald's suggestion for a single ISO distribution, this is what I thinking:

Extend the toolkit approach by:

1. Eliminate a prebuilt tinycore.gz

Only the.gz, as such is not needed. However, if desired, it can easily be rebuilt by using 'cat' as shown above in this thread, or one can unpack the cpio archive(s) and repack as is known from Wiki docs on remastering.

My two cents worth ...

While I for one do not want to stand in the way of progress ... I read the suggestion by Roberts to eliminate the pre-built tinycore.gz with a little apprehension.  I never use an iso to boot up tc.  I always drop the bzImage and the tinycore.gz into my boot area and use grub menu to configure a number of boot up modes.  I like being able to drop in the latest tinycore.gz without changing anything else and so far I have not experienced problems with startup scripts breaking. 

I hope that the tinycore.gz is not eliminated as it is what I use primarily and I will guess the majority of users are tinycore rather than microcore users, correct me if I am wrong.  Having to download and cat a number of gz's to boot seems to make it unnecessarily complicated for users who like to keep things simple when one is not using an iso. 

[roberts]

I appreciate the comments and concerns. While no decision is final until a final release is cut. Many times during release candidates I try new options. Most recently it was mfm which was replaced by fluff.

But to address the concern of having to cat several files...
No need to do such. No need to overly complicate grub with multiple .gzs either.

With the proposed 'more modular' method you would change grub entry from tinycore.gz to microcore.gz and then in your tce base directory include only those components needed, e.g. Xlibs.gz and Xprogs.gz.

If you do not use Xvesa, then no need to download it and load it upon each boot.
If you do not use flwm, then no need to download it and load it upon each boot.
If you do not use wbar then no need to download it and load it upon each boot.

This is a proposal. So comments and concerns are welcomed.

[roberts]

It has already been expressed to me the need to keep offering microcore.iso and I agree.

[tinypoodle]

There would be an impact in 2 other aspects not mentioned so far:

1. Cases - besides from CD boot - in which a /tce would not have been used so far.
A particular case I can think of is netboot (using pxelinux).
My estimation is that in specific case it might be most suitable for users who have already a customized permanent routine to just append the extra cpio archives in the boot config file. 

However, an adaption to reflect the changes in 'tc-terminal-server' might be in order for firsttimers.

2. For those who at current are booting tinycore with help of a DOS based linux bootloader like e.g. loadlin or linld, 'microcore.gz' - as opposed to 'tinycore.gz' - could not be directly used without adapting the filename to the 8.3 naming scheme.

Just my thoughts, by no means implying that the already mentioned benefits - first of all a more finetuned choice - could not outweigh some minor inconveniences.

[tinypoodle]

Having to download and cat a number of gz's to boot seems to make it unnecessarily complicated for users who like to keep things simple when one is not using an iso. 

An alternative approach could be to download the tinycore .iso, loopmount it and then copy the [selected] contained cpio archives and the kernel.

[gerald_clark]

Those using PXE boot will not have to add the additional cpio archives to the boot config file if they are using an NFS based tce directory.
The init scripts will find them and load them just as they would on a HD or USB based boot.

I PXE boot microcore all the time, and I only have bzImage and microcore.gz in my boot config.

[Michael Wells]

With the proposed 'more modular' method you would change grub entry from tinycore.gz to microcore.gz and then in your tce base directory include only those components needed, e.g. Xlibs.gz and Xprogs.gz.

If you do not use Xvesa, then no need to download it and load it upon each boot.
If you do not use flwm, then no need to download it and load it upon each boot.
If you do not use wbar then no need to download it and load it upon each boot.

Roberts: Thank you for responding to my query about making booting into tinycore.gz more complicated ... however, unless I misunderstand, I still fail to see how the 'more modular' method simplifies things for me as I do use Xvesa, flwm and wbar since they come default in tinycore ... and having to download these components separately and put them in my tce base directory ... seems to me like a step towards further complexity ... when all I have to do at present is download tinycore.gz and I get all I want in one download.

I have no stats ... but I would guess the vast majority of tinycore users are using the tinycore setup as it is in the default tinycore.gz/iso without getting rid of the core components included therein or adding new windows managers, and other system components except for user apps.

This 'modular approach' seems to me a neat trick that would appeal most of all to those who like playing around at more or less remixing their own tinycore.gz, starting with microcore.gz but is that the tinycore market target?

I think that tinycore.gz as the tc base cpio filesystem should continue to be offered and the modular options available to those who want to play around in that area.

My humble opinion.

[robc]

when all I have to do at present is download tinycore.gz and I get all I want in one download.

Perhaps a base update script could be used to wget all the current files? That would make it pretty easy to update.

Are there any more files in the base that would be editted and backed up? (not including those that are meant to be backed up, ie bootlocal.sh)