Possibly related:

https://forums.fogproject.org/topic/7763/ipxe-login-after-upgrading-to-latest-trunk-no-such-file-or-directory/22

and

https://forums.fogproject.org/topic/7774/default-ipxe

Hi, apologies the bios on the laptop needed flashing to allow the adapter to function. We now have Inspiron’s booting to the fog menu - what a pretty sight!

Thank you for your guidance, brilliant as always.

Tom

I understand, I created a new topic: https://forums.fogproject.org/topic/7767/another-init-xz-issue
PS: dhcp settings seem to be ok (see the new topic).

@george1421 my newbie mistake! this is now resolved

@Wayne-Workman Thanks a ton for you offer to assist!!! I’m going to put these servers right. Need to read up on how environments change in Linux as I’m guessing it has to do with my problem. Live and learn! This should be marked solved I think as we can reasonable guess the problem is hidden in how the server was built/upgraded in the first place.

Minor update.

I haven’t changed anything today yet but did image a lab this morning. While the lab was going I didn’t see a single occurrence of a machine getting the error I had before (unable to mount) with two storage nodes active. I had no discernible slowdowns while imaging one machine at gig while simultaneously imaging 7 others at 100 Mb (old 2950 switches still in this building). I was also seeing traffic coming off of more than one vNIC according to VMWare.

Until I try and do 4-6 or more simultaneous imaging tasks at Gig on the new network I won’t know for sure if the > 1000 Mb/s throughput “barrier” is broken.

I’ve got one last model’s image I’m uploading today, then I’ll do the trunk upgrade and do some more tests to see how things look.

@Wayne-Workman Thanks for the link. My mistake, great support on this forum 🙂

@Pascal-Gazaille Anything in the apache error log when you see the Internal Server Error in your browser? See the signature below my message on where to find the log.

Thanks it is now working

Issue should be corrected for in latest.

@Tom-Elliott Okay, thanks. I did set it there so I should be good. I’ll mark this as solved for now and if it reoccurs after update I’ll post here again.

@Tom-Elliott Feeling like dullest knife in drawer. Update fixed everything just fine.

@Sebastian-Roth You’re right. When I made it I was thinking… man we are gonna have stuff spread out everywhere. But, when I look at the other articles that are solely about DHCP there is no troubleshooting, just stuff about setup. I’ll move this stuff into what you’re working on and link this article to that.

Thanks @Wayne-Workman for reminding me. Added to the wiki now (see my signature). The article is still missing a lot of details about the boot process and all the issues one might run into.

Thanks again Wayne, that’s exactly what I needed.

@Wayne-Workman said in Image hosting on NFS server, process uncompleted?:

@arnaudrigole I have some methods documented.

using lftp:
lftp -c 'open x.x.x.x; user UserGoesHere PasswordHere; mirror -e /images/TheImagePath /images/TheImagePath; quit'

using NFS:
mount x.x.x.x:/<remote directory> <local directory>
cp -R /mbimages/Optiplex9020UEFI /images/Optiplex9020UEFI
umount <local directory>

Using Samba:
mkdir /tempMount
mount -t cifs //x.x.x.x/ShareNameGoesHere /tempMount -o username=YourUsernameGoesHere -o password=YourPasswordGoesHere,noexec
cp -r /tempMount/ImageNameHere /images/ImageNameHere
umount /tempMount

using SCP:
scp -r /images/ImageNameHere root@x.x.x.x:/images/ImageNameHere

using rsync:
rsync -a /images/ImageNameHere root@x.x.x.x:/images/ImageNameHere

wiki worthy

Added to the wiki here:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually

@Sebastian-Roth said in Impossible to boot on PXE......:

Wireshark filter bootp && tftp is great for this

This has been in the wiki for some time, here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_TFTP

@BedCruncher said in Multicast Issues on Centos 7:

@Wayne-Workman

Using one of the links, can’t remember which. I was able to get the server and client to send using the udp-sender and udp-receiver. So I know they can talk, but I had to use the command.

udp-sender --file /opt/fog/.fogsettings --log /opt/fog/log/multicast.log --ttl 32 --nopointopoint --interface em2

if I dropped the last bit off then it would still try to grab em1 instead of em2.

An example now exists in two different places in the wiki. I want to merge the articles but it will be an involved process to do that - I’ll get it done.

For now, here are the two articles:

https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Downloading_-_Multicast
2.
https://wiki.fogproject.org/wiki/index.php?title=Multicast

@Tom-Elliott said in Fast TSC Calibration Error, unable to register and inventory:

@mattyb Run this command to just download the latest kernels in place.

mkdir /var/www/html/fog/service/ipxe/backup mv /var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe/backup cd /var/www/html/fog/service/ipxe/ wget --no-check-certificate https://fogproject.org/kernels/bzImage -O bzImage wget --no-check-certificate https://fogproject.org/kernels/bzImage32 -O bzImage32

This has been covered in the wiki here: https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update

Update on this project, @Tom-Elliott has taken the PHP backend and integrated it partially into FOG Trunk. It’s available as a plugin, but not fully functioning just yet. We still need to create scheduling for it. Tom has already written a way to display everything in the checksum table, and a way to export those if people wanted to use a 3rd party app to analyze the results if they wish.

I’ll be writing some intelligent code that will analyze the table’s contents to display concerning entries. The analysis will follow some basic principals.

Makes decisions based on data in the DB.

A storage group’s files should always match across all nodes in the group, both images and snapins.

Images shared between storage groups should always match between those groups masters.

If no image upload occurred between the last and current check, images are expected to match across that time period.

If an image upload does occur, the files are expected to change.

Results of the intelligent analysis should display concerns, following the rules above, and the user should be able to “dismiss” individual file concerns so they don’t show anymore.

The integrity table will have a column that will operate similar to the pending hosts column in the hosts table. blank or zero should be unchecked or false (bad or unprocessed), 1 should be good or dismissed.

This column in the table will be administered by the intelligent checking, and by the user’s “dismiss” clicks. Once an entry for a file is marked as “good” by either no problems being detected or being dismissed by the user, that entry is forever good. If it’s blank, when analyzed it will be marked 0 or 1 respectively.

I’ll be working on this as I have time.