Posts made by jburleson

Not sure if this will help any.

mdadm -D /dev/md0 shows
Raid Level 0
Total Devices 0
State Inactive

cat /proc/mdstat shows
Personalities: [linear] [raio0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
unused devices: <none>]

@Tom-Elliott

Here is the output of lsblk.

@george1421

I modify the BIOS when the computers come in. One of the settings I change is to switch the SATA operation to AHCI.

I switched from ipxe.efi since the Surface Pro 4 would not boot from it.

ipxe7156.efi does not work for RAID mode either (just tested it).

After my next appointment I will run debug and see if I can get you some additional information on it.

@chrisdecker

I have successfully deployed an image to the Optiplex 7040 with the same SSD as yours using UEFI (Secure Boot Disabled).

FOG Information:
Running Version 1.3.1-RC-1
SVN Revision: 6052
Kernel Version: bzImage Version: 4.9.0

Host EFI Exit Type: Refined_EFI
PXE File: ipxe7156.efi

Image: Windows 10

Update
For Option 2, you do not need to create a new profile. Instead you can modify the file /etc/apparmor.d/lxc/lxc-default-cgns. Here is the content of the file after I added the nfs mount options.

# Do not load this file.  Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default-cgns flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>

  # the container may never be allowed to mount devpts.  If it does, it
  # will remount the host's devpts.  We could allow it to do it with
  # the newinstance option (but, right now, we don't).
  deny mount fstype=devpts,
  mount fstype=cgroup -> /sys/fs/cgroup/**,
  mount fstype=nfs*,
  mount fstype=rpc_pipefs,
}

You will not need to edit your container configuration file using this method.

If you are not using Proxmox and your host kernel is NOT cgroup namespace aware, you will need to edit the file /etc/apparmor.d/lxc/lxc-default instead.

@Tom-Elliott Gotcha. I appreciate the help.

@Tom-Elliott Thanks Tom. I will update the server in the morning.

There is nothing logged to the apache2 error log either.

@Tom-Elliott Interesting. The printer detail page shows the type set to TCP/IP Port Printer.
However, when I looked at the list of all printers, it did not show a printer type for that printer. When I clicked on update printer from the Printer Management screen (not changing anything just clicking update), it filled in the type on the list of all printers.

I think I may have found what caused this issue. When creating a new printer, when you click add printer it is not saving the Printer Type to the database. If you then select the printer and just click update printer, it adds the printer type.

To reproduce:

1. Select create printer
   

2. Filling in printer detail
   

3. Save the printer and then go the list all printers. I just snipped the listing for the test printer. The second field which should be Printer Type is blank.
   

4. Select printer to edit it.
   

5. Do not change anything just click Update Printer and then check the list of all printers. The Printer Type is now set correctly.
   

OS: Ubuntu 16.04
Fog Running Version 1.3.0-RC-10
SVN Revision: 5955
Fog Client Version: 0.11.5

I do not seem to be able to deploy printers from the FOG server. Here is the relevant message from fog.log on the client machine.

------------------------------------------------------------------------------
--------------------------------PrinterManager--------------------------------
------------------------------------------------------------------------------
 9/15/2016 7:42 AM Client-Info Client Version: 0.11.5
 9/15/2016 7:42 AM Client-Info Client OS:      Windows
 9/15/2016 7:42 AM Client-Info Server Version: 1.3.0-RC-10
 9/15/2016 7:42 AM Middleware::Response Success
 9/15/2016 7:42 AM PrinterManager ERROR: Data conversion using the DataContract FOG.Modules.DataContracts.PrinterManager failed
 9/15/2016 7:42 AM PrinterManager ERROR: Error converting value "" to type 'FOG.Modules.PrinterManager.Printer+PrinterType'. Path 'printers[0].type'.
------------------------------------------------------------------------------

The .fog_user.log has the following:

------------------------------------------------------------------------------
-----------------------------DefaultPrinterManager----------------------------
------------------------------------------------------------------------------
 9/15/2016 7:43 AM Client-Info Client Version: 0.11.5
 9/15/2016 7:43 AM Client-Info Client OS:      Windows
 9/15/2016 7:43 AM Client-Info Server Version: 1.3.0-RC-10
 9/15/2016 7:43 AM Middleware::Response Success
 9/15/2016 7:43 AM DefaultPrinterManager Checking defaults
 9/15/2016 7:43 AM Printer Setting BiSci-LSE202-Xerox660DN as default
 9/15/2016 7:43 AM PrinterManager PrintUI return code = 0
------------------------------------------------------------------------------

I have been able to install from the server previous and have several printers (Brother, Canon, and HP) configured. Deployment did work from the server up until recently (not sure when it stopped working correctly).

The apache error log does not have any error messages.

I configured the Xerox printer using the instruction posted here (very useful – thanks for the helper utility):
https://forums.fogproject.org/topic/8030/xerox-printer-deployment-w-fog-trunk/2

I also ran a git pull and installfog.sh this morning to make sure the server was up to date.

Any ideas on what I should check next?

Thanks

@Wayne-Workman I can confirm that this happens on Windows 7 Enterprise as well.

I am running the same client and server version. The server OS is Ubuntu 16.04.

@PageTown Is apache2 already installed? If so, have you installed all the updates for the server?

sudo apt-get update && sudo apt-get upgrade

@PageTown It almost looks like the server does not have a network connection or is being blocked by a firewall. You might want to check that the server can connect to the Internet.

@PageTown I think you might have left off sudo on the second apt command.

Try:

sudo apt-get update && sudo apt-get install svn

@Tom-Elliott I think we can mark this as a one off problem. Maybe I missed a step when I migrated the old images. Thanks for looking into it.

@JMacavali I can confirm that the Dell Optiplex 3040 works with the latest kernel 4.6.2. Here is my server info:

OS: Ubuntu 16.04
Fog:
Running Version 8515
SVN Revision: 5882

I was able to inventory, register, and deploy an image using uefi boot (secure boot disabled). However, after the it finished deploying the image and rebooted it got stuck in a boot loop. Switching EFI Exit types did not have an impact either. Changing back to legacy boot did fix the issue.

I did also try updating the 3040 bios to the latest version available on the Dell site but it did not change the uefi booting issue.

My recommendation is to disable secure boot and switch to legacy boot. If you do that then it should work fine. I have imaged 3 OP3040s with these settings.

When I captured the image a second time, it did not change the storage group id. The filesystem owner did change back to root, but that may not be an issue since ‘other’ has rwx permissions.

This may be in someway related to my migration from 0.32 to trunk as it only seems to affect my old images.

OS: Ubuntu 16.04
Fog:
Running Version 8515
SVN Revision: 5882

After capturing an image, I can no longer click on the image link from the image list to edit it or view information about it. This is due to the storage group no longer being associated with the image.

Prior to image capture, the image was associated with a storage node. After capture, the storage group was remove. I tested this on two different images and it happened both times.

Database table imageGroupAssoc before capture

*************************** 2. row ***************************
            igaID: 2
       igaImageID: 34
igaStorageGroupID: 1
       igaPrimary: NULL

Database table imageGroupAssoc after capture

*************************** 2. row ***************************
            igaID: 10
       igaImageID: 34
igaStorageGroupID: 0
       igaPrimary: 0

Note that the igaStorageGroupID has changed from 1 to 0. Switching the igaStorageGroupID back to 1 fixes the problem.

After capturing an image, the owner of the captured image directory is changed from ‘fog’ to ‘root’.

Prior to capture

drwxrwxrwx  2 fog root 4.0K Jul 6 11:05 OptiplexD1D4Fall2015

After capture

drwxrwxrwx  2 root root 4.0K Jul 12 09:58 OptiplexD1D4Fall2015

@Tom-Elliott I have to say, FOG has some of the speediest devs Y’all do great work. The migration from 0.32 to 1.3.0 was pretty straight forward and worked quited well. To be honest, I had expected more issues since I made such a big jump in versions but they were minor and easy to fix. This is a testament to how dedicated the FOG team and community are to this project.

For anyone still running 0.32 (if I was not the last hold out), the migration is straight forward. Follow the directions on the wiki and you will be up and running in no time.

Thanks for the help everyone.

@Wayne-Workman Yeah, give me a minute to fire up the old vm and I will generate a new dump. I have finished the migration and have changed all the passwords so that is no longer an issue. Can I still drop the history and user tracking data? There is almost 9 years worth and it makes the file around 70MB?