Not getting correct minimyth.conf from backend
Moderator: Pablo
Not getting correct minimyth.conf from backend
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.
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.
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)?
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)?
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.
It does exist but it's empty (so no it's not my minimyth.conf :-)Does the file /etc/minimyth.d/minimyth.conf exist on the frontend? If so, is it your minimyth.conf 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 followsDoes the log file on the machine running your TFTP server show anything? In particular, is the frontend requesting and receiving the correct file?
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"
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
Code: Select all
in.tftpd: LOCAL, 192.168.1.121
atftpd: LOCAL, 192.168.1.121
'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.On the frontend in /var/log/messages, what is the URL reported as being used to fetch minimyth.conf (search for minimyth.conf)?
As you can probably tell i'm no guru so any suggestions welcome, thanks in advance.
P
It should not be doing that.
If you telnet into the frontend and run the command 'hostname', what is the output?
If you telnet into the frontend and run the command 'hostname', what is the output?
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.
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.
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.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
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.
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.
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.
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.
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.
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
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
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.
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.
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.
Hi!
I had a similar problem while trying MiniMyth v0.21.0-59b2. This is my pxelinux.cfg/default:
When I booted the frontend system, it failed to fetch the minimyth.conf file. I'm using atftpd. In the log, it says:
/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:
The result is, that MiniMyth finds the minimyth.conf file.
This indicates to me that there is a problem either with atftpd or with the "guessing" in MiniMyth.
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
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
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/"
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
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?
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.
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.
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?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.
MiniMyth running on an Acer ApireRevo 3610 and a Zotac ZBOX-ID80-U. Find out more at my MythTV page.