Mods input needed on disk activity (theoretical)

[CentralWare]

Hi Rich!

Sadly, what you noted is in fact true...  to a fault.
When booting via PXE or in cases where boot media does not have tce= specified, if another device contains /opt and such, it tends to throw things off horribly by somewhat "merging" the two or completely skipping the boot media's intentions entirely by booting from it, then turning control over to the second device.  I'll be fixing that while I'm in here

I'm currently dissecting tc-config (stock) and ripping it into separate files to organize and sort the functionality of the boot-up sequences.  (/etc/init.d/boot/files where /etc/init.d/tc-config simply runs find | sort and launches each segment individually so things can be monitored, paused, bypassed, etc. with the least amount of hunting.)  Somewhere in here I'll find an answer...  a bit of hay in a needle-stack, though!

Thanks for your ongoing feedback and take care!

~TJ~

[Rich]

Hi centralware
You are probably already aware of this but I'll mention it anyway. There is a second file called  tc-functions  which contains subroutines
that are called by  tc-config. I recommend that you leave that file as is since it is also used by other scripts.

[mocore]

  Hear is the path of and a link  to :
 #git.tinycorelinux.net/index.cgi?url=Core-scripts.git/tree/etc/init.d/tc-functions

[coreplayer2]

Picture a classroom.  There's roughly 30 workstations where by themselves, they boot from a read-only version of TC (most likely SD card, CD, CF card, etc.) and if nobody is logged into the station, it loads into a basic kiosk (desktop, browser and a few low-end utilities.)

Now, let's say a student parks it in front of the same machine.  They whip out their USB device (which in this case looks like a thick business card, similar to the smart-card design, with an embedded flash of so many gigs.)  The LABEL and UUID on this device are unknown

I understand re the UUID however..
If you issue the USB device or the image to install to a USB device then you have discretion of naming the file system LABEL of your choosing




Sent from my iPhone using Tapatalk

[CentralWare]

@Rich: Thank you for your response.  The tce= portion of code is in a different file (/u/l/b/tce-setup I believe) and I'm still knee deep in tc-config at the moment.  I believe I might have come up with a solution though, which should be reasonable (wait-time wise)
1) Right before udevadm is triggered, inventory block Ids
2) Launch the trigger.  Plug-n-Pray, hot-swap, etc. begins
3) Start a timer loop, monitoring block devices for NEWLY created ones compared to the above list.
    IF FOUND, stop the timer and launch udevadm settle and wait for hardware to finish
    IF NOT FOUND, expire after the ~5 second delay OR when usb hubs AND PORTS are found
4) If new block devices are found, mount-test them for the flag file
    IF FOUND, replace the command line tce= opt= and other codes as needed.

This is the theory at least!  Once I'm done dissecting tc-config I'll have time to run this route.

[gerald_clark]

You cannot change the contents of /proc/cmdline.

[CentralWare]

It's actually not all that difficult to do (though it's a hack, technically)

Build a new cmdline and bind-mount it on top of the old.  Works like a charm and it becomes transparent to apps/scripts globally.
All I do is parse the old /proc/cmdline and set aside the initrd segment.  Variables/values are swapped out, added, etc. and for sake of safety, the init is added to the end of the line.  ($commands in the following)

Code: [Select]

echo $commands > /etc/sysconfig/cmdline
mount -n --bind ro /etc/sysconfig/cmdline /proc/cmdline
If done within tc-config, then setting CMDLINE=$commands becomes prudent as well.