Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: gmc on May 02, 2013, 12:10:16 PM
-
Greetings,
I am ready to set up a permanent PxE server using TCL. My problem has to do with persisence. I have read the wiki and searched the forums but the more I read the more confused I get. Much of the information I find seems to apply to older versions of TCL. What I need is a clear explanation of how to set up TCL to automatically start the terminal server at boot time with all the required settings in place. I want it to start with the modified menu.c32 'default' menu and the related support files (boot images) already in place.
I would be most grateful for any assistance.
-
Mys suggestion is to use dnsmasq to do your dns, dhcp, and tftp.
Configure it to serve files off your hard drive.
-
Hi gerald_clark - Thanks for the quick reply. I played with dnsmasq quite a bit and it looks good - but what I need now is help with persistence and auto-start. Once I have those mastered the sky's the limit.
-
Hi gmc
Add the commands you use to start the PXE server to your /opt/bootlocal.sh file. Add any config files you modified to
/opt/.filetool.lst.
-
http://wiki.tinycorelinux.net/wiki:persistence_for_dummies
You can add startup code to /opt/booltocal.sh.
-
Once configured, I replace binaries in netboot (i.e. kernel, initrd's and syslinux binaries) by symlinks, then add "netboot" to /opt/.filetool.lst.
-
Hi Rich, gerald_clark and tinypoodle. Thanks for all your tips, most useful! As soon as I figure out how to change the HP T5740's DOM from read only to writable I'll begin to implement these ideas. I tried cfdisk and testdisk but they don't appear to have the option to make a drive/partition read only/writeable. My copy of Partition Magic doesn't like the DOM for some reason. So I am off to search for a good tool for the job...
Thanks again for you help!
-
Hi all - I have been reading lots and testing as I go. I have two areas I am not clear on:
1. What are the startup commands I would use to start the PXE server?
2. How are the symlinks used in this particular setup? (I understand the theory and command syntax but not the actual how-to details.)
A doctor friend used to say that to learn a surgical procedure they were taught to "see one, do one, teach one". Well, at this point it would help if I could see some actual steps. Then I can "do one". Who knows, someday I might actually "teach one"! (Scary thought, eh?)
It feels like I am almost there...
-
1. Something like:
sudo udpsvd -E 0 69 tftpd /netboot &
sudo udhcpd /netboot/udhcpd.conf &
2. e.g.:
ln -s /usr/share/syslinux/pxelinux.0 /netboot/
and alike for kernel and initrd's.
-
Great! That is just what I needed.
The code I have in /opt/bootlocal.sh is:
sudo udhcpd /netboot/udhcpd.conf &
sudo udpsvd -E 0 69 tftpd /netboot &
Said code works if I enter it manually in a terminal windows but not automatically at boot time. Any ideas?
Thanks.
-
bootlocal.sh runs as root. Do not use sudo.
-
I have tried it now without sudo - no change. Is there some way to see what is happening at the time bootlocal.sh is read? Any other ideas?
Thanks.
-
Hi gmc
Maybe the network isn't up yet.
-
Hi gmc
This might be helpful:
http://forum.tinycorelinux.net/index.php/topic,14731.msg83695.html#msg83695
-
Rich - you nailed it. The network was not up yet. As a quick test I put Robert's settime.sh script in front of the udhcpd command, saved the bootlocal.sh file and rebooted. As soon as the server was up I rebooted a PXE client - and for the first time ever (here) the client immediately found the PXE server and booted into TCL 4.7.6 (command line interface only).
I have a lot more to learn before I get this server set up the way I want but thanks to all the help from all of you it will happen. Thank you all again so very much.
-
1. Something like:
sudo udpsvd -E 0 69 tftpd /netboot &
sudo udhcpd /netboot/udhcpd.conf &
2. e.g.:
ln -s /usr/share/syslinux/pxelinux.0 /netboot/
and alike for kernel and initrd's.
OK, I tried using the symlink idea but it won't work for me. I first remove the actual file from /netboot (pxelinux.0, core.gz, vmlinuz) and then symlink the source files to /netboot. I can see the symlinks in /netboot but the PXE client can't. The tftp server says file not found.
I have tried changing the files one at a time and when I do the client fails at the point of trying to access the file I have just symlinked. When I put the original source file back in place of the symlink the client can then complete the PXE boot.
Is there another step I need to perform in order for PXE clients to see the symlinked files at boot time?
-
tftpd does not have '/' as its root so the symlinks are not resolved properly.
-
Odd, I couldn't spot a difference in the description to what is working fine for me...
???
-
tftpd does not have '/' as its root so the symlinks are not resolved properly.
Is there a way to fix it?
-
Odd, I couldn't spot a difference in the description to what is working fine for me...
???
??????
I'm not at all sure what you just asked! But it left me smiling...
Would you mind clarifying your question a bit?
-
Not very sure what is not clear...
I could not spot a difference between the description of your procedure not working and my procedure proven to be working.
-
Not very sure what is not clear...
I could not spot a difference between the description of your procedure not working and my procedure proven to be working.
Got it! Now I understand what you don't understand!
Are you using TCL 4.7.7? Maybe the changed tc-terminal-server script has something to do with it? Just a thought...
Ansyway, I booted from CD with 4.7.7, installed to sda1(DOM), rebooted and ran tc-terminal-server. Once that was up and running I deleted the three files from /netboot, ran the ln... command verbatim (copied it from your post and pasted it into aterm just to be sure I got it right). I modified it for core.gz and vmlinuz, verified that the symlinks were actually in the /netboot directory and tried a client PXE boot.
When that did not work I deleted pxelinux.0 symlink and replaced it with the original pxelinux.0. The PXE client found that file but stalled on core.gzz.
Replace dcore symlink with actual source file. PXE client stalled at not finding vmlinuz.
Replaced vmlinuz symlink with source. PXE client booted normally again.
Anything else I can add to make it any clearer? This would not be so important but I only have 113MB of DOM space available on a clean install. It disappears very rapidly when I start installing apps, backing up files, etc.
-
Hi gmc
ln -s /usr/share/syslinux/pxelinux.0 /netboot/
Can you double check that path? Syslinux.tcz lists:
/usr/local/share/syslinux/pxelinux.0
-
No, I haven't tried latest version and my examples may be inaccurate or outdated, but all that does not change anything about the principle of replacing files by symlinks.
My guess would be what gerald_clark already hinted, that symlinks are not resolved properly.
You might want to consider trying to create symlinks using drag'n'drop with an app like rox, where you get visual interaction and feedback.
Clarification: I only use absolute symlinks, not relative ones.
-
Hi gmc
ln -s /usr/share/syslinux/pxelinux.0 /netboot/
Can you double check that path? Syslinux.tcz lists:
/usr/local/share/syslinux/pxelinux.0
Yes, double checked and verified. For what it is worth, I replaced the pxelinux.0 in /netboot with the one from /usr/local/share/syslinux and PXE boots still worked, so I believe I am sourcing the symlink from the correct pxelinux.0
-
No, I haven't tried latest version and my examples may be inaccurate or outdated, but all that does not change anything about the principle of replacing files by symlinks.
Agreed, and it is a principle I want to apply here.
My guess would be what gerald_clark already hinted, that symlinks are not resolved properly.
Maybe I should do a packet trace and see what is actually being sent as the file name? That might be very revealing...
You might want to consider trying to create symlinks using drag'n'drop with an app like rox, where you get visual interaction and feedback.
I'll do it.
Clarification: I only use absolute symlinks, not relative ones.
Good point, thanks.
-
My guess would be what gerald_clark already hinted, that symlinks are not resolved properly.
Maybe I should do a packet trace and see what is actually being sent as the file name? That might be very revealing...
1) Different tftpds may respond differently with symlinks. If run chroot-style, it won't resolve the symlinks at all. I recall having to do a bind-mount which I think was for a tftpd configured to do a chroot after start.
2) If the tftpd has /netboot as its root and you want to boot /netboot/pxelinux, specifying "pxelinux.0" for the DHCP/BOOTP field file is perfect.
-
1) Different tftpds may respond differently with symlinks. If run chroot-style, it won't resolve the symlinks at all. I recall having to do a bind-mount which I think was for a tftpd configured to do a chroot after start.
2) If the tftpd has /netboot as its root and you want to boot /netboot/pxelinux, specifying "pxelinux.0" for the DHCP/BOOTP field file is perfect.
Hi genec,
In answer to #2 above: "If the tftpd has /netboot as its root..."
It does.
"...and you want to boot /netboot/pxelinux..."
I do.
I am including my udhcpd.conf file. Perhaps that is what you are refering to?
udhcpd.conf:
=========================
# The start and end of the IP lease block
start 192.168.0.111
end 192.168.0.122
# The interface that udhcpd will use
interface eth0
boot_file /pxelinux.0
opt dns 192.168.0.1
option subnet 255.255.255.0
opt router 192.168.0.1
option lease 864000 # 10 days of seconds
option tftp 192.168.0.17
siaddr 192.168.0.17
===========================
EoF
Of course pxelinux.0 is only part of the problem, core.gz and vmlinuz can't be found when symlinked, etiher. I don't know if that will make any difference or not in relationship to what you wrote.
Please know that what I say next is said with all kindness and admiration, no sarcasm here.
You are obviously highly intelligent and very knowledgeable about linux (which I admire and am envious of). But this mere mortal is way below your esoteric knowledge base. Could you, would you, translate what you just wrote into something I might be able to comprehend? Maybe with an example or two? I think I can almost make sense of it but a bit more help would maybe, just maybe get me over the top.
Thanks so much for taking the time to give the information you have already, and thanks for any further clarification you may give.
-
gmc, thank you.
1) There's no need for the leading "/" generally on your filename.
2) What you're seeing is exactly what I spoke of (and others have alluded to). If "/netboot/vmlinuz" is a symlink with a value of "/path/to/vmlinuz" and the tftpd operates chroot style in /netboot, it'll hunt for the file "/netboot/path/to/vmlinuz". There are 4 basic resolutions:
a) copy the files to /netboot.
b) change the tftpd's root to another directory. This probably won't save any RAM assuming all of the files are in the rootfs in RAM (unless you wanted to drop all of your files in 1 directory on persistent storage).
c) use another tftpd. This would require that you disable dnsmasq's built-in tftp and use another like atftpd/tftpd-hpa.
d) use a hard link (which is 2 filenames pointing to the same file data) rather than a symolic link (which is just special text saying what other path to examine) and works reasonably within 1 file system but can be very dangerous across file systems (extensions are additional file systems)
If you have persistent storage you can use for the files, option (b) is probably your best bet. Otherwise, option (a) is probably the easiest (at least for the moment) seeing as you've already got the beginnings of something working.
-
@genec
I have been taking a short break from this issue while I try to get Xorg set up for larger fonts/desktop, etc. I didn't want you to think I was ignoring your last post. I have been thinking about which of your options would be best for my situation. Once I have my desktop setup working the way I need it then I can focus (pun intended) on this issue again.
In the meantime, thanks for your help.