Overlay initrd files using cat

[btheado]

I stumbled across http://lxr.linux.no/linux+v2.6.37/Documentation/early-userspace/buffer-format.txt and discovered the initramfs buffer format supports multiple gzipped cpio archive files concatenated together.

This means a gzipped cpio archive can be 'overlaid' on top of another archive using nothing more than 'cat'.  The alternative to using cat is to use gunzip, cpio, gzip and requires sudo to preserve the file permissions.

So tinycore.gz could be constructed from microcore.gz and the .gz files at http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/microcore/ like this:

Code: [Select]

cat microcore.gz Xlibs.gz Xprogs.gz Xvesa.gz > tinycore.gz
Maybe that is already the way tinycore.gz is created--I don't know.  I just tried it and  I either did something wrong or there is some other difference in tinycore.gz because it booted into X but there was no wbar and mouseclicks on the background didn't produce a menu.

I use this method to maintain an alternate version of tinycore.gz usable with colinux.  As described at http://forum.tinycorelinux.net/index.php?topic=7348, I needed the kernel modules that match the colinux kernel and I needed a small patch to /usr/sbin/rebuildfstab in order to load extensions from colinux cobd devices.

I used sudo+cpio+gzip to create colinux-modules.gz containing the kernel modules and rebuildfstab patch.  Now that I have that file, I can upgrade to new versions of tinycore using just 'cat' (assuming my rebuildfstab patch doesn't interfere with any future tinycore changes).

A small convenience, but I find it useful.

[roberts]

You are missing a window manager and icons, flwm_topside and wbar both which are currently extensions, although could be made into cpio .gzs.

[roberts]

I quite like this concept as currently flwm.tcz, flwm_topside.tcz, and wbar.tcz are really pseduo extensions as they do not install to /usr/local. They really are core compenents of Tiny Core and their use is really only viable via Micro Core.

By moving them to .gzs not only is the advantage of quick and easy tinycore.gz creation but more importantly all of Micro Core compenents will be archived together. See: http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/archive/?C=M;O=A

As it is now, by being extensions, only the latest version is available in the repository which might cause issues with prior versions of Micro Core, i.e., a mismatched set of compenents.

Of course there is absolutely no impact to Tiny Core users.

Look for this change in v3.5 of Micro Core.

[gerald_clark]

Your previous post had me thinking too.

Actually, you would not need two distributions.

Tiny Core / Micro Core CD can simply be a boot option.

A nogz boot option could suppress loading of the included gz files from the CD.
Then you could include a boot menu on the CD that allows you choose TC or MC.

When creating a persistent tce directory, the user can include the X*.gz if desired,
and use or not use the nogz boot option.
They can still select Xvesa vs Xorg, and the window manager of choice.

[tinypoodle]

Of course there is absolutely no impact to Tiny Core users.

Not sure if I entirely understood.
Is the case of Tiny Core users which would currently prefer to make use of flwm (as opposed to flwm_topside) included?

[btheado]

Tiny Core / Micro Core CD can simply be a boot option.

A nogz boot option could suppress loading of the included gz files from the CD.
Then you could include a boot menu on the CD that allows you choose TC or MC.

The concatenation of the gz files needs to have been done prior to boot (unless the bootloader has some way of concatenating or of passing in multiple initrd which the kernel would concatenate).  Or are you thinking something different like changing MC init scripts to load the extra gz files?

[tinypoodle]

What would the need or advantage of concatenating be - versus just passing multiple cpio archives to the kernel by the bootloader?

[btheado]

If the bootloader can pass multiple cpio archives, that is better, I think.  Does that functionality exist?  A quick search didn't give me the answer.  I only found this link which made me think the functionality is not prevalent in bootloaders: https://bugs.launchpad.net/qemu/+bug/393569.

Once the archives are concatenated, the kernel can handle it fine--that's all I know.

[tinypoodle]

If the bootloader can pass multiple cpio archives, that is better, I think.  Does that functionality exist?

Yes. Not entirely sure if supported by every bootlader.

For example with sylinux family bootladers:

Code: [Select]

initrd=tinycore.gz,my_initramfs1.gz,my_initramfs2.gz

Works fine for me with linld as well, despite not having seen it documented anywhere.

Edit: Content of your link appears to refer exclusively to Qemu, so the issue might be rather about emulation than about real life circumstances.

[gerald_clark]

It has nothing to do with the boot loader.
The TC/MC init scripts load any .gz files found in the tce directory.

http://wiki.tinycorelinux.com/Adding+a+Desktop+to+MicroCore

[roberts]

There is nothing new with the handling of .gzs.

It has and remains SOP to specify either in the boot loader for those that support it or as Gerald has posted in the tce/ directory.  Not with the extensions in tce/optional.

The only difference is that I am moving the pseudo extensions, as I stated above, to gz.
If you want to run Tiny Core and desire flwm then simply place flwm.gz on the boot loader line or in the tce/ Although it would be more efficient to use Micro Core and gzs.

[gerald_clark]

That will eliminate the slightly troublesome problem of tce-update downdating wbar.tcz on the release candidates.

[roberts]

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.

2. Continue to offer tinycore.iso

TinyCore the ISO will continue to be offered and will boot into the usual X(vesa), flwm_topside, and custom fltk system programs. It will however be constructed from microcore.gz, Xlibs.gz, Xvesa.gz, Xprogs.gz, flwm_topside,gz, and wbar.gz

3. Eliminate the microcore.iso. Instead add the nogz boot code for booting the tinycore.iso into microcore.

Benefits from the above

* More modular extends the philosophy of the toolkit approach.

* More flexible as a toolkit, e.g., no need for Xvesa, don't include it, No need for wbar don't include it, etc...

* Possible smaller downloads. Only download the components that you need or have been upgraded.

* Easier to remaster as no need to unpack tinycore.gz to remove unneeded component(s).

* Better documentation possible with a single modular construction kit approach. As it is now, many ask for documentation specific for microcore. Having a singular approach should lessen duplication and confusion caused by such.

* No visible impact to those using or booting from the iso.

[frimical]

great !
TC is getting to be more coherent and mature.
Just one suggestion, why not go further, up to the 'core' of the concept of tc as a toolkit, and gain more coherence and flexibility all the way, by splitting microcore, and create 'CLIprogs.gz' in the same spirit of 'Xprogs.gz'? (everything that is specific and tailor made for tc,  like tc's utilities, scripts and so... ).

[gerald_clark]

About the only command line progs in MC are busybox and the other programs necessary for the init scripts.