Okay,
When you performed the install, did you have any special parameters involved. Such as:
[LIST]
[]Is your tftpboot folder in a location other than /tftpboot?
[]Is your tftpboot folder hosted on another filesystem?
[/LIST]
Has your system performed a filesystem check and/or is your filesystem on a RAID setup? Is it possible one of the drives has failed?
what is the output of the command:
[code]umask[/code]
No, you shouldn’t have to restart any services that I’m aware of, is there a reason you ask?
[quote=“falko, post: 18095, member: 48”]Tom your a MACHINE with these updates!![/quote]
I think that’s what I was born to do. I know there’s plenty more to do, but I am also starting to see the light at the end of the tunnel with 0.33 release. I have to try to figure out about this sysprep thing with Windows 7. I understand the reasoning, but at the same time I think imaging a system should just be upload image, deploy when needed, presto/chango complete with imaging process. I not a huge fan of: make master, sysprep, upload, verify sysprep didn’t screw up activation (as necessary of course), then try again until you know you’re good, then deploy.
This is also going to sound a bit odd, I think, but is there a firewall running on the FOG Server? Is iptables disabled?
To find out run:
[code]iptables -L -n[/code]
If you get the text such as:
[code]Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination[/code]
Then chances are it’s already disabled. If you get anything more than that run:
[code]chkconfig iptables off; service iptables stop[/code]
You can download from SVN with:
[code]svn co https://svn.code.sf.net/p/freeghost/code/trunk fog_0.33b[/code] then cd to the fog_0.33b folder and perform normal install or you can download a pre-made tarball at latest revision with:
[url]https://mastacontrola.com/fog_0.33b.tar.bz2[/url]
Extract the tarball with:
[code]tar -xjf fog_0.33b.tar.bz2[/code]
Then cd into the fog_0.33b folder and perform normal install from there.
This may sound really odd, but can you try tftp from your fogserver with:
[code]cd
yum -y install tftp
tftp -4 localhost
get
pxelinux.0
exit[/code]
Does this work?
This is starting to make some sense.
The files that you’re working with are all currently 666, or rw-rw-rw- try chmoding all folders as 755 with:
[code]chmod -R 755[/code]
Then perform:
[code]find /tftpboot -type f -exec chmod 744 {} ;[/code]
This should put all files as rwxr–r-- which is what my system looks like. It will also place all the directories as their natural state of rwxr-xr-x
Well,
One way to be ensure it’s a permissions issue is to make sure all permissions are out of the question. Most Directories follow a 755 rule, and many of the files follow that as well. It sounds like it can’t write any request data to the filesystem, which means when you’re accessing it, it can’t modify the last access time. One way to verify if it’s permissions is to put the whole directory as rwx all the way through with:[code]chmod -R 777 /tftpboot[/code]
Then try your ftp command. if that allows it to work, then try [code]chmod -R 755 /tftpboot[/code]
It should still work. I can’t fully remember, though, if you have to specify the full path either, in reference to the command you’re writing in windows…
Vous pouvez le faire dd dans une multitude de façons. Même en utilisant le fichier init.gz de FOG.
La meilleure méthode serait de disque à disque, mais le démarrage du système et dans le menu PXE, choisissez le mode débogage.
Quand vous obtenez l’invite, plug-in les deux disques, ou si vous utilisez de la machine source, branchez le second disque.
Vous pouvez utiliser le DD déjà fourni, mais vous devrez vérifier votre source et des lettres de lecteur de destination. Utilisez fdisk-l pour montrer ce qui les pousse, ils signalent que.
Je recommanderais presque ça. Une autre méthode qui pourrait fonctionner, si vous êtes à l’aise avec cela, effectuer un clonage de disque vous-même en utilisant DD. La façon dont vous voulez faire est d’effectuer
[code]dd if=<ORIGINAL DRIVE> of =<DESTINATION DRIVE> bs= <WHATEVER THE BYTESIZE IS (512 normal, 2048, Modern Windows 7, 4096 AF Disks)[/code]
Donc, si mon lecteur source est / dev / sda et le disque de destination est / dev / sdb et c’est un format lecteur de pointe, nous aimerions entrer comme:
[code]dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror[/code]
Le noerror assure seulement il continuer si elle rencontre une erreur. Trier c’est de récupération de données propre.
Le programme dd semble fonctionner correctement. Quand il est complet avec l’imagerie, il est censé recracher ces chiffres. C’est vous dire combien de dossiers ont été copiés. Le disque peut être de 250 giga-octets, mais en général il finira abrubtly si le disque est endommagé. Avez-vous essayé d’utiliser un autre système?
Les copies du programme dd prendront un temps très long à compléter comme il est la copie bit par bit de données. Faire une image de style fenêtres est légèrement plus rapide et complète beaucoup plus rapide car il est seulement copier les données utilisées du système et de le compresser directement au montage NFS.
Donc, si je comprends bien compris, vous avez besoin d’une image de système d’une configuration multiboot? Si c’est le cas, alors je suppose Autres (99) est correct, mais cela ne fonctionne pas pour vous? Je pense que ce qui se passe est le disque des deux machines doit être égale pour que dd fonctionne correctement. Si vous téléchargez l’image sur un disque qui est plus grand que l’original, cela fonctionnera, mais il apparaît que le lecteur est seulement aussi grand que le système principal.
Timikana, if it’s easier, can you write in your native language? I’ll use translate.google.com to help me understand what you’re trying to do.
Also,
Please try service xinetd restart as that should control tftp for Centos 6.4
Try tftp command line windows lookup.
make sure the folder is also accessible to the fog user:
[code]chown -R fog:root /tftpboot[/code]
Good luck, and if there’s any pertinent issues, just let me know.
Thanks,
Yep, Not quite a million updates, but a lot of frustrating testing.
Again, I don’t have any thing real to test with, but I can watch the tasks being activated, and verify they’re now activating when they’re expected to. Hopefully this is what’s needed. For the Task Run Time in the log viewer, I have the dates working to display the rfc time based on the timestamp for delayed jobs, and for cron jobs, it just displays the cron as is present on the database. It appears, so far, all is working properly now.
