UNSOLVED invalid OS ID (0) (determineOS) Args passed:0

  • I rebuilt my training room last week and imaged it up. Fog version: 1.5.0. There are 11 machines. on 4 of them everything’s ok, but one doesn’t have an image but works, details below, and the remaining ones give me the following error. A screen shot is here.


    There are 11 images in my room. Servers 0-11. Server 9 doesn’t exist. If I look in the /images directory I see Server0-8 and 10-11. BUT not server 1, but there is an image in the /images/dev directory with the same MAC as server1, so this is the temporary one that is copied over. If that didn’t happen then it probably ran out of disk space, but I deleted all the server images from /images before I started the upload. I’ve checked the images directory, and there’s space here’s the details https://www.dropbox.com/s/d0jnxw7b7q0dn92/IMG_3598.JPG?dl=0

    I think the database is corrupted.

    Fog has worked brilliantly for me, and I’ve become totally dependent on it. I have to get this working this week or I’m in a real mess.

    can anyone help me? Pleeese


  • Senior Developer

    @Julianh No it won’t wipe the image definitions or anything else important. It only removes DB entries that are obviously wrong (not pointing to valid entries or something like that).

    It’s not very hard to do - just enter the DB password you find in /var/www/html/fog/lib/fog/config.class.php - might even be empty so you just hit ENTER on the password entry:

    shell> mysql -u root -p
    mysql> use fog;
    mysql> DELETE FROM `hosts` WHERE `hostID` = '0';

    Run all the commands mentioned in the wiki article.

  • Thanks Sebastian. I’m not good with databases though. Will these commands wipe the image side of the database? I’m not bothered. I can happily recreate the images, as the files will still be there.

  • Senior Developer

    @Julianh This sounds really strange! I have no idea why FOG (and with that the DB) should behave in a random way. Especially when you say it deploys wrong the image.

    Before you go ahead and install it all from scratch I might suggest you run the database maintenance stuff you find in our wiki: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

    I’m going to screen shot the image details. I’ll use unbuntu 18 and the latest fog. I’ll take the details of the images Is there anything I need to be aware of before I do this?

    If you only have that handful of servers and images this is probably a good idea. Nevertheless I would save a full copy of the database (using mysqldump) just in case.

  • I had another look at it in the light of day. I redeployed the images to the rest of the servers and what a mess. Servers were deploying on the wrong physical boxes. It’s VMware and the UUID of the hard disks need to match or it gets awfully upset.

    So the images seem to have their references to the image locations wrong. I then changed an images location and saved it, then changed it back again and saved it, nope that didn’t work. I then created a new image, moved the original image elsewhere, and pointed the new image to the correct file location, and it works.

    So the database seems stuffed. The fog server is crutial, I’ve put it on a fast box with a SSD raid array and don’t want this again, so I’m going to image down the servers, rebuild the fog server and image it up.

    I’m going to screen shot the image details. I’ll use unbuntu 18 and the latest fog. I’ll take the details of the images Is there anything I need to be aware of before I do this?

  • Senior Developer

    @Julianh We can try to help you sort this as it seems like this has worked before and you don’t have new hardware as I understand it. George is right that we can’t fully support older versions as we just don’t have the time to backport any fixes or such. So if this turns out to be an issue in the 1.5.0 version we need to ask you to update to 1.5.6!

    For the “invalid OS ID” error follow what George already posted. It looks like the host doesn’t have an image assigned. Check in the web UI and post a picture of the Server4 host settings here.

    About the Server1 image that does seem to be stuck in /images/dev. You can easily rename that in hope of it being properly captured but just not moved over: mv /images/dev/aabbccddeeff /images/server4 (put in the MAC address and make sure you got the destination path correct - lower case and upper case do matter!)

  • Moderator

    @Julianh Well the first thing the developers are going to ask you to do is update the 1.5.6 since they won’t nicely support that release.

    Looking at the supplied image, it looks like the host Server4 doesn’t have an image assigned to it. I’m saying that because if you look at the kernel parameters at the bottom of the picture all of the image definition information is missing.