@Sebastian-Roth So far I’ve tried a fresh Ubuntu 16.04 install, and I’ve even used LVM and just captured as non-resizable with 0 issues. Now while this wasn’t Ubuntu 18, I did notice the machine I had the issue on originally is unable to install this OS due to something being wrong with the “file system” on the disk which for some odd reason it couldn’t format, delete, or write to. It is an SSD, and I couldn’t recreate this issue on any other box. I ran various SSD diagnostics with no errors being found so I’m stumped. I haven’t gotten to try with the exact iso posted above just yet - doing production stuff lately since I’m alone in IT currently.

@jeevan517 Please provide more information on what’s not working or what you need help with.

Fixed. I needed to run the command “service mysql restart”

@sbenson No, we don’t use Avahi/LLMNR in FOG. The FOG installer does not set this up so I suppose you installed/configured it on the server manually?!

Immediately before capturing CentOS 7.x I do the following.

# Direct next Kernel recompilation to include AHCI drivers & be HW generic sed -i 's|#add_drivers+="|add_drivers+="ahci|g' /etc/dracut.conf sed -i 's|#hostonly="yes|hostonly="no|g' /etc/dracut.conf # Clean & Update the OS (includes Kernel recompilation) yum clean all yum makecache yum update -y # Shutdown shutdown now

Ok, seems like @jflippen’s advice helped here. Now we face a new issue following up here: https://forums.fogproject.org/topic/12742/capturing-centos-linux-image

@china-boy I moved your post with the pictures to the new topic.

@Critchleyb Good to know you could work around the issue as suggest in the issue ticket on github. I will see what I can do to properly fix this. Will surely be fixed in the next release.

@Bigredcherokee I have seen people in the past “think” they can use this account for system administration, they install FOG and the installer takes over this account and gives it a new password. The admin then resets the password on the fog account that’s where things usually go sideways. FOG will throw a similar error to what you last posted when this happens.

You will also see a similar error when you try to capture an image. Right at the end of the capture it will fail with an error about unable to update the fog database. That is an indication that the fog service account’s password has changed.

@Xibeaga actually, no. There’s been very few this past year.

Found the problem! Hurrah!

Managed to find this page on other DHCP Settings for routers which listed instructions for Cisco: https://wiki.fogproject.org/wiki/index.php?title=Other_DHCP_Configurations

We initially used:

Option 66 [Server IP] Option 67 ascii undionly.kpxe

What actually worked

next-server <Server IP> bootfile undionly.kpxe

Thanks for the help @Sebastian-Roth @george1421

@Sebastian-Roth -465.7 GB

@dbrilliant -It’s all good. Working fantastic!

That’s it thanks guys. I used sudo add-apt-repository universe, and there were about 20 packages out there. Now, if I can remember how to finish this project off. It’s been 7 years since I built a fog server. lol

@osandag said in no such device or address:

Hi, Was this issue resolved?
I have a same or similar issue where the host status is green for about the first ten minutes till i register the host image it, but after a while fog says ‘no such device or address’

Given the age of the issue, has it been fixed or I have to follow the SQL edit procedure?

I just had the same issue that you are describing. The way I fixed it was to ensure that my interfaces file (Ubuntu server) was configured correctly. In my case, I was using search [domain] instead of dns-search [domain]. Once I fixed that, all was well.

@george1421

Reading the Parted Magic Frugal install instruction did get me some valuable information :

https://partedmagic.com/frugal-install/

Simply put, the boot process for Parted Magic will seek the Squashfs in removable devices, which do not exist in a “sanboot” :

root=/dev/sdXX

Starting with PartedMagic 6.2 the search for the pmagic-.sqfs file will begin with the removable devices, unless a device/partition (root=/dev/sdXX), label (label=XXXXXXXX) or partial uuid (uuid=XXXXXX) is stated. Without such a kernel boot parameter a 10 seconds delay will occur.*

Furthermore, the boot must be set to “boot=/boot” :

directory=/boot

Previous versions of this document said to copy the “pmagic” folder to ”/”. This carried the risk of a subsequent run of PartedMagic from a CD or a USB stick to find the pmagic-.sqfs file on the disk instead of the on the media – something you would not want in the majority of cases.
Starting with PartedMagic 6.2 the risk is inverted: a subsequent run of PartedMagic from the disk might find the pmagic-.sqfs file on the media.
The solution in both cases is to “hide” the “pmagic” folder on the disk in e.g. the ”/boot” folder.

@aborn said in Images are created with 777 (world writable file rights) and owner root on CentOS 7:

I inserted the proposed new line now in the fog.postinit script

This is at the wrong point in time. We can use a postinit script to fix things before things happen. Current a postdeploy script will handle actions after an image is install on the target computer. What we need is a postcapture script to handle things after the image has been captured but before the image is moved from /images/dev to /images. Once the image has been captured we will use a postcapture script to reset the permissions and file ownership of the captured directory so that the FTP process can move it as fog. I can see the process in my head clearly. We just need to patch the fog.capture (guessing at name) script to make the call to a postcapture script. We should be able to mimic what is done for a postdeploy script. It shouldn’t be that hard to do, then we’ll use a postinit script to copy the patch fog.capture script to FOS before it starts doing its thing.

@abulhol Fixed in working branch, will be in the next release. Let’s see if we are able to get this out in time so people upgrading their servers from 16.04 to 18.04 won’t run into the same issue as you did.

@lucycle
I used to have an issue with some Realtek cards behaving weird and throwing errors in IPXE and later in the boot process, but it’s been a while. With these two HP models and an integrated Realtek card I had to use a different boot firmware, long shot but maybe you can try that?

HP210 Legacy Test

pxe-service=tag:HP210,X86PC, “HP-210 Working”, realtek.kpxe

HP430 UEFI Test

pxe-service=tag:HP430,X86-64_EFI, “HP 430”, realtek.efi

@lucycle said in NFS over TCP not available from x.x.x.x:

In my case the driver in question was dm9601.ko and I also compiled it into my initrd.img which did not fix the issue and behavior persists.

I’ve added another USB dongle, this time a Lenovo 2.0 Ethernet Adapter based on the asix driver, however it didn’t work, then I checked with modinfo and noticed I was missing a dependency (usbnet.ko)

modinfo asix .... depends: mii,usbnet modinfo usbnet filename: /lib/modules/4.15.0-34-generic/kernel/drivers/net/usb/usbnet.ko

Just to be sure, you said initrd.img, I added it to initrd.lz

That’s about all I’ve got to suggest at this point

@george1421
Thanks george1421,
I have no issues with mine but thank you 🙂

@Boyan-Biandov yes, but I prefer to use the working branch because it uses Ubuntu’s PHP7.2, which makes it more compatible with other software.