Hi Jason, I use device names rather than UUIDs in all of my linux images but I’ve never actually had to use the instructions at the end - I gave it as a worst case scenario.
For ext4 filesystems, they stash the UUID in the superblock so I think that i why they still work - you could probably continue to use UUIDs for ext filesystems, I just choose not to.
The other thing is, swap is just swap. You can blow it away and recreate it with pretty much no system impact.
UUIDs are supposed to be unique, the simplest way around is to use a device name rather than a UUID in /etc/fstab. To find the device names you could do something like
[CODE]
$ blkid
/dev/sdb1: UUID=“b5383030-0990-4386-a694-288f1f67cb5c” TYPE=“ext4”
/dev/sdb2: UUID="4349ed6e-d556-4ba8-a7b6-31dcfb46c0bf" TYPE="swap"
[/CODE]
Then fire up your favourite editor and replace
[CODE]
UUID=4349ed6e-d556-4ba8-a7b6-31dcfb46c0bf swap swap defaults 0 0
[/CODE]
with
[CODE]
/dev/sdb2 swap swap defaults 0 0
[/CODE]
replacing /dev/sdb2 with /dev/sda2 or whatever you find in the output of blkid.
In general I replace the UUIDs with the device names when making a new linux image (for all partitions not just swap). When I’m about to upload I boot my linux image one last time and…
[LIST=1]
[]fsck all the filesystems
[]adjust the fstab as above
[]stash the ssh_host_ keys
[]remove any persistent device names under /etc/udev/rules.d
[]yum clean all or apt-get clean
[*]…
[/LIST]
It makes the linux images a bit more portable. I’ve never run into problems adjusting the fstab, but in principal if you use /dev/sda and the next client system enumerates the disks differently you could. It wouldn’t be hard to fix though - just boot a rescue CD and edit fstab again.
[B]It takes me so long to type that this post is completely irrelevant now. Solved above :).[/B]
I think you’ve already checked this, but it sounds like permissions on /tftpboot, you need both read and execute set on the directory, e.g.
[CODE]
$ ls -ld /tftpboot
drwxr-xr-x. 2 fog root 4096 Jun 17 14:46 tftpboot
$ ls -l /tftpboot
total 2592
-rw-r–r–. 1 fog root 840 Jun 17 14:46 boot.txt
-rw-r–r–. 1 root root 296 Jun 17 14:46 default.ipxe
-rw-r–r–. 1 fog root 389702 Jun 17 14:46 ipxe.kkpxe
-rw-r–r–. 1 fog root 389750 Jun 17 14:46 ipxe.kpxe
-rw-r–r–. 1 fog root 391231 Jun 17 14:46 ipxe.krn
-rw-r–r–. 1 fog root 389766 Jun 17 14:46 ipxe.pxe
-rw-r–r–. 1 fog root 25340 Jun 17 14:46 memdisk
-rw-r–r–. 1 fog root 16794 Jun 17 14:46 pxelinux.0.old
-rw-r–r–. 1 fog root 165088 Jun 17 14:46 snponly.efi
-rw-r–r–. 1 fog root 102777 Jun 17 14:46 undionly.kkpxe
-rw-r–r–. 1 fog root 102825 Jun 17 14:46 undionly.kpxe
-rw-r–r–. 1 fog root 382650 Jun 17 14:46 undionly.kpxe.INTEL
-rw-r–r–. 1 fog root 102841 Jun 17 14:46 undionly.pxe
-rw-r–r–. 1 fog root 147728 Jun 17 14:46 vesamenu.c32
[/CODE]
Assuming that is all OK you should be able to run tftp in the foreground to check for errors,
[CODE]
$ service xinetd stop
$ /usr/sbin/in.tftpd -vvv -s /tftpboot -L
[/CODE]
Then from another shell on your fog server try the get (in a directory where you have write permissions!)
[CODE]
$ tftp fog.stat.ubc.ca
tftp> get pxelinux.0.old
tftp> quit
$ ls -l pxelinux.0.old
$ -rw-r–r–. 1 root root 16794 Jun 20 15:31 pxelinux.0.old
[/CODE]
When you’re done, remember to restart xinetd
[CODE]
$ service xinetd stop
[/CODE]
If this works, is there a systematic way to have this be an option in the UI? It would be a really nice feature for me and a couple of other people. In general we have NFS storage nearby that I would like to use but which I can’t turn into a full fledged fog storage node.
Did the upload complete OK? under images can you see all of the partitions listed, e.g.
[CODE]
$ ls -l /images/Mint17x67Cinnamon
total 8.9G
-rwxrwxrwx. 1 root root 1.0M Jun 12 10:38 d1.mbr
-rwxrwxrwx. 1 root root 0 Jun 12 10:38 d1.has_grub
-rwxrwxrwx. 1 root root 37M Jun 12 10:39 d1p1.img
-rwxrwxrwx. 1 root root 4.1G Jun 12 10:50 d1p2.img
-rwxrwxrwx. 1 root root 4.0G Jun 12 10:59 d1p3.img
-rwxrwxrwx. 1 root root 764M Jun 12 11:03 d1p4.img
[/CODE]
Assuming that the file sizes in there look sane to you I would think something about the partition layout is tripping up fog. Can you include a copy of the partition table?
Glad to hear your PXE server is working! For the 2900 it might be worth double checking the network card settings in the BIOS or sticking the service tag into dell.com and looking for updated firmware.
[quote=“BBBBlaine, post: 30888, member: 24687”]
EDIT maybe I will try this on a different machine to see if maybe there’s just some problem with this server… It is a Dell PowerEdge 2900 - refurbished (I mean the server I’m using to try PXE boot at least. The Fog server is a Virtual Machine on ESXi 5.5)[/quote]
That sounds like a good idea, it would be informative to see some different PXE clients. Good luck!
I’m running it on RHEL 6.5 and also Centos 5. Do you have any other clients you can try to iPXE boot? the VESA thing might be a hardware issue.
[quote=“Tom Elliott, post: 30877, member: 7271”]The default.ipxe you’re seeing looks wrong to me, unless you cut out the last line because of IP?
The last line should be set to something like:
chain 192.168.1.1/fog/service/ipxe/boot.php##params[/quote]
Yes, sorry! that line is indeed in my default.ipxe - lazy copy pasting!
[CODE]
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://MY IP HERE/fog/service/ipxe/boot.php##params
[/CODE]
Actually BBBBLaine, now that I think about it, your default.ipxe IS going to be different from mine, it’ll have your fog server’s IP address in it. Can you verify that the contents of your ipxe file that is chain loaded look sane? (point a browser at [url]http://MY[/url] IP HERE/fog/service/ipxe/boot.php##params). Here’s mine
[CODE]
[COLOR=#000000]#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
colour --rgb 0xff6600 2
cpair --foreground 7 --background 2 2
console --picture http://MY IP HERE/fog/service/ipxe/bg.png --left 100 --right 80
prompt --key 0x1b --timeout 3000 Booting… (Press Escape to access the menu) && goto menuAccess || sanboot --no-describe --drive 0x80
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param menuaccess 1
param debug 0
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://MY IP HERE/fog/service/ipxe/boot.php##params[/COLOR]
[/CODE]
I don’t know iPXE (or PXE) well so I’m not sure what the sequence is, but just comparing the file sizes in the directories, my default.ipxe looks different from yours. I’ll md5sum everything in that directory to let you compare
[CODE]
$ md5sum *
e98752ef921d9ae727e8056550a6c9a5 boot.txt
418b6eb51122fcdab90ec8c7ed80ef85 default.ipxe
48f6c6d1b580a4a8b64f20c13d0dd683 ipxe.kkpxe
326f7de6b826275725cd0728e4f5c194 ipxe.kpxe
828b8ccf956cf63ef4d20b46c4a13698 ipxe.krn
565956b5a03307ba52b38a45edc61291 ipxe.pxe
2c44adda31db993665f51a8717af3985 memdisk
3794629cd0a52cf5d20df3984319de1b pxelinux.0.old
ffb7b9176e3d40eca5903364def6753d snponly.efi
418b7656f88e07e591947e6a0f11694f undionly.kkpxe
2967e86058a2ed5fbc159f722a62e211 undionly.kpxe
dc15ad8391f21429be2db7d6922aed41 undionly.kpxe.INTEL
b9c71e3130f2a5963c15ab157fcf695b undionly.pxe
2e3f0be8f5e63ff99812a140795beffc vesamenu.c32
[/CODE]
And here is my default.ipxe
[CODE]
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
[/CODE]
The missing (and corrupt??) files are weird. A reinstall might fix it, but it’s probably better if we can figure out what has gone wrong this time.
Yeah, it sounds like you’re on the right track. my undonly.kpxe looks slightly different
[CODE]
$ cd /tftpboot
$ ls -l undionly.kpxe
-rw-r–r–. 1 fog root 102825 Jun 17 14:46 undionly.kpxe
$ md5sum undionly.kpxe
2967e86058a2ed5fbc159f722a62e211 undionly.kpxe
[/CODE]
If you untar a copy of the fog installer somewhere then you can copy out the file, it should be under packages/tftp/undionly.kpxe. Copy that into place and see if you are back in business.
That looks consistent with what I see in mine (I added a test kernel called bzImage-test)
[CODE]
$ cd /var/www/html/fog/service/ipxe
$ ls -lhrt
-rw-r–r–. 1 fog apache 230K Jun 17 14:37 grub.exe
-rw-r–r–. 1 fog apache 25K Jun 17 14:37 memdisk
-rw-r–r–. 1 fog apache 5.9M Jun 17 14:37 bzImage
-rw-r–r–. 1 fog apache 756 Jun 17 14:37 boot.php
-rw-r–r–. 1 fog apache 44K Jun 17 14:37 bg.png
-rw-r–r–. 1 fog apache 10M Jun 17 14:37 init.xz
-rw-r–r–. 1 fog apache 9.1M Jun 17 14:37 init_32.xz
-rw-r–r–. 1 fog apache 5.9M Jun 17 14:37 bzImage32
-rw-r–r–. 1 fog apache 1.8M Jun 17 14:37 memtest.bin
-rw-r–r–. 1 fog apache 503 Jun 17 14:37 advanced.php
drwxr-xr-x. 2 fog fog 4.0K Jun 19 13:56 backup
-rw-r–r–. 1 fog fog 5.9M Jun 19 13:56 bzImage-test
[/CODE]
Assuming the permissions on the ipxe directory are OK and that you’re not running selinux my guess would be something to do with the web frontend. You might find something in the apache logs.
Hi Jackley, Toms response was to Chuck Sites above, there was too much going on in this thread :). Do you see anything in the ipxe directory (e.g. /var/www/html/fog/service/ipxe - you might have a slightly different web root). The Add Kernel function should drop the file you are uploading in there I think.
[quote=“Chuck Sites, post: 30799, member: 22709”]when I select ‘Boot from hard drive’, It clears the screen and prints “PRESS A KEY TO REBOOT”. Pressing any key reboots.[/quote]
It sounds like you might have a different problem to the other posts in this thread, your DHCP is working if you are getting the FOG boot menu. You might try adjusting the “[FONT=Ubuntu][COLOR=#555555]Exit to Hard Drive Type”[/COLOR][/FONT] in the PXE Boot menu.
Hi MarkusK, on my system the fog install script puts udpcast into /tmp and builds in there. You could try doing this manually, it might give you a better idea of the problem from, e.g.
[CODE]
cd /tmp/udpcast-20120424
make distclean
./configure
make
[/CODE]
From what you said above it sounds like somewhere in ./configure you will see an error, that will give you a better idea of what is missing or wrong.
Given that, my best guess would be a firewall somewhere between the server and your client. As I mentioned above, TFTP does weird things with it’s port choices, disabling the firewall(s) for a few seconds could save you a lot of time in debugging.
If you have another machine (e.g. another linux server on the same switch as your fog server), you could try tftp from there and rule out networking/firewall issues on the fog server.
Can you tftp the file on the fog server itself? (I mean run the tftp get above on the fog server). If so I would suspect the client or an intervening firewall: from memory TFTP might uses 69 as a control port but the actual transfer takes place on other port(s).
EDIT Also, if you use tcpwrappers, take a look in your hosts.allow and hosts.deny
For my setup, this looks very similar to [URL=‘http://fogproject.org/forum/threads/multicast-does-not-work-to-multiple-clients-only-to-single-client.863/’]this post[/URL], but their hack with the 239.X.X.X mcast address doesn’t seem to be working for me.
Sorry, missed your question. No, single node setup, I think my problem is either with udpcast or our network configuration.
I’m running into the same problem with fog-1.1.1 on RHEL 6.5. I’m pretty much clueless about UDPcast so I’m not sure if the problem is with the network or fog. I can say that everything seems to work with a single machine in the group and fog tells me that it will be using UDPcast for that host.
EDIT I should also say that I took a go at running udp-sender and udp-receiver manually (in debug mode on the clients). The results were the same: a single host worked fine, more than one failed, this time with errors like
[CODE]
Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=84698
[/CODE]