TC fromISOfile boot rocks!

[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]

I'm probably the only guy who uses it,...

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

[Leee]

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

Seems like it would be nice to be able to specify what onboot.lst to use on the kernel command line.

onboot.CLI.lst
onboot.90s-doorstop.lst
onboot.kiosk.lst
etc, etc

[Rich]

Hi Leee

Seems like it would be nice to be able to specify what onboot.lst to use on the kernel command line. ...

Yes, if only there were a boot code like:

Code: [Select]

lst=SomeName.lst
Oh wait, there is.

[PDP-8]

Rich - right!  And therefore no need for multiple "pre-packaged" iso's.  Just manipulate the onboot.lst as long as your tcz library on the other iso has the needed packages for the different environments.

Is there anything TC can't do? 

Maybe this is morphing into a slightly different question - that of maintaining a local library as we build sticks doing different stuff, so we aren't so redundant downloading the same thing over and over.

I mean - I do - I archive tcz's as I fool around on my "library stick", so I can be nice to the repo when I rebuild other projects.

Just thinking, an automated option for a user to have a "library stick" of their own just sitting there off to the side on an open usb port, automatically archiving tcz's as they play around, and when they DO try to download LibreOffice for the 20th time, TC grabs it from the library stick first.

So maybe this is a different question - sorry about that.  My initial thoughts were about archiving, and not pre-packaging...

Probably needs a different thread - but the "libary stick" could be smart, and inform the user when they try to make a system out of CorePlus installer "TCZ installation from the library not possible when booted frome the CorePlus installer.  Use a non-installer environment".

Something like that - a little automation to reduce the dev workload explaining stuff over and over.

[Leee]

Yes, if only there were a boot code like:
Code:

lst=SomeName.lst


Oh wait, there is.

Well, don't I feel silly now.