Kernel update 6 hours later
-
ooff…this is getting ugly! Could you try running the same commands as the fog user, i.e. log in to the fog server and try this
[CODE]
$ sudo su - fog
$ cd /tmp
$ echo “test” > testFile$ ftp 10.120.88.146
Connected to 10.120.88.146 (10.120.88.146).
220 (vsFTPd 2.2.2)
Name (10.120.88.146:fog): fog
331 Please specify the password.
Password: ********
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put testFile /var/www/fog/service/ipxe/testFile
local: testFile remote: /var/www/html/fog/service/ipxe/testFile
227 Entering Passive Mode (10,128,128,146,125,20).
150 Ok to send data.
226 Transfer complete.
ftp> quit
221 Goodbye.$ ls -l /var/www/fog/service/ipxe/testFile
-rw-r–r–. 1 fog fog 0 Jul 15 20:47 /var/www/fog/service/ipxe/testFile
[/CODE]Additionally, just confirm that the [FONT=Ubuntu][COLOR=#555555]FOG_TFTP_HOST[/COLOR][/FONT] in your fog configuration is set to 10.120.88.146. Also Since that section of code relies on Javascript and ajax, can you confirm that the browser you’re using to do this doesn’t have javascript disabled.
-
[CODE]
fog@SC-Image:~$ sudo su - fog
[sudo] password for fog:
fog@SC-Image:~$ cd /tmp
fog@SC-Image:/tmp$ echo “test” > testFile
fog@SC-Image:/tmp$ ftp 10.120.88.146
Connected to 10.120.88.146.
220 (vsFTPd 2.3.5)
Name (10.120.88.146:fog): fog
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put testFile /var/www/fog/service/ipxe/testFile
local: testFile remote: /var/www/fog/service/ipxe/testFile
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
5 bytes sent in 0.00 secs (157.5 kB/s)
ftp> quit
221 Goodbye.fog@SC-Image:/tmp$ ls -l /var/www/fog/service/ipxe/testFile
-rw-r–r-- 1 fog fog 5 Jul 16 08:58 /var/www/fog/service/ipxe/testFile
[/CODE]JavaScript is enabled.
-
Holy cow, I just tried this in Chrome and it went through correctly. All this for a browser issue. When you mentioned checking settings I figured I’d try Chrome. I updated both the 32 bit and 64 bit kernels without an issue when I used Chrome.
-
Apparently updating kernels doesn’t work in IE11, or at least it doesn’t for me.
-
But this doesn’t solve my long withstanding problem of why bzimage takes forever to load up on the client I’m trying to image.
-
[quote=“NDNtech, post: 33253, member: 23658”]But this doesn’t solve my long withstanding problem of why bzimage takes forever to load up on the client I’m trying to image.[/quote]
This could be due to the drivers that are included in the bzImage, if you are feeling up to the task, you can always create your own bzImage that includes ONLY the drivers you need, this will increase the speed in which bzimage is loaded.
-
I’ve tried to avoid this for as long as I can. lol Can this only be done on a Linux machine? -
[quote=“NDNtech, post: 33256, member: 23658”]:( I’ve tried to avoid this for as long as I can. lol Can this only be done on a Linux machine?[/quote]
yes, it’s fairly simple to do, it just takes some time figuring out which drivers need to be included, Tom’s kernels tend to be all inclusive, and this can cause some load time issues.I’ve built a kernel or two in the past, just make sure you keep back ups of the working kernels… don’t ask why <.<
-
[url]http://fogproject.org/wiki/index.php?title=Building_a_Custom_Kernel[/url]
^Is this the best guide out there?
-
That should do just fine… this is an old guide and this is the one I used when creating my kernels.
-
This is out of /etc/default/tftpd-hpa:
[CODE]# /etc/default/tftpd-hpa
FOG Modified version
TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“-s”[/CODE]Is it right??
-
For FTP, what does tftp have to do with it?
That file doesn’t mean anything in regards to kernel download.
-
Well, I figured out that the kernel issue was for the browser. I was wondering if this was right since it has 0.0.0.0 rather than my IP address
-
0.0.0.0 in that context basically means listen on all available addresses on your machine. You should leave it at that value.
Can you confirm exactly what you see when you boot one of the problematic clients, e.g. Do you see it get a DHCP entry and then grab the iPXE image?
-
Yes, it gets to the ipxe screen and if it’s going to the menu, it takes forever to load bg.png. If it’s going to the imaging environment it takes forever to load bzimage
-
If it is just being slow then I would agree that it is probably a driver issue, but in one of your other threads you mentioned that you fixed it…
[QUOTE]I got the problem fixed that made the fog boot menu take forever to load by setting permissions to the tftpboot folder to 777 and the owner is fog and the restarting the xinetd service.Now when I try to upload/deploy an image, bzimage will not go past 0%.[/QUOTE]
Does that workaround no longer work? I mean does it EVER complete or is it just slow? -
It ended up being a network issue. I just moved the computer to the same switch as the server and it went blazing fast. I’m going to get with the Network Admin and see if we can get this cleared up.
-
it seems like the first time I try it it goes somewhat slow. If I try again, it’ll go super slow. That work around proved to be ineffective.
-
What workaround?
-
From IANABC
[QUOTE]If it is just being slow then I would agree that it is probably a driver issue, but in one of your other threads you mentioned that you fixed it…
[INDENT=1]I got the problem fixed that made the fog boot menu take forever to load by setting permissions to the tftpboot folder to 777 and the owner is fog and the restarting the xinetd service.[/INDENT]
[INDENT=1] [/INDENT]
[INDENT=1]Now when I try to upload/deploy an image, bzimage will not go past 0%.[/INDENT]
Does that workaround no longer work? I mean does it EVER complete or is it just slow?[/QUOTE]
