Tiny Core Extensions > TCE Tips & Tricks

TC fromISOfile boot rocks!

(1/2) > >>

PDP-8:
Rather than reply in thanks to an 8 year old thread, just wanted to say the ability to use embedded extensions from within an iso file rocks with CorePure64-11.1

I'm probably the only guy who uses it, but what a timesaver.  I've spent much time hacking my own tce directories because I multiboot an iso (just so the iso gets recognized at all as a boot option on uefi-only box in the first place), which while successfully booted, they don't automatically recognize where the extensions are. Afterwards.

Seems like Roberts (any myself) noted this in YUMI.  Even so, I progressed to VENTOY, but even though boot is successful, picking up the embedded extensions just makes me work a little harder with my own hacks.

But he solved that issue:

http://forum.tinycorelinux.net/index.php/topic,12786.msg69982.html#msg69982

I totally get it now.  I used the bootcode, got it working, ran tce-setdrive, and then modified my /opt/bootsync.sh file.

Beautiful baby!

Somewhere Roberts is laughing at me for spending a year hacking my own tce, and not reading the faq *slowly*...  :)

Now that's what I call FUN!

 

hiro:
hah, never noticed this feature either

PDP-8:
I think it is because when people see anything iso, they assume booting, and not the true purpose of this bootcode picking up the embedded extensions contained within an(other) iso.

I also tested it at the command line and that worked great too.

So it's funny - I use Ventoy to initially boot an iso due solely to my unique requirements.  Then, once booted, use this specific boot code to pick up the embedded extensions from another iso on a different filesystem to kickstart them. :)

emmi:

--- Quote from: PDP-8 on July 22, 2020, 05:46:48 AM ---I'm probably the only guy who uses it,...

--- End quote ---
No.

PDP-8:
Sometimes suffering opens new doors!

What intrigues me about this, is the fact that all we are doing is picking up the embedded tcz from within another iso.

My initial tests used the same bootable iso to do so.  BUT, since all we're doing when we point to the secondary iso is embedded tcz's, there seems to be no reason that this secondary iso needs to be bootable!!!

It just needs the proper filestructure to hold them, without any bootable baggage.

So - and this needs to be tested - a kinda different way of setting up TC without straying beyond the norm or trying to turn it into something completely different:

1) Boot as normal.  Whether you use a front-end like Ventoy for my one specific case with one piece of hardware is immaterial.  99% of TC users can just burn-n-boot the iso for their semi-older hardware.

2) On another stick, you have non-bootable iso's that may be dedicated solely to providing embedded tcz's for a specific purpose.  You gather up the tcz's you need for a specific environment like:

a) CLI-only box iso
b) 90's simplistic workstation (core/X/Xterm/TWM) iso
c) Browser-kiosk iso
d) Multimedia iso
e) Developer tools iso

and so forth.  This means that like the multibooters, you would probably want to make a multi-menu grub on our boot stick.  Or just have good memory and manually use the boot: iso= code.

Of course this means the end user would need iso-building tools.  Again, not necessarily to boot, but to just be a simple archive iso.

Hmm....  just thinking - if you were to develop a bunch of things like this, it is likely you would build up a local library of tcz's to put together for the iso environment desired depending on need.  Now you wouldn't be hammering the repo all the time.

So something intriguing is there.  Not sure if this is wasting my time or re-inventing the wheel, so have to think about it...

Navigation

[0] Message Index

[#] Next page