I have about 500 hrs in this over the past 6 years
which is one reason I stuck with 3x as its the
only version I ever had near zero problems with.
As I attempted to move to 4x issues like this
forced me to stick with 3x. When 7x came out
I figured I'd try 6x and see if it had this "bug"
?feature? fixed but no such luck.
Here is the objective using a DOS metaphor
we all learned when we were in our early 30's
and MSDOS 1.0 was invented....
a) you edit a file called autoexec.bat and
b) when the system boots it runs a batch file
This was a throwback to codes we commonly
put in UNIX and old IBM/VAX boot up scripts on
mainframes and it worked ok...so well many
Windows users found out 20 years later folks
loved injecting viruses into Windows start up
folders...and when that was "fixed" by Symantec,
they went after the registry, then the boot loaders,
boot tracks, and drive firmware as NSA does today...
In other words, getting something to fire on boot
is appealing to many people for many reasons.
Now we turn to Tiny Core Linux and documentation
PUT IT IN BOOTLOCAL.SH or BOOTSYNC.SH
and you're done.
Which is inaccurate or ineffective, as it requires
a persistent OPT= folder on the CD which means
.tce_dir can't get written and no extensions work.
(3x version) or other problems pop up. So much
nicer when we don't have to muck up the original
distro and fs...much. Unfortunately, all the codes
like root= (instead of grub4dos --find-root which
is cleaner) or tce= (which assumes you know the
drive) or uuid and all that other rather cryptic
and unpredictable stuff - as that all changes with
new media)...none of that works well across
multiple systems and multiple devices.
So a boot code? i.e. using grub4dos menu.lst syntax
kernel /tce/boot/vmlinux (or bzImage) init=/tce/init.sh waitusb=5 quiet etc. etc.
...that'd would be really kewl.
I looked at init - a shell script in the root and it'd be easy enough
to add a line or two there, and if ONLY the code that
gave TC a clue as to where to get the script to run on
boot and it DID that before loading extensions - or after;
either way is fine...
...that'd be great...but me thinks would require a remaster.
So far, 500 hours into this and I have yet to get a CD
run a script at boot.
I tried using /opt/bootsync and bootlocal and a bunch
of other stuff dies anytime opt= becomes a ro on a CD;
...sys not happy.
What is really fun to watch is qemu -cdrom isoname.iso
which mounts it as hdc and runs every extension no
problem, though the startup.sh issues remains unsolved.
In short, TC runs a CD better in QEMU than on real iron.
I can't get a /tce/onboot.lst extension to load from
a CD with either /tce/onboot.lst or /cde/onboot.lst
to save my life, let alone fire off a shell script on boot,
Any questions - I'll provide answers...but me thinks
the easiest way to handle this would be to somehow
integrate the init=root_relative_scriptpath/scriptname.sh
method and we'd be done.
Anyone ever get that to work?