Issues with core.gz rebuilt for PXE

[CentralWare]

I threw together a script which is helping me rebuild core.gz to use in a PXE environment.  (Add/modify files, then cpio, etc.)

/opt/bootsync.sh has been built up to wait for the network connection to settle, to grab the MAC address from ETH0 and to test the network connection until the "master server" answers using wget.  Once done, it passes the buck to a file called /opt/bootpxe.sh which then uses the MAC to identify the machine and based on a PHP system I'm throwing together, it'll use the MAC to build configuration details for the machine to use (similar to choosing between Micro, Tiny and CorePlus.)

In this file, the server is being used for literally everything from sharing repo files down to hosting r/w hard drive images (ext2...  for some reason or another TC4 doesn't like ext3 or above on a non-block-device.)  This got me to thinking...  if I have a file such as server:/profiles/tc4/hdd1_ext2.fs (512MB ext2 formatted drive image) which in a sense is nothing more than a copy of TC's directory structure (and static files that otherwise would require filetool to manage) wouldn't it be wonderful if the drive image itself could be passed to the kernel and that file used as a boot device (similar to a frugal install) and thus skipping all of these otherwise unnecessary steps?

My thought is, if we were able to get the kernel to (via CIFS most likely?) mount the drive and have it rooted ( / ) merging the core.gz contents with the newly mounted contents (mount overwriting core) and voila'...  you have a drive-less machine using external storage in a static-write environment.  (It's not exactly thin-client, but it's a direction I'd like to take!)

Q1: Is this direction already an option and I've just missed it in my boot command research?
Q2: When loading TCZ files, once they're mounted (/tmp/tcloop) are there caveats of deleting those original TCZ files (and DEP/TXT) as to me, they're just taking up memory (storage)?
Q3: For some reason or another, when rebuilding core.gz, tce-load complains about a permission problem under /usr/local/tce.installed (denied) though I've manually set permissions to 775 root.staff in /opt/bootsync.sh as was seen fram a clean install.  Any ideas as to what might be causing this?  (I have it being sent to /dev/null so it's not a major eye-sore, it's just "not right" thus I'm asking.)

Sorry for the multiple post; it just made sense to me to keep things together as opposed to wasting three separate posts for somewhat related content.

Thanks,

TJ

[gerald_clark]

The stock core can pxe boot to an nfs based tce directory.
PXE supports custom config files per MAC.
Please read the wiki article http://wiki.tinycorelinux.net/wiki:netbooting

No remastering is necessary.

[CentralWare]

I went through the netboot wiki again...  it comes close to what's needed, but lacks in a few important areas which are going to require a good deal of administrative time, but using the basic core MAY have potential for automation assuming I do some programming on the server-side to help automate things a bit.  (There are many machines which come and go and many more which are in-house...  creating PxeLinux scripts for each machine on the fly would be rather tedious and opens the door to mistakes.)

To accomplish this, the only thing I can think of is to have a "default" PXE menu which basically loads TCL in all of its glory (base, nothing fancy) and with that, have the bootsync.sh script compare itself (and the NFS mount) to the MAC address it finds on its own hardware.  If the two don't match (which is expected) it asks the server to create a machine account (and the associated PXE menu 01-xx-xx-xx-xx-xx-xx) and once permissions (which have been a nightmare thus far) are set, have the machine leave a little message to the user (if there's someone there) saying "I'm rebooting...  BRB!" and in doing so, should find its dedicated PXE file.

The hitch here is that there's really no organization...  just a bunch of numbers (MAC) so that's going to require further maintenance just to keep things sane and clean.

I imagine the only real cure (following the wiki) is to create TCZ apps of my own to implement the necessary changes, but the remaining question still stands...  when loading TCZ files, if a file already exists (ie: /usr/local/bin/filename) and the loading TCZ has the same file, does it get SKIPPED or does the existing one get overwritten?

Thanks for your time and feedback!

[CentralWare]

Two last questions:

(here's the PXE line for reference)
APPEND initrd=/nfs/boot/test/core.gz nfsmount=server:/tftpboot/nfs/users/test opt=nfs home=nfs tce=/mnt/nfs/tce

1) Since HOME and OPT are seemingly the only root paths allowed in the init string (areas in /usr/local, sbin, etc. are needed here) what do you think (worst case scenario) would happen if say /usr/local were NFS mounted on top of the pre-existing one?  (It's just a thought at this point as making a filetool backup would seem wasteful in CPU time/resources whereas a replica with necessary changes and/or additions would take more drive space on the server, but in theory should reduce load/launch time as "all" of those files are not being used at one time.)

2) Some of the machines I plan to launch are x64 -- any good resources off hand where you'd suggest starting from as TCL doesn't seem to really have an x64 ISO and I have to assume it'll have to be built.

Thanks again!

[curaga]

Q1: Is this direction already an option and I've just missed it in my boot command research?

No, that would go squarely into the "very custom hacks" category

Q2: When loading TCZ files, once they're mounted (/tmp/tcloop) are there caveats of deleting those original TCZ files (and DEP/TXT) as to me, they're just taking up memory (storage)?

Linux does not delete files that are open. If you delete a mounted TCZ, the file will disappear (out of sight, out of mind), but the space won't be reclaimed as the file is still open.

If you used the copy2fs option so that they get extracted rather than mounted, then you could delete them afterwards, but the total space use would be more than mounting.

Q3: For some reason or another, when rebuilding core.gz, tce-load complains about a permission problem under /usr/local/tce.installed (denied) though I've manually set permissions to 775 root.staff in /opt/bootsync.sh as was seen fram a clean install.  Any ideas as to what might be causing this?  (I have it being sent to /dev/null so it's not a major eye-sore, it's just "not right" thus I'm asking.)

Some extension has broken permissions for that dir. If you find out which (boot with "showapps pause" bootcodes), please report it.

Extensions cannot overwrite system files unless explicitly coded to do so in their install script.

For /usr/local mounting, we used to support that in fact. The downside to that is only the clutter of possibly stale files, and the possibility of conflicts (like a symlink in /usr/local that was saved, but now points to nowhere).

I believe we do have 64-bit isos, though the Xfbdev (TinyCore) one was experimental.

[CentralWare]

Thank you VERY much for your insight!

I've written a preliminary web/php system which so far is doing what I had hoped, though there's a lot of tweaking to come.

pxelinux.cfg > default is set up to offer an option to "PXE Install" a machine.  If selected, a normal boot takes place and within the NFS mount (/opt) the bootsync script is set to call the web server with the MAC of the machine.  The web server then propagates a NFS directory and sets up permissions, builds a boot script to add to pxelinux.cfg and reboots.

pxelinux.cfg > 01-xx-xx-xx-xx-xx-xx then takes over.  The menu only lists the TCL and utilizes the newly created NFS along with opt=nfs and home=nfs.  Here, the PHP system has already built a fresh bootsync file which handles installing X and a few basic tools, deletes itself (bootsync) and then reboots.

The final boot lands with a fresh TFTP/NFS based TCL with desktop (though firefox fails for some reason to start "Illegal Instruction" - I haven't dug to see why yet as it's just a preliminary trial run, but since tce-load was used in the second step above, it's assumed dependencies are covered, so I'm guessing permissions again.)

The objective...  or should I say one of many...  is to launch a dozen headless ITX motherboards, have SSH preset during that last boot (DHCP lease info will basically tell which machine is which) and once the PHP system is updated to allow "reformatting" from a desktop to say a hosting (apache) environment, etc. this should work perfectly as needed once the bugs are ironed out.  I may even drag out a couple old VIA C3 (800mhz ITX) motherboards just to see if it's worth resurrecting them for use!  ("If it works on them...  it'll work on anything" type of thinking.)

I've spent the greater of two weeks trying to perfect the PXE installation methods just for TCL.  If this pans out, I'll post the outcome (and setup/files) here as well as I have to assume I'm the only person thinking "automation" when it pertains to PXE/NFS/TFTP/CIFS combined.  (Not to mention I still have to build an administration area to "manage" the content since it's very likely a single machine will, how to say...  "dual boot" via PXE by allowing Admin to swap out NFS directories and boot scripts.)

Thanks again and take care!

[curaga]

"Illegal Instruction": Firefox (or a library it depends on) was compiled for a cpu above what you used. Old Vias in particular hit this often, as they are only 586 compatible, but a lot of software is compiled for a 686.

Some of the Firefox extensions are compiled, some are repackaged from Mozilla. You may need to compile Firefox yourself to get a 586-compatible one. (the repo does require 486, but Firefox is quite a big package to compile, and so it was only repackaged for a while)