Page 1 of 1

Not getting correct minimyth.conf from backend

Posted: Sun Aug 17, 2008 11:03 pm
by paulH
Hi all,

I am running an M10000 frontend with 512MB ram, i am part way through upgrading to 0.21 from 0.20 netbooting with a RAM fs. The 0.20 was working on a fedora 6 backend (and is still working but the backend has been removed from network while i work on the 0.21).

The new backend is a ubuntu Hardy Heron install and i am using the latest 0.21.0-57 build of minimyth.

The minimyth boot stops after displaying the following
[code]error: 'TCode' (or 'MM_DHCP_TCODE') not configured.
error: 'NTP Servers' (or 'MM_DHCP_NTP_SERVERS') not configured.
error: 'MM_THEME_NAME' is not set.
error: 'MM_THEMEOSD_NAME' is not set.
error: 'MM_X_OUTPUT_DVI', 'MM_X_OUTPUT_VGA' and 'MM_X_OUTPUT_TV' are all disabled.
error: 'MM_X_MODE' format is not valid.
error: 'MM_THEME_NAME' is not set.
error: 'MM_THEMEOSD_NAME' is not set.
error: check '/var/log/minimyth.err.log' for further details.
[/code]

All of these variables are set sensibly in the minimyth.conf file on the backend. Telnetting into the box has demonstrated that none of the variables i set in the minimyth.conf on the backend are transfered to the frontend. All of the variables are set to their default value which (sensibly) means that minimyth won't get past this stage.

Thinking it might be minimyth not using the right tftp server for the config files i checked
[code]# cat /etc/conf.d/dhcp
MM_NETWORK_INTERFACE='eth0'
MM_TFTP_SERVER='192.168.1.140'
MM_TFTP_BOOT_URL='tftp://192.168.1.140/PXEClient/'
# cat /etc/conf.d/dhcp.override
MM_DHCP_DOMAIN_NAME=''
MM_DHCP_DOMAIN_NAME_SERVERS=''
MM_DHCP_HOST_NAME=''
MM_DHCP_LOG_SERVERS=''
MM_DHCP_NTP_SERVERS=''
MM_DHCP_TCODE=''
[/code]

the /etc/conf.d/dhcp looks sane (correct ip and location). my inetd line on the backend looks like this
[code]
# cat /etc/inetd.conf | grep tftp
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /tftpboot
[/code]

Which i think is OK (i'm no expert). My dhcpd.conf looks like this
[code]# written by Paul Hoy on 27 May 2007
ddns-update-style interim;
ignore client-updates;
next-server 192.168.1.140; #added 17-08-08 for minimyth 0.21
filename "PXEClient/pxelinux.0"; #added 17-08-08 for minimyth 0.21
allow bootp;
allow booting;

group {
next-server 192.168.1.140; #tftp server IP address
filename "PXEClient/pxelinux.0";
host pippin {hardware ethernet 00:40:63:D7:D9:92; fixed-address 192.168.1.121;}
}
[/code]

This is very little changed from my working dhcpd.conf from my old backend, the addition of the next-server and filename at the top had no effect with or without (they have always been included in the group). I have cropped a section from this file which was only related to other network machines, print server, laptop etc...

My PXEClient.cfg/default looks like this

[code]# cat /tftpboot/PXEClient/pxelinux.cfg/default
DEFAULT minimyth-ram
LABEL minimyth-ram
KERNEL minimyth-0.21.0-57/kernel
APPEND ro root=/dev/ram0 ramdisk_size=96000 initrd=minimyth-0.21.0-57/rootfs
[/code]

the tftboot directory structure is as follows
PXEClient
-conf
--default
---minimyth.conf
---lircd.conf
---various others
-minimyth-0.21.0-57
pxelinux.0
-pxelinux.cfg

At this point i'm somewhat lost as to what to do next, i have tried various combinations of boot parameters/dhcpd.conf variables and have looked in the forums and interweb for further info. I don't think that i have any of the filenames wrong, all the files in tftpboot are owned by root and world readable.

Any help greatly appreciated.

Posted: Tue Aug 19, 2008 5:23 am
by Pablo
Does the file /etc/minimyth.d/minimyth.conf exist on the frontend? If so, is it your minimyth.conf file?

Does the log file on the machine running your TFTP server show anything? In particular, is the frontend requesting and receiving the correct file?

On the frontend in /var/log/messages, what is the URL reported as being used to fetch minimyth.conf (search for minimyth.conf)?

Posted: Thu Aug 21, 2008 8:09 am
by paulH
I will investigate when i get home. Thanks Pablo (and thanks for a great system which i've been using daily for about 18months).

P

Posted: Thu Aug 21, 2008 10:44 pm
by paulH
Does the file /etc/minimyth.d/minimyth.conf exist on the frontend? If so, is it your minimyth.conf file?
It does exist but it's empty (so no it's not my minimyth.conf :-)
Does the log file on the machine running your TFTP server show anything? In particular, is the frontend requesting and receiving the correct file?
I'm using atftpd 0.7 (not inetd as i said previously, i now have a better understanding of what inetd does). atftpd is called as follows

Code: Select all

USE_INETD=false
OPTIONS="--daemon --port 69 --tftpd-timeout 1000 --retry-timeout 5     --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=7  --logfile /var/log/atftpd /tftpboot"
The log reads,

Code: Select all

Aug 21 22:15:00 backend atftpd[8121.-1210954864]: Serving PXEClient/pxelinux.0 to 192.168.1.121:2071
--snip -- (as the minimyth box tries variants on it's MAC address?)
Aug 21 22:15:00 backend atftpd[8121.-1210954864]: Serving PXEClient/pxelinux.cfg/default to 192.168.1.121:57099
---snip -success
Aug 21 22:15:00 backend atftpd[8121.-1210954864]: Serving PXEClient/minimyth-0.21.0-57/kernel to 192.168.1.121:57100
---snip -success
Aug 21 22:15:00 backend atftpd[8121.-1210954864]: Serving PXEClient/minimyth-0.21.0-57/rootfs to 192.168.1.121:57101
Aug 21 22:15:00 backend atftpd[8121.-1210954864]: tsize option -> 68739072
Aug 21 22:15:00 backend atftpd[8121.-1210954864]: blksize option -> 1408
Aug 21 22:15:26 backend atftpd[8121.-1210954864]: End of transfer
Aug 21 22:15:26 backend atftpd[8121.-1210954864]: Server thread exiting
Aug 21 22:15:39 backend atftpd[8121.-1210954864]: Creating new socket: 192.168.1.140:44510
Aug 21 22:15:39 backend atftpd[8121.-1210954864]: Serving /PXEClient/conf to 192.168.1.121:32768
Aug 21 22:15:44 backend atftpd[8121.-1210954864]: timeout: retrying...
Aug 21 22:15:44 backend atftpd[8121.-1210954864]: recvmsg: Connection refused
Aug 21 22:15:44 backend atftpd[8121.-1210954864]: tftpd_file.c: 926: recvfrom: Connection refused
Aug 21 22:15:44 backend atftpd[8121.-1210954864]: Aborting transfer
Aug 21 22:15:44 backend atftpd[8121.-1210954864]: Server thread exiting
I suspect the problem is here where it gets a connection refused while serving the conf directory (slightly confused as conf is a directory and the minimyth.conf is in a subdirectory). I have tried a number of things to solve the connection refused, including various different permissions on the /tftpboot directory (recursively), differing ownership of the directory, i have also included the following in hosts.allow in case that makes a difference (deny is empty and allow is empty other than these lines).

Code: Select all

in.tftpd: LOCAL, 192.168.1.121 
atftpd: LOCAL, 192.168.1.121
On the frontend in /var/log/messages, what is the URL reported as being used to fetch minimyth.conf (search for minimyth.conf)?
'minimyth.conf' is not referenced in /var/log/messages on the frontend. # cat /var/log/messages | grep minimyth.conf displays nothing and a manual search also turns up nothing.

As you can probably tell i'm no guru so any suggestions welcome, thanks in advance.

P

Posted: Sat Aug 30, 2008 8:52 pm
by phreeky
I just came across this problem too, my first experience with minimyth.

Anyway, it turns out that minimyth is looking for the config file AT /minimyth/conf, not within that folder.

Posted: Sat Aug 30, 2008 10:13 pm
by Pablo
It should not be doing that.

If you telnet into the frontend and run the command 'hostname', what is the output?

Posted: Sun Aug 31, 2008 1:55 am
by phreeky
Tell me about it, that doesn't match the documented behaviour at all. However, as you can see from my log below, that's what it was trying to get and failing, and my "fix" (read: hack) worked.
Aug 30 15:49:48 lounge01 atftpd[17588]: Serving /minimyth/conf to 192.168.0.1:32768
Aug 30 15:49:48 lounge01 atftpd[17588]: recvmsg: Connection refused
Aug 30 15:49:48 lounge01 atftpd[17588]: tftpd_file.c: 926: recvfrom: Connection refused
As for the host name, no I'm not setting in DHCP nor the boot line, but instead the conf file - which is quite backwards if that's the cause for it not getting the conf file in the first place, as the doc specifically mentions that this can be done.

Posted: Sun Aug 31, 2008 2:13 am
by Pablo
Could you provide the output of the 'hostname' command?

MiniMyth tests to see whether or not the output of the hostname command is empty. If it is empty, then it skips the request for the request for the hostname specific minimyth.conf file. Therefore, MiniMyth thinks that the hostname is is non-empty yet the hostname is empty.

As as result, it could be helpful to know the output of the hostname command as requested. Without it, I have little chance of tracking down why this is happening.

Posted: Sun Aug 31, 2008 5:04 am
by phreeky
My apologies, I didn't realise where you were coming from.

When I go by the doc and have minimyth.conf in the correct location, which it fails to retrieve, 'hostname' returns '?'.

When I set the hostname in that config file and name it in place of the conf directory (like mentioned earlier), it does pick up the MM_DHCP_HOST_NAME parameter and 'hostname' returns 'minimyth_01' as expected.

Posted: Mon Sep 01, 2008 10:05 pm
by paulH
I'm still having the same problem (although i haven't had much more time to investigate). And i now realise that it was looking for a config at minimyth/conf rather than a sub directory.

My frontend is also replying with a hostname of ? The Hostname is specified in the DHCPD config on the backend so it should be picking it up (my previous version does on a different backend).

When i specify MM_DHCP_HOST_NAME in the backend pxelinux.cfg/default the frontend now has a sensible frontend name and responds correctly to 'hostname' via telnet. This solves the problem.

So i guess the question is why is it not getting the hostname from the dhcp server. I am using dhcp3-server on ubuntu feisty fawn (long term service - if that makes a difference). version 3.0.6.dfsg-lubuntu9 if anyone is interested.

Thanks for the help (i will continue to be around and am happy to try stuff if needed).
P

Posted: Wed Sep 03, 2008 12:27 am
by Pablo
Thanks for the information. It appears that the hostname utility returns '?' when the hostname is not set. I do not recall it doing that. Maybe it is a change in more recent versions of busybox.

Anyway, I have modified the scripts so that they convert '?' to ''. This should fix the problem.

I am not sure why the client is not setting the hostname sent by DHCP. I use the 3.0.5 version of the ISC DHCP server on CentOS 5.2 and it works fine.

Posted: Sun Sep 28, 2008 7:45 pm
by cptspock
Hi!

I had a similar problem while trying MiniMyth v0.21.0-59b2. This is my pxelinux.cfg/default:

Code: Select all

LABEL minimythram
	MENU LABEL MiniMyth 0.21.0-58 RAM
	KERNEL minimyth/kernel
	APPEND ro root=/dev/ram0 ramdisk_size=96000 initrd=minimyth/rootfs
When I booted the frontend system, it failed to fetch the minimyth.conf file. I'm using atftpd. In the log, it says:

Code: Select all

Sep 28 20:17:22 canberra atftpd[9728]: Creating new socket: 192.168.31.2:1057
Sep 28 20:17:22 canberra atftpd[9728]: Serving srv/tftpboot/conf/default/minimyth.conf to 192.168.31.51:32768
Sep 28 20:17:22 canberra atftpd[9728]: File /srv/tftpboot/srv/tftpboot/conf/default/minimyth.conf not found
Sep 28 20:17:22 canberra atftpd[9728]: Server thread exiting
/srv/tftoboot is my tftp root directory. As you see above, I do not pass any boot line argument to MiniMyth. So MiniMyth "guesses" the path wrong. The problem is, that MiniMyth doesn't need to know the root path of the tftp root. It should look in the conf/default directory.

Than I changed this in pxelinux.cfg/default:

Code: Select all

LABEL minimythram
	MENU LABEL MiniMyth 0.21.0-58 RAM
	KERNEL minimyth/kernel
	APPEND ro root=/dev/ram0 ramdisk_size=96000 initrd=minimyth/rootfs MM_DEBUG="yes" MM_MINIMYTH_BOOT_URL="tftp://192.168.31.2/"
The result is, that MiniMyth finds the minimyth.conf file.

Code: Select all

Sep 28 20:26:43 canberra atftpd[9728]: Creating new socket: 192.168.31.2:1059
Sep 28 20:26:43 canberra atftpd[9728]: Serving conf/default/minimyth.conf to 192.168.31.51:32768
Sep 28 20:26:43 canberra atftpd[9728]: End of transfer
Sep 28 20:26:43 canberra atftpd[9728]: Server thread exiting
This indicates to me that there is a problem either with atftpd or with the "guessing" in MiniMyth.

Posted: Mon Sep 29, 2008 10:05 pm
by Pablo
MiniMyth guesses the location based on the DHCP filename option (the option that returns the location of pxelinux.0). To what value have you set this in your DHCP server configuration?

Posted: Mon Oct 27, 2008 7:46 am
by cptspock
Hi!

Yes, your are right. The value 'filename' in my dhcpd.conf file is set to '/srv/tftpboot/pxelinux.0'. That is correct for me. If set to anything else, the system wouldn't find the files during boot process.

To me it seems, that atftpd uses that directory as its root directory. So you can not enter directories outside that one. Maybe other tftp server handles this differently.

For me, it is OK the way it is, as long as it is written down somewhere.

Posted: Mon Nov 03, 2008 5:50 pm
by Pablo
cptspock wrote:Hi!

Yes, your are right. The value 'filename' in my dhcpd.conf file is set to '/srv/tftpboot/pxelinux.0'. That is correct for me. If set to anything else, the system wouldn't find the files during boot process.

To me it seems, that atftpd uses that directory as its root directory. So you can not enter directories outside that one. Maybe other tftp server handles this differently.

For me, it is OK the way it is, as long as it is written down somewhere.
This is very odd. Either the DHCP server of the TFTP server is translating /srv/tftpboot/pxelinux.0 to /pxelinux.0. Otherwise, the file would not be found relative to the TFTP root (/srv/tftpboot). Does it work when you use either /pxelinux.0 or pxelinux.0?