/etc/sysconfig/tcuser file not found [4.4rc2]

[philip]

I'm getting the error message in the subject line when trying to netboot Core 4.4 RC 2. Suggestions welcome; here are some details.

My TFTP setup correctly delivers the pxelinux to the client, and both the kernel (vmlinuz) and the initrd (core.gz) get loaded OK. Then it gets interesting. Here is cat /proc/cmdline:

Code: [Select]

initrd=core/core-4.4-initramfs.gz pause host=samsung tftplist=192.168.2.115:/ltsp/i386/core/tce/tftpboot.lst BOOT_IMAGE=core/core-4.4-vmlinuzThis shows that I'm delivering the basic GUI extensions using the built-in TFTP functionality of /etc/init.d/tc-config. Here is my file tftpboot.lst (sorry about the long prefixes--go ahead and ignore them):

Code: [Select]

ltsp/i386/core/tce/optional/915resolution.tcz
ltsp/i386/core/tce/optional/Xvesa.tcz
ltsp/i386/core/tce/optional/Xlibs.tcz
ltsp/i386/core/tce/optional/Xprogs.tcz
ltsp/i386/core/tce/optional/fltk-1.10.tcz
ltsp/i386/core/tce/optional/flwm_topside.tcz
ltsp/i386/core/tce/optional/wbar.tcz
ltsp/i386/core/tce/optional/openssh.tczThe client loads these files correctly, but with Xlibs the error messages start: the file /etc/sysconfig/tcuser is not found, and after that (perhaps *because of* that?) the path /home/root is tried and that fails also.

Thanks for any ideas.

PS: Trying this with Core 4.3 gave me a much bigger challenge: kernel panic! So I'm pretty enthusiastic about the new kernel that will come along with 4.4.

[curaga]

The tftp/http options load extensions early enough that the system is not yet set up to handle startup scripts properly.

If you don't need functionality that early, I'd suggest loading the extensions yourself in bootsync.sh (/bootlocal).


I'm not sure whether the *tp loading could be moved to right before the usual extension setup. Gerald, are there any gotchas in your uses?

[gerald_clark]

Tftp/http loading of extensions was intended to assist in setting up other storage methods.
I will look at the code, but I would suggest using nfs to host a tce directory, and use the normal
onboot.lst.

[philip]

Thanks, gerald_clark, for your offer to reconsider the sequencing in the boot configuration. I was looking for quick and easy access to a setup that is as minimal on the server side as TC is on the client. I'm just embarking on a little project where -- eventually -- a carefully remastered initrd will make the nfs connection obsolete, so I was hoping to get by without running additional services.

Knowing that the current situation is a deliberate consequence of careful design makes me willing to live with it. (But if the design turns out to be improvable, let's do that.)

curaga's comments inspired me to make my own tcz-extension containing my tcz-acquiring and tce-loading commands, and then loading *that* by tftp. I put all those commands into a replacement copy of /opt/bootsync.sh, hoping the new version would be in position by the time the initscript had to execute it. Alas, I had a learning experience instead of a success: the unsquashfs command apparently refuses to overwrite a file that already exists. (And this is clearly a Good Thing!)

Deep into esoteric thinking now, I wonder if there would be any good reason for a boot option that directs TC to use *tp to go get a list of commands that should be run as root just before the setup process calls bootsync.sh. (You could generalize to insert such *tp-enabled hooks at various stages in the process; an early one could provide a versatile alternative to the nfs-initializer now in place.) Just a thought.

Thanks for your comments.

[curaga]

use *tp to go get a list of commands that should be run as root

Why yes, "DNS poisoning"