InstantCore

[jazzbiker]

Greetings!

I want to propose pre-installed image of CorePlus-14.0 and TinyCorePure64-14.0. New users may benefit burning it to the USB flash drive and obtaining ready to use various flavours of Core at the single drive in normal read-write mode, with backup and restore available, normal tce-load -w and so on. The image is dual-boot BIOS/UEFI, includes both x86 and x86_64 distribution files, proposes Core, Core64 and Corepure64 modes depending on Your hardware.

You can download an image from Google Drive :

https://drive.google.com/file/d/1X2y2RZRLArrqcpy8XfC4SMN0nlvDmMl0/view?usp=sharing

An image was packed following an approach already implemented in piCore images. When You burn this 600M image to for example 32G flash drive You have absolutely functional but restricted in free space (less than 200M) environment. If You are absolutely new to TinyCore You may continue experimenting with it. But if You want to utilize the whole drive space You need to perform few simple steps:

1. Load into "base+resize". You will see clear command line prompt.
2. Run "inflate.sh" script.
3. Reboot and continue with the full drive capacity accessible.

Please ask Your questions, and have Merry Christmas!

[gadget42]

your description of the expansion of the working partition reminded me of EasyOS

https://easyos.org/tech/how-easy-works-part-2.html

At the first bootup, the initrd increases the size of the working-partition to fill the drive, and creates some folders in it...

[jazzbiker]

Hi gadget42!

I was following the way piCore developers deal with unallocated drive space :-) Of course expanding/inflating may be unconditional, but probably in some (maybe afew) cases it may be inappropriate, I guess.

Another thing done after inflating is filesystem's UUID shuffling. Cloned image assumes cloned UUID, not good for regular use. Maybe separating these tasks is possible, in order to have possibility to change the UUID without inflating the filesystem.

[core-user]

Seasons Greetings - this sounds like how I have set up a Ventoy pendrive - except for expanding & using free space - downloading now, thanks.

[jazzbiker]

Hi core-user!

If You are on the short leg with Ventoy You may try it with InstantCore. In case of success it may be attracting, as Ventoy can boot even the boxes with "secure boot = on", as far as I've read some time ago.

Happy Holydays!

EDIT: I want to warn You about using inflate.sh while running from Ventoy! I can not predict exactly what may happen, because I am not using Ventoy, but I guess inflate.sh will cause some kind of disaster (

[Rich]

Hi jazzbiker
I mounted your image file and did a little poking around.
Just some observations:
It contains partitions 1 and 3 but skips 2:

Code: [Select]

tc@E310:~/Downloads/tmp$ sudo losetup --show --find --partscan InstantCore.img
/dev/loop296
tc@E310:~/Downloads/tmp$ sudo lsblk -f /dev/loop296
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
loop296                                                       
|-loop296p1 vfat         E28D-73DA                           
`-loop296p3 ext4         f6bff2ef-e204-46cd-a3e5-c86f6ca5073bProbably not an issue, it just seemed odd.

There are 2 versions of  rootfs.gz:

Code: [Select]

tc@E310:~/Downloads/tmp$ for F in `sudo find P3 -name rootfs*`; do ls -l $F; done
-rw-r--r-- 1 root root 3498790 Dec 25 01:40 P3/boot/14/0/3/0/rootfs.gz
-rw-r--r-- 1 root root 3470570 Dec 24 02:56 P3/boot/14/0/3/rootfs.gz
-rw-r--r-- 1 root root 3523605 Dec 24 02:56 P3/boot/14/0/6/rootfs64.gz

[jazzbiker]

Hi Rich!

It contains partitions 1 and 3 but skips 2:

Code: [Select]

tc@E310:~/Downloads/tmp$ sudo losetup --show --find --partscan InstantCore.img
/dev/loop296
tc@E310:~/Downloads/tmp$ sudo lsblk -f /dev/loop296
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
loop296                                                       
|-loop296p1 vfat         E28D-73DA                           
`-loop296p3 ext4         f6bff2ef-e204-46cd-a3e5-c86f6ca5073bProbably not an issue, it just seemed odd.

I think it is not an issue, too. I create the drive partitions and filesystems with the help of the script - grub4tc.sh. My defaults are:
sdx1 - grub
sdx2 - boot
sdx3 - tce

The script asks for boot partition size and if it is zero, then sdx3/boot is used for distribution files. sdx2 appears to be absent.

I did in such a manner because distribution files are not necessary after the boot finished, and keeping them in the separate partition I guess slightly decreases the risk they will be damaged accidentally. Still TC default is /boot directory, so I decided to follow the default TC scheme for InstantCore.

There are 2 versions of  rootfs.gz:

Code: [Select]

tc@E310:~/Downloads/tmp$ for F in `sudo find P3 -name rootfs*`; do ls -l $F; done
-rw-r--r-- 1 root root 3498790 Dec 25 01:40 P3/boot/14/0/3/0/rootfs.gz
-rw-r--r-- 1 root root 3470570 Dec 24 02:56 P3/boot/14/0/3/rootfs.gz
-rw-r--r-- 1 root root 3523605 Dec 24 02:56 P3/boot/14/0/6/rootfs64.gz

Yes, You are absolutely right. 32-bit version (/boot/14/0/3 subtree) includes two versions of rootfs.gz. The upper one is the default one, while /boot/14/0/3/0/rootfs.gz is used during "base+resize" boot menu option and is slightly customized: resize2fs and inflate.sh are added to the official rootfs.gz. So inflate.sh can be used only during "base" boot when not a single disk partition is mounted and all partitions are free to play them with.

Thanks for review! Merry Christmas!

[Rich]

Hi jazzbiker

... /boot/14/0/3/0/rootfs.gz is used during "base+resize" boot menu option and is slightly customized: resize2fs and inflate.sh are added to the official rootfs.gz. So inflate.sh can be used only during "base" boot when not a single disk partition is mounted and all partitions are free to play them with. ...

Ah, that makes sense.

Merry Christmas to you too.

[jazzbiker]

Hi!

As far as I understand at this moment, nothing prohibits to write InstantCore to the hard drive. EFI grub is installed with "--removable" option which only means that such hard drive will work with any EFI motherboard. In such an application InstantCore seems to be the easiest way to install TC to the local hard drive. It may be test-driven and configured in the USB drive incarnation and then immediately self-copied to the hard drive. Only if the box is intended to be TinyCore only :-) Which is not bad but in opposite is very good.

Not yet tested, if anybody will find some obstacles, please warn me.

If /home must be persistent, the dedicated partition on the hard drive may be created with some gap from sdx3 (tce partition) and after image copying inflate.sh will fill the gap.

Looks of that kind. Or not?

[Rich]

Hi jazzbiker

... If /home must be persistent, the dedicated partition on the hard drive may be created with some gap from sdx3 (tce partition) and after image copying inflate.sh will fill the gap. ...

Persistent  home  and/or  opt  don't need to be put on separate partitions.

Anytime I do a Tinycore install, it gets its own partition with:

Code: [Select]

boot/  home/  lost+found/  opt/  tce/An entry for this install gets added to grubs  menu.lst  file.
Then home, opt, and tce get populated to suit my needs.

[jazzbiker]

Hi Rich!

Persistent  home  and/or  opt  don't need to be put on separate partitions.

Anytime I do a Tinycore install, it gets its own partition with:

Code: [Select]

boot/  home/  lost+found/  opt/  tce/An entry for this install gets added to grubs  menu.lst  file.
Then home, opt, and tce get populated to suit my needs.

Thanks for the explanation, I must have remebered this :-) but I never use persistent /home or /opt.
But what must be the directory structure if You have several TC versions? Partition per version?

[jazzbiker]

Probably directory per version:

Code: [Select]

/boot
/lost+found
/tc10/home
/tc10/opt
/tc10/tce
/tc11/home
/tc11/opt
/tc11/tce
...
?

[Rich]

Hi jazzbiker
I typically do partition per version.
I have also done this when I want a choice of booting
to a 32 or 64 bit environment:

Code: [Select]

/boot
    core.gz
    corepure64.gz
    vmlinuz
    vmlinuz64
/home
/lost+found
/opt
/tce
/tce64I use this for when I want to be able to run one of
my compile scripts to produce 64 bit binaries.

[jazzbiker]

After playing a bit with InstantCore the simple, yet probably silly, question arose in my head:

Why, damn, OSes in general and TinyCore especially are not distributed in the form of really alive filesystems? What is the sacred meaning of dead iso-s?

It is so comfortable and convenient to:
1. dd it to some drive and instantly dive at the full depth.
2. Run it in qemu, perform some tweaking and return to the point 1.
3. Mount in rw mode and adjust manually.

Sorry for me being too emotiional, but I am really astonished.

[CNK]

Why, damn, OSes in general and TinyCore especially are not distributed in the form of really alive filesystems? What is the sacred meaning of dead iso-s?

Well I still write them to CDs. You could include all the functionality of your disk image in a dd-able ISO anyway, catering for the likes of me as well. Dual BIOS/UEFI booting is possible with dd-written ISOs, though it took me quite a while to figure out how to set that up right.

For PiCore I think it would be better to distribute an image as a ZIP containing the OS files which can be unpacked to a preformatted SD card (the default FAT, or re-formatted ext* by the user). Much easier than dealing with disk image writer tools and expanding partitions. I did that for a PiCore-based package that I developed.

But everyone has their own opinions. I believe Puppy Linux switched from ISOs to disk images a while ago, so your opinion isn't unique. That might have turned me off, except I already hadn't tried a new Puppy Linux version in many years anyway.