General TC > Remasters / Remixes - Unofficial
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:
--- Quote from: centralware on August 27, 2014, 06:27:08 PM ---Q1: Is this direction already an option and I've just missed it in my boot command research?
--- End quote ---
No, that would go squarely into the "very custom hacks" category :)
--- Quote ---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)?
--- End quote ---
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.
--- Quote ---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.)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version