Well trying to install centos 7 on a new out of box hard drive didn’t work I received the same error (something unknown happened). I might have an issue with the install media.

Taking a different approach, I downloaded and booting ubuntu 15.10 desktop. The installer had a live option so I booted successfully into that. I run zorin on my home laptop so I thought that ubuntu woudn’t be that foreign to me. Well, its kind of like traveling to the UK for holiday. (While we kind of speak the same language, there is just enough differences to get into trouble quick).

With that said here is the output of the lspci with different options.

lspci -vv (very verbose)
0_1448370335531_o7010vv.txt

lspci -k (kernel level drivers)
0_1448370353360_o7010k.txt

lspci -vn (verbose with hardware numbers and not names)
0_1448370383197_o7010n.txt

@Wayne-Workman said:

Fedora Server is a server OS. They have three different versions: workstation, server, and cloud.

I would also point out that Windows 7 uses the same kernel as Windows Server 2008 R2.

Well color me red (hat) and call me embarrassed (to a point), mea culpa.

Traditionally the fedora brand was the rapid development OS for redhat with many new/advanced functions. Some of those features would end up in rhel (centos) and some features would just disappear. With the rapid development cycles you may get a new version every few months (which is NOT what you need for a server OS). Some companies have regulations about NOT using outdated or unpatched software (including the OS). If you built your servers based on Fedora (any version of a rapid development OS) you would be in a continual update cycle just to stay current and within policy. That is why rhel, centos, ubuntu lts are all long term supported OS’. To give companies a stable and supported OS platform. Does this mean you shouldn’t use Fedora for a OS, no. A lot depends on your company’s regulations. Just because you CAN install MS SQL server on Win7, doesn’t mean you should. (If I remember MS’ Windows 7 EULA you are not allowed to use a desktop OS in a server role)

@Sebastian-Roth said:

So I guess this is more a UEFI/OptiPlex issue than a NIC issue.

This is what I was thinking. While it might appear to be a nic issue, it could also be another component pre nic setup.

I have downloaded Ubuntu 15 and will try to install on this Dell. I tried yesterday with Centos 7 and it kept crashing. I’m suspecting that its the hard drive that I was trying to use (not wanting to mess up the existing install), I just grabbed a disk from my bench and tried to install.

When I get to work in 2 hours I’ll see what happens and update you.

For clarity I run FOG under centos running on ESXi 5.5. I don’t have this kind of issue.

I know this was a long thread and I kind of skimmed it.

When you setup your linux server you should set the network adapter to e1000, you can use vmxnet3 if you install the vmware tools first. Its always has been a pain to do so I just use the e1000 driver. I seem to recall a bug with the e1000 driver with either the GA release of 5.0 or 5.5 that caused the virtual nic to hang under heavy load. That issue was fixed with a ESXi update. Is you ESXi server up to date with patches?

Please help me understand you say you can’t access the FOG server. I understand if you can’t access it via the network, can you log into the console directly using vmware configuration client? Or is the vmclient frozen? If you can log in from the console then I would sure check the logs in /var/logs to see if there is any indication of what happened. I would also try to restart the network services (from inside the fedora OS) to see if you can get it back online. I have see where two hosts having the same IP address will take a server off line like this.

It would be interesting to see what happens to this vm if you shutdown all FOG services at the end of the day. Is the VM still on the network in the AM?

[soapbox] While I understand the techie needs to run fedora, why are you using a desktop OS instead of a server OS? Would you load MS SQL server on Windows 7 for your enterprise application? Please pick stable rhel or centos over fedora. Yes I know it works, but why not use the right tool for the job.[/soapbox]

@Sebastian-Roth

I’m trying to remember the history with these Dells. It was either the 7010 or the 9020 we got hung up on with Windows deployment because the WinPE 2.0 environment didn’t have the drivers for the nic. We needed to upgrade to the next WinPE environment for it to have the drivers.

IPXE boot iso. I think the rom-o-matic had the option to create an iso image as well as a usb image. Im just wondering if the e1000 driver doesn’t support this intel nic. I have an older/different intel nic in this box in an expansion slot and that must not support uefi booting because I can’t select that card. I’m going to work on the linux/FreeBSD booting in uefi mode later tonight. Maybe I can glean more info on what hardware is installed.

@Sebastian-Roth No luck with the 32 bit version. It starts to load and then just kicks back to the Dell UEFI boot menu. I’m going to have to work on this later tonight. I’m learning more about uefi than I care to right now.

For a uefi boot from cdrom or usb flash drive the system must detect the uefi bits on the media or it won’t boot. That is why I can’t boot puppy linux via the uefi menu.

This decidedly simple request has turned into a big PITA. I was able to boot the system with puppylinux but I think what I have on my flash drive is the 32 bit version. I’m downloading the 64 bit version to try to boot via cd in efi mode. Here is what I extracted from puppy linux in 32 bit mode with lspci -v
0_1448303778683_dell_7010b.txt

FWIW: The centos 7 rescue DVD (and centos 7) no longer uses lspci but pciutils (which is not available in rescue mode).

@Sebastian-Roth I have was able to capture the screen and uploaded it here (since this is the first time I tried this process, the relevant information is about 50% of the way through the video. And the video is quite large because of the cruddy codec I used. As they say better next time:

https://www.dropbox.com/s/7t22wb4354njp56/1448293078345_ipxe_efi.avi?dl=0

One thing I noticed is your description 0_1448292948783_ipxe.efi did not match the downloaded file 1448293078345-ipxe.efi.

[Edit] FWIW this video doesn’t play well in VLC but it does in WIndows Media player. Sorry [/Edit]

A18 will work as long as you turn off the legacy ROMS. I did see that post too, btw. I just had to try it and it worked with the same results as you. So no better or worse then.

Well this is either good or bad. I get the same results as Wayne using 7010 bios A18.

Not sure if this has any bering on anything. But I checked into the dhcp discover and the 7010s are sending out arch type 7. I noticed that there are two different arch types. One is 7 and one is 9. There is also a arch 6 for 32bit. I guess the question I have is what is the efi boot kernel that is being built?

Type Architecture Name
---- -----------------
0 Intel x86PC (BIOS pre-OS environment)
1 NEC/PC98
2 EFI Itanium
3 DEC Alpha
4 Arc x86
5 Intel Lean Client
6 EFI IA32 (UEFI 32 pre-OS environment)
7 EFI BC (UEFI 64 pre-OS environment)
8 EFI Xscale
9 EFI x86-64 (UEFI 64 pre-OS environment)

@jbsclm interesting, I’ll have to give it a spin on Monday. The discussion with my colleague was about finding a way to uefi boot systems that have a broken net boot under uefi. This may be adapted to help with that issue too.

This one may actually work a bit better since it should connect you right to the FOG menu

set fogserver:ipv4 <ip_addr_fog_server>
set next-server ${fogserver}
chain http://${fogserver}/fog/service/ipxe/boot.php?mac=${net0/mac}

Funny I was just discussing this the other day with a colleague. I haven’t had a chance to put together a POC yet on this. But the general idea is to create the ipxe boot image on the usb device and then chain to the fog server using the command like Sebastian posted. On your USB boot stick you want to enter something like this: (Understand this just came out of my head, and may be filled with bugs).

set fogserver:ipv4 <ip_addr_fog_server>
set next-server ${fogserver}
chain tftp://${fogserver}/undionly.kxpe

That “should” tell the ipxe client using the boot media to chain to the fog server. Then the fog server will take over from there.

@need2 said:

I’m late to the party, but no I never got WDS and FOG to play well together.

@FlowLive was just able to do this. Its a bit down in the thread, but he has FOG acting as the PXE boot server then you can select the WDS environment from the FOG Menu.

I went the other way around and setup FOG to be able to boot the MDT litetouch image so that you can deploy through MDT from the FOG boot menu. Two different ways to have FOG and MDT/WDS coexist.

The normal PXE boot sequence is that it waits for the dhcp server to provide the dhcp IP address and then requests the dhcp option values of 66 (boot server IP) and 67 (boot file). For option 66 you should enter the IP address of your FOG server (not the conical name) and for 67 you should enter undionly.kpxe. Those settings will tell teh client what to do next. If you see some messages about iPXE then you have connected to the FOG server.

Lets start out by getting some background information.

I see you are running Ubuntu 14.04. What version of FOG are you running are you running the stable 1.2.0 or the SVN trunk release (pre 1.3.0)? If you are running the trunk release what is the number in the cloud (upper left corner or page) on the management console?

Now that is out of the way. Have you ever setup PXE booting before (FOG or something else)?

What did values did you set for DHCP option 66 and 67?

Here is a step by step for rhel 6 distros
https://forums.fogproject.org/topic/6074/extending-a-file-system-on-redhat-base-distros

I can’t help you with the fogstorage node issue, but I can with the space issue.

Actuality what I’m going to recommend will sound counter intuitive, but its the right move. Traditionally with *nix systems you place the /home and /opt directories on their own partitions/disks. These two partitions could potentially grow out of control filling up the root partitions ( / ) basically killing the *nix systems.

What I’m going to recommend is that you do the following.

1. Create a new VMDK file for your storage drive
2. Create a filesystem on that vmdk and mount it on /mnt/itemp
3. Stop FOG and all of its services
4. Move the contents of the /opt directory to /mnt/itemp
5. At this time /opt will be empty with the contents not under /mnt/itmp
6. Now unmount /mnt/itmp and mount that new vmdk on /opt (this will restore the contents of /opt but the files will now be on the new vmdk
7. Now for the last bit. Make a directory under /opt/fog called images
8. move the content of /images to /opt/fog/images (this will place all of your big files on this new vmdk file
9. Now that all of the contents are in /opt/fog/images delete the /images folder and create a symbolic link from /images to /opt/fog/images

You may need to check the file permissions before you start and after you’re done to make sure things are sane. But IMO this is a better setup than placing both the /images and /opt/fog/snapins on the root partition. In this setup the /opt directory (vmdk) can go to 100% and it won’t take down the OS.

But if you want to extend your current VMDK I did a write up a bit ago on how to do this with rhel 6 based system.

I guess a question that is still not clear to me is when you ran the install.sh on the current trunk, the installer “should” download the latest client. Did that step complete as expected? Or was there an error saying that needed to manually down it?

IF your fog server sits behind a proxy server you need to update wget (what the installer uses to get the msi) with your proxy server settings.

[Edit] Well if you followed Wayne’s instructions and it worked, then something in the installer or svn trunk is broken. The wget in Wayne’s instructions should have thrown an error if there was a proxy issue [/Edit]

I’m going to guess that its not possible to change the display order. There is no concept of display order in the database so I assume the display order is being set based on the record ID where boot from the hard drive is record ID 1. I would not recommend messing with any record ID to alter the display order.

You will receive much bad karma if you do go ahead with this plan.