pxe image fails to boot: "Forbidden directory"

I had a 9.10 vmware VM and my clients was booting with PXE.
Then I upgraded to 10.04 and my clients stop booting for "permission" problems.
I do a ltsp-build-clients but that do not solve.
After some google search, I look at /etc/default/tftpd-hpa
Here i see that tftp folder now is /srv/tftp (before it was TFTP_DIRECTORY="/var/lib/tftpboot")
I look at /srv/tftp and see that all files are there with right permission.
Also, in /etc/default/tftpd-hpa now i have TFTP_OPTIONS="" while before was TFTP_OPTIONS="--secure"
I put TFTP_OPTIONS="--secure" than
sudo service tftpd-hda restart

Now my clients boot

Sorry for bad english, hope this help.

Thanks so much Inno for your suggestion. I get much further with that. I definitely think that ltsp-server-standalone should configure that correctly. Unfortunately the 9.04 options are completely different and I blew away my 9.10 install with the 10.04 one, perhaps too optimistically. And your English is fine!

Now I'm left with a 500 MB image, and the notation in /opt/ltsp/ltsp-update-image.conf that
 # By default, do not compress the image
# as it's reported to make it unstable
Well, that may be so, but as I expected, this seems too big to boot either of my clients. I'm going to try changing the arguments in the above .conf file (which are for squashfs), and making a smaller image. But I need to do it when my family isn't using my nicely functioning ltsp system under 9.04 and I have some time!

Update on the bug: it's still not working, on either of my clients,
so I'm running 9.04, the last version that worked out-of-the-box.
It boots and gives a login screen, but logging in fails, and the
server logs show "nbd_server: Disconnect request received" which
google tends to link to nbd bugs, for the most part. I was able
to compress my image below 200 MB, and I even tried the 9.04 image
which failed. I'm going to try the server distribution; if that
works, I'll see if I can add the GUI parts I need rather than use
workstation and add ltsp.

You may be thinking, what a newbie, can't even make Ubuntu work!
It's really not true--I used Unix from 1976, Linux from 1992,
and ltsp at least since Redhat 7.1 in 2001, according to my notes.
The easiest configuration I ever did was with Ubuntu 8.04 to 9.04.
9.10 failed on one of my clients, and 10.04 is a complete bust.
I'm still installing Ubuntu for friends and family...but I may try
another distribution next...

Some ideas why logging in could fail:
 * If for a second it says "server not responding, restarting..", then it might be an ssh-keys problem, which you normally solve with sudo ltsp-update-sshkeys && sudo ltsp-update-image.

 * If you do see that "not responding" message, and updating the ssh keys doesn't solve it, try putting
[Default]
  SCREEN_02=shell
  SCREEN_07=ldm
in lts.conf. Reboot the client, switch to vt2 by pressing Alt+Ctrl+F2 and enter this command:
  ssh _user_@server
Replace "_user_" with an existing username, but leave "server" as it is without replacing it with your actual server name or IP.
This command should allow you to login without producing any warnings at all. If you do see a warning then it's still an ssh keys error.

 * If it appears to be logging in but then X crashes and you get back to the login screen, you may find some hints on that user's ~/.xsession-errors.

 * A very frequent problem with the same symptoms as yours is caused by compiz, which is enabled by default on Ubuntu. Try entering the following command to disable it:
  sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity
No reboot necessary, neither on the server nor the client. Just enter that command on the server and try to login on the client.

If you still have no luck, try the LTSP IRC channel, it's very helpful on troubleshooting such problems:
http://webchat.freenode.net/?channels=ltsp

Thanks a lot Alkis for your suggestions. The compiz proved to be the key
trick. Let me explain what finally needed to be done to get my two clients
running, for posterity. Client A is a desktop with a A7V8X-MX motherboard,
AMD Athlon XP, circa 2003. Client B is a Dell Inspiron 8100 laptop with the
hard drive removed. Both are booting with the onboard PXE capability.
If you have older clients running older versions of LTSP/Ubuntu, listen up.

First edit /etc/default/tftpd-hpa and change the TFTP_OPTIONS:
TFTP_OPTIONS="--secure"
then restart service: sudo service tftpd-hpa restart
(This seems like a bug that Ubuntu should fix!)

Try running after this if you're feeling lucky! I wasn't, for either client.
Run Alkis' suggested command to disable compiz:
sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity

Try running again. My client B worked, but not A. You may notice that your
image is 500 MB whereas in earlier versions of LTSP/Ubuntu it was 200 MB!
Edit file /etc/ltsp/ltsp-update-image.conf and change the NO_COMP definition to be
NO_COMP="-no-exports", which will restore squashfs compression. Run
sudo ltsp-update-sshkeys
sudo ltsp-update-image --arch i386
(Omit the --arch i386 if you're not building a 32-bit client.)
This got both my clients running, and B boots 3 seconds faster.

For general debugging I recommend also doing:
sudo cp /opt/ltsp/i386/etc/lts.conf /var/lib/tftpboot/ltsp/i386/lts.conf
and then adding the lines Alkis recommends above into the /var/lib version.
It's a lot easier to get error messages from the console than from flashing
X displays!

The only thing left not working for me is sound on client A. In .xsession-errors
it complains about "/usr/bin/asoundconf: not found" which is true.
Package asoundconf-gtk doesn't provide this either. I'm not a heavy user
of sound on this client, though.

As far as I know, this bug consists of three separate bugs, one in tftpd-hpa (==when installing from the alternate CD tftpd-hpa uses /srv while when installing from the desktop CD it uses /var/lib/tftpboot), one in compiz, and a sound problem.

So I'm marking it invalid for LTSP and I'm putting tftp-hpa in the affects list.

Tim please file separate bug reports for any bugs you see, it makes it easier for people to handle them in launchpad.

Hi Alkis--

I installed from the desktop CD, not the alternate, and tftpd set up for
/srv. I don't know what the contract is between the various Ubuntu
services like tftp and the many (Ubuntu and custom) applications that
might use them. I assumed that it would be the responsibility of the
LTSP packages to verify the configuration of any services such as tftp
that they need and re-configure if necessary. Hence I assumed it was a
bug in LTSP. Similarly, I don't know if compiz is supposed to function
with a wide range of remote clients of possibly limited hardware. So
I'd also file that one under LTSP, myself. Sound...it's working pretty
well on my desktops. Haven't looked into the ltsp client problem yet!

So it's not that I don't try to file separate bug reports...it's just
not always easy to figure out what package is at fault! :)

--Tim

On 07/10/2010 01:39 AM, Alkis Georgopoulos wrote:
> As far as I know, this bug consists of three separate bugs, one in
> tftpd-hpa (==when installing from the alternate CD tftpd-hpa uses /srv
> while when installing from the desktop CD it uses /var/lib/tftpboot),
> one in compiz, and a sound problem.
>
> So I'm marking it invalid for LTSP and I'm putting tftp-hpa in the
> affects list.
>
> Tim please file separate bug reports for any bugs you see, it makes it
> easier for people to handle them in launchpad.
>
> ** Also affects: tftp-hpa (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: ltsp (Ubuntu)
> Status: New => Invalid
>

tftpd-hpa installs by default with /var/lib/tftpd-hpa as its directory, but that behavior can be changed by a debconf preseeded value.
I can't see any issue in tftpd-hpa itself... Alkis, could you explain in more details ?

Ccing strgraber, since he worked on making LTSP and tftpd-hpa work together during the Lucid cycle...

I did not see the issue myself, but the reporter and another person (comments #1 and #2) say that for them, /etc/default/tftpd-hpa contained "/srv/tftp" instead of the expected "/var/lib/tftpboot", and that caused the message "forbidden directory" to be displayed.

I don't know under which circumstances that happens, so I cannot provide any feedback - it's up to the reporter to provide any details necessary. Maybe on same cases the debian/tftpd-hpa.templates file isn't used?

There are also other problems in this bug report (compiz, sound etc) but I think that the "major" one that's also reflected in the title is related to tftpd-hpa, that's why I thought it should be moved here.

I explain better.
At work I have a VM with ubuntu 9.10 that is an upgraded from a 9.04.
With 9.04 i had 2 working clients that do not work with 9.10 (they were old and have been replaced now).
One client was not able to boot and the other had sound problems.

Then, for testing purpose, i tried at home a copy of the same VM after upgrading to 10.04.
The result was that no clients (old and newer) were able to boot and I had the "forbidden directory" error.
Searching for the cause, I found the mentioned /etc/default/tftpd-hpa where i see the path to /srv/tftp.

In my 9.10 VM (still in use), that folder do not exist and in my 10.04 test VM, I have both /srv/tftp and /var/lib/tftpboot.
But that is not the cause of the "forbidden directory" error in my case.
I wanted tell about the changed folder because that was not obvious to me (I still have /var/lib/tftpboot) and knowing that, maybe can help...
I do not know the situation on a fresh (not upgraded) 10.04 installation.

How I had say, the cause of my problem was the mentioned TFTP_OPTIONS="--secure" that was missing in my 10.04 after the upgrade.
After adding that option, the "forbidden directory" error had gone and my (newer) clients boot with 10.04

For the old amd K6-2 not booting...I found that upgrading to 64Mb of ram, make it able to boot again (compiz is automatically disabled if it can't be run).
The other (an old notebook) now have not the sound problems that I had with 9.10

Upgraded server from 8.04 LTS to 10.04 LTS on 8/21/2010. Server was running LTSP with 8.04. Same issue with clients not able to access tftp directory. The fix suggested by Inno to change the directory and add "--secure" worked (THANK YOU!):

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
#TFTP_DIRECTORY="/srv/tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
#TFTP_OPTIONS=""
TFTP_OPTIONS="--secure"

Changed the two lines and issued "sudo ltsp-update-kernels" plus "sudo restart tftpd-hpa".

Since it just happened, I would consider it still a bug in the upgrade process for systems with LTSP.

I do not changed the directory from "/srv/tftp" to "/var/lib/tftpboot".
I only added the "--secure" option and checked the content and permissions of the new directory (they were all ok).
Maybe, the two directory are equals after the upgrade and the old "/var/lib/tftpboot" can be deleted but I have not do that.

Looking into it, in Karmic and before, tftpd was started with:
OPTIONS="-l -s /var/lib/tftpboot"
start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- $OPTIONS

And now it runs with:

TFTP_OPTIONS=""
start-stop-daemon --start --quiet --oknodo --exec ${DAEMON} -- --listen --user ${TFTP_USERNAME} --address ${TFTP_ADDRESS} ${TFTP_OPTIONS} ${TFTP_DIRECTORY}

So it lacks the "-s" (or "--secure") by default.