Manually using VI is slow.

It’s far easier to simply copy and paste the command code in a single click.

Considering that disabling SELINUX is from your horses mouth, what’s the point of permissive?

I know about the checkout number differences. The difference at the time of my writing was that GIT is build 4714, and SVN is build 4716 (cloud graphics).

I’m assuming that the build number is built into the code when it is compiled before posting to GIT or SVN.

@ Press [Enter} key when database is updated/installed
– Browser visit http://x.x.x.x/fog/management

The page returned is 404.

p.s. It’s also interesting to see:

systemd-fstab-generator: Failed to create mount unit file /run/systemd/generator/images.mount, as it already exists . Duplicate entry in /etc/fstab?

… spitting out on the console window; I’m remoting in via shell and separately watching the vm during installation. Yes I already mounted /images before beginning the fog install.

GIT checks out installer for build 4714
SVN checks out 4037 which is the installer for build 4716

I see my mistake now. Though there is a /etc/sysconfig/selinux , I wanted to edit /etc/selinux/config .

To cover my bases I’m editing both. I suspect that the first is generated by the second:

setenforce 0
sed -i "s/=enforcing/=disabled/g" /etc/sysconfig/selinux
sed -i "s/=enforcing/=disabled/g" /etc/selinux/config

… and checking … yep, that did the trick.

Now for an actual Fog install.

Okay, next problem. I can’t get SELINUX to not start.

sed -i "s/=enforcing/=disabled/g" /etc/sysconfig/selinux
setenforce 0

… is not doing it. After reboot, sestatus shows SELINUX is still enabled.

Looks like this might do it:

if [ -f /etc/debian_version ]; then
fi

if [ -f /etc/centos-release ]; then
fi

This leads me to my next task.

How to detect the OS variant. Namely Ubuntu, Debian or CentOS An if then idea.

I’ve run into my first problem with CentOS that I haven’t found a direct solution for yet. It’s a difference in syntax for ‘git’ compared to Ubuntu/Debian.

Git in Ubuntu/Debian allows me to direct clone and pull to a specific path (/opt/trunkgit) using:

git -C /opt/trunkgit clone https://github.com/FOGProject/fogproject.git /opt/trunkgit
git -C /opt/trunkgit pull

Git in CentOS doesn’t have a -C . For now I’m making do with

cd /opt/trunkgit
git clone https://github.com/FOGProject/fogproject.git

… but, git then creates the directory /opt/trunkgit/fogproject and downloads to that. For updating I must then:

cd /opt/trunkgit/fogproject
git pull

I like my scripts to have as few differences as possible between OSes so I’m looking for a way for git to perform the same in all three.

Pausing to reflect on what I just wrote … I realize I needed to think in the other direction. This works:

if [ ! -d /opt/trunkgit ]; then
mkdir /opt/trunkgit
fi
if [ ! -d /opt/trunkgit/fogproject ]; then
cd /opt/trunkgit
git clone https://github.com/FOGProject/fogproject.git
else
cd /opt/trunkgit/fogproject
git pull
fi
if [ ! -d /opt/trunksvn ]; then
mkdir /opt/trunksvn
fi
if [ ! -d /opt/trunksvn/fogproject ]; then
mkdir /opt/trunksvn/fogproject
fi
svn co https://svn.code.sf.net/p/freeghost/code/trunk /opt/trunksvn/fogproject

My brain is cooked… I spent too much time in the sun at a Canine Agility competition today.

Interesting. My CentOS installation is less than half the size of Debian.

2.3GiB vs 5.3GiB
P.S. I got it even further down to 1.66GB, but then aha. I switched from XFS file system to ext4 and it’s now 5.5GB.

Got it. Thx.

Am I correct?

By the looks of it, the command:

yum update -y

is the CentOS equivalent of what’s used by Ubuntu and Debian:

apt-get clean &&
apt-get update &&
apt-get upgrade -y &&
apt-get dist-upgrade -y &&
apt-get autoremove -y &&
apt-get autoclean -y &&

mmm, thx. I will keep an eye tilted to that document.

Interesting installer for CentOS.

I’ve been quiet on the forums for a little while … busy time of year and all that with back to school.

I have a moment now where I’m re-deploying a few FOG servers and since Microsoft officially only publishes Linux Integration Services for Hyper-V for RHEL and CentOS, I figured I’d try my hand now at a CentOS 7 installation.

I’ve tamed Ubuntu and Debian for our FOG deployments. Wish me luck with CentOS!

I try to summarize what I’ve found in this new thread here.

Yes it is fixed. I set the message threads to solved.

What didn’t make sense?

Many, many thanks for all of your patience and assistance with this unusual problem that took so long to percolate until I had my eureka moment.

This article is the result of this previous thread.

I think I’ve figured it out.

When kernel 3.18.5 and earlier versions enumerate the interfaces in a 2012 R2.u1 Hyper-V Generation-1 Virtual Machine, it only has drivers to recognize the Legacy adapter (eth0). it ignores whether you have the ‘Ethernet’ adapter (eth1) connected to the virtual switch or not.

Kernel 3.18.5 then uses the 100Mb Legacy adapter (eth0) that it PXE booted from to transfer to/from the FOG server.

Beginning with my use of kernels 3.19.1 on up to the current version 4.1.4 kernel, I’m guessing that the driver for the Hyper-V ‘Ethernet’ adapter (eth1) is included. If the ‘Ethernet’ adapter (eth1) is disconnected, like I had been doing for kernels 3.18.5 and older, 4.1.4 will not fail back to use the ‘Legacy’ adapter (eth0), but will fail the process in an infinite spit out of CR+LF, or error out with network interface (eth1) not found.

If when using kernels 3.19.1 on up, the ‘Ethernet’ adapter (eth1) IS connected to the virtual switch at the same time as the Legacy adapter (eth0), the VM will PXE boot from the Legacy adapter (eth0), then uses the 'Ethernet" adapter (eth1) for the data transfer.

… and there was much rejoicing.

As a bonus, using the ‘Ethernet’ adapter (eth1) for the data transfer means using a 1Gb connection; ergo, roughly 1/8 the time required for data transfer.

It depends on where and how you want to focus your effort.

I already have extensive scripting and sysprep solutions for our deployments, much of which FOG can’t touch or isn’t built for, so it’s easier for me to use Microsoft’s existing tools then it is to look for a solution elsewhere.

Good news everyone! Now it’s my turn to be called an idiot… maybe

When FOG came in as our deployment solution I also quickly ramped up through server revisions (core and gui) to our current 2012 R2u1 and Hyper-V. My initial tests with Fog 0.29 with whichever version of Hyper-V it was at the time, showed that I couldn’t PXE boot properly unless I disconnected the Ethernet adapter from the Virtual Switch, leaving the Legacy Adapter connected alone. One or the other could be connected, but not both at the same time.

Annoying, but the workaround … worked; albeit at 100Mb.

I couldn’t sleep tonight (yep, it’s 2am) so I tried something other than Quick or Full Reg; I tried a Quick Image on the Hyper-V VM. This option didn’t exist on FOG way back in 0.29 or so. I expected Quick Image to fail with what appeared to be a controller /sda no hard drive and unable to register error that appeared when attempting Quick or Full Registration. This time though, I got an adapter error.

How can this be? I can PXE boot. The Legacy adapter is obviously working.

I double checked the VM. Yep, Legacy is connected, and the ‘Ethernet’ (synthetic) is disconnected.

Hmm … so I reconnected the VM’s main ‘Ethernet’ adapter to the same virtual switch as the Legacy adapter, so both were connected at once and tried again.

The bloody thing works.

I’m glad it works but riddle me this batman. Why does 3.18.5 work with either both connected or just the Legacy connected? … while 4.1.4 requires that both be connected?

The published 4.1.4 and your special 4.1.4 64bit at the http link above both work without dumping pre-emptible bugs now.