Host registration: hdparm: ioctl 0x304 failed: Inappropriate ioctl for device
-
For the hdparm issue, check your FOG Configuration->FOG Settings->Web Server and make sure the web root has the trailing slash. Also check that this information is corresponding to the PXE Default file web={IP}/fog/ portion. If it doesn’t have the trailing slash, it can cause this issue, as the FOG scripts actually run the system as:
${web}service/<file>
Without the trailing slash, it will search for something like:
192.168.1.1/fogservice/<file>.php which obviously wouldn’t exist. Some systems seem to not care and add the trailing slash, but a majority of them do this is in this fashion from what I’ve seen.
Maybe I’m wrong, but it couldn’t hurt to check.
-
[quote=“Sebastian M., post: 14122, member: 229”]I tried to reinstall FOG several times. Does not fix the problems.
The crux is that we tried everything with the same hardware to image and on the one machine it works without problems and on the othder machine (new installed FOG 0.33 on Ubuntu LTS 12.04.2 x64) it does not work and we get the error mentioned above.
I do not understand what has changed, also tried to change the kernel, downgrade, upgrade, changed the kernel with the one from our old, working install, no positive effects.[/quote]
Hi,
At my location we have a working FOG server (has been running for 12 months). It is my colleagues FOG server (at another school)
which is the problem. Thursday last week he took his server over to my school, and we reinstalled the server and imaged a few computers with unicast, tried uploading and multicasting. All was working beautiful.Today he took the server back to his own network, i logged in to the server and changed the ip-adress (we use DHCP, so only fog-config-files was edited).
and what do you know?! The same f%&¤%" problem is back. -
[quote=“Tom Elliott, post: 14177, member: 7271”]For the hdparm issue, check your FOG Configuration->FOG Settings->Web Server and make sure the web root has the trailing slash. Also check that this information is corresponding to the PXE Default file web={IP}/fog/ portion. If it doesn’t have the trailing slash, it can cause this issue, as the FOG scripts actually run the system as:
${web}service/<file>
Without the trailing slash, it will search for something like:
192.168.1.1/fogservice/<file>.php which obviously wouldn’t exist. Some systems seem to not care and add the trailing slash, but a majority of them do this is in this fashion from what I’ve seen.
Maybe I’m wrong, but it couldn’t hurt to check.[/quote]
What is a trailing slash? -
the / marks are slashes. Many times, I’ve seen the pxe default file looking for web:
<IPADDRESS>/fog rather than <IPADDRESS>/fog/ <- (This is the trailing slash as it trails at the end.)
The default file is generally located in:
/tftpboot/pxelinux.cfg/
the file is just called default.
You can edit it however you want, but just make sure the slash is in the file and in the fog settings.
-
In dealing, today even, with the dreaded problem with no configuration issues, I’ve also seen this issue occur when a network has been affected by a broadcast storm. Essentially what ends up happening is the network is being flooded by another switch, kind of like a loopback into itself. (I know that sounds funny) However, the fix for this particular issue was to reset all mini-switches within the path of the network with a simple power down, power up. Then, as needed, reset the Layer 3 Switches if they became too bogged down by the broadcast error messages.
I hope this helps. The particular issue I saw with one of my systems is that the cable has a break in it somewhere. It had enough signal to boot the kernel and init.gz, but when fog tries to reset the device after boot up, the signal is lost and nothing can be found. Then we got the hdparm issue. Connected the system to a good connection from another area and all worked fine. It wasn’t the system, but the network. Check that this other system isn’t having many Multicast devices attached (iPads, Smartphones, Apple TV, etc.) Reset the switches, and reboot any miniswitches. You may narrow the problem down further this way. If your setup worked elsewhere, chances are it isn’t a configuration issue and I was just trying to help. I’m sorry if I lead you in the wrong direction, but hope that this helps you out.
-
Tom, I think you’re on to something here. I will have my colleague reset his switches and other devices.
About this pxelinux.cfg/default - I edited this file before when I changed ip-address. All seems fine there.We well try going trough switches etc. and post back later. Thanks
-
I hope this helps you. I only, yesterday, learned about this all. Good Luck!
-
I looked into my pxelinux.cfg and all entries are with a trailing slah at the end. So this is not the problem
[ATTACH=full]378[/ATTACH]
Also the entry in the FOG Configuration is /fog/ as base directory.
[B]I remember, that the old FOG server has the same error but continues with making image, deploying etc. The new FOG server displays the error and does nothing or aborts.[/B]
[url=“/_imported_xf_attachments/0/378_tftp.PNG?:”]tftp.PNG[/url]
-
There are a few options that you should look into other than configuration. I just know, for my setup, if I don’t have the trailing slash, it causes the same type of issue. The other things to look into would be the Network itself. Make sure that the path to the router/switch is relative free of collisions and/or broadcasts. Things that seem to affect the network adversely are Devices that use broadcast messages to communicate such as Apple’s Bonjour service (iPads, iPhones, iPods, Airplay) especially if they’re setup to communicate wireless to another endpoint. Also check your kernel and make sure it’s not a driver issue. If fog can’t recognize your network card, it would also give this issue. I would almost point out that it could be the hard drive setup as well. Though the kernel’s I use seem to be able to work on AHCI mode, maybe the kernel you’re using can’t recognize it. Does the system recognize a hard-drive (/dev/sda, /dev/hda, etc…)?
Also, start small to help in troubleshooting. Try just emplacing a single router or switch to the host you’re trying to image and the fog server. This will help you troubleshoot whether it’s a network issue, or a driver issue.
Thank you,
-
The point is, that both systems standing in the same environment, at the same switch etc.
It makes no sense at all for the moment.
-
What, else, have you tried? Have you tried alternative kernels? Have you tried debug mode to see if you can find an issue specific to network or hard drives? It isn’t just going to be configuration. There are many different things that could be the cause of the problem.
-
Tried upgrading the kernel, tried older versions and the kernel from the other FOG installation.
It is the same piece of hardware, so can it be a problem with network or hard drives even if it works with the other FOG installation?
The error is the same at both installations but on the older one the deploy and the image process works even though.
-
Yes it could be the network. Not necessarily a network driver issue, but something is preventing the system from communicating with the FOG Server. On your alternate system, these aren’t occuring.
-
Server 1 and server 2 are installed at the same ESX-server with the same infrastructure and same settings.
The test PC were always the same.
-
so you have two tftp servers running on the same network?
-
Not at the same time, I shut down the one server and started the other one.
-
Hello everybody.
Tom Elliott did the trick: [url]http://fogproject.org/forum/threads/kernel-cannot-open-proc-partitions.5487/#post-14450[/url]
-
Sorry all,
I forgot to read that you guys were having the issue with FOG 0.33b. I posted all of this information on FOG 0.33 Bugs forum as well.