tc-terminal-server and persistence

[gmc]

1. Something like:

Code: [Select]

sudo udpsvd -E 0 69 tftpd /netboot &
sudo udhcpd /netboot/udhcpd.conf &
2. e.g.:

Code: [Select]

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?

[gerald_clark]

tftpd does not have '/' as its root so the symlinks are not resolved properly.

[tinypoodle]

Odd, I couldn't spot a difference in the description to what is working fine for me...

[gmc]

tftpd does not have '/' as its root so the symlinks are not resolved properly.

Is there a way to fix it?

[gmc]

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?

[tinypoodle]

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.

[gmc]

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.

[Rich]

Hi gmc

ln -s /usr/share/syslinux/pxelinux.0 /netboot/

Can you double check that path? Syslinux.tcz lists:

Code: [Select]

/usr/local/share/syslinux/pxelinux.0

[tinypoodle]

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.

[gmc]

Hi gmc

ln -s /usr/share/syslinux/pxelinux.0 /netboot/

Can you double check that path? Syslinux.tcz lists:

Code: [Select]

/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

[gmc]

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.

[genec]

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.

[gmc]

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.

[genec]

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.

[gmc]

@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.