Host registration: hdparm: ioctl 0x304 failed: Inappropriate ioctl for device
-
Hello,
we have a problem at the “Full register host” option. When we try to register a host the error message “hdparm: ioctl 0x304 failed: Inappropriate ioctl for device” appears.
It is a 0.33 Beta out of SVN from 12. July build on a Ubuntu LTS 12.04.2 x64.
We tried changing from IDE to AHCI and just new installed the FOG.
We also have a 0.33 Beta at an Ubuntu Server 12.10, working without problems, also build from the SVN but a short time ago
We always used the same computers to try, so it is no problem with the computer. HP Compaq 8200.
Regards
Sebastian -
Having the same problem with only one of our laptops. Using 0.33B rev. 899. Hopefully this will be fixed soon.
-
Same problem here with HP ProBook 6475b. Boot Options set to UEFI Hybrid with CSM and Clear SecureBoot Keys.
It does however work on some 6475b-machines. -
[quote=“robjoh, post: 14104, member: 2831”]Same problem here with HP ProBook 6475b. Boot Options set to UEFI Hybrid with CSM and Clear SecureBoot Keys.
It does however work on some 6475b-machines.[/quote]I would say it is a problem with the actual version of FOG or with the Linux version used. Which version do you used at your ProBook?
-
[quote=“Sebastian M., post: 14105, member: 229”]I would say it is a problem with the actual version of FOG or with the Linux version used. Which version do you used at your ProBook?[/quote]
Hi, here we use FOG 0.32 on CentOS 6.4… have also tried the newest kernels for pxeboot. This is very odd.
Next I will try the latest BIOS for ProBook 6475b and let you know. -
No luck. I do not have any idea what causes this.
What is really strange is that older models, which I know for certain work on another FOG server, does not work on this FOG server.I think our solution here will be a full FOG server reinstall. :eek:
-
[quote=“robjoh, post: 14109, member: 2831”]No luck. I do not have any idea what causes this.
What is really strange is that older models, which I know for certain work on another FOG server, does not work on this FOG server.I think our solution here will be a full FOG server reinstall. :eek:[/quote]
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.
-
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.