@george1421 The error message you posted basically means that the FOS Kernel (operating system) bzImage, doesn’t understand the format of its virtual hard drive (init.xz). We’ve seen that happen when the wrong pxe boot file is used or the bzImage file gets out of sync with its virtual hard drive (init.xz)
Posts made by george1421
-
RE: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled
-
RE: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled
@b.nelson I’ll follow up with my second question then;
What precisely do you have configured for dhcp option 67 {boot-file}?
And follow up with what hardware are you trying to pxe boot on? (mfg, model)
-
RE: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled
Was this an upgrade from a previous release of FOG?
What precisely do you have configured for dhcp option 67 {boot-file}?
-
RE: FOG Server complete on NAS (e.g. Thecus , QNAP)
Installing FOG directly on a NAS hasn’t been done as far as I know. We have setup a NAS as a FOG storage node, with the FOG server running on a small linux platform some place else.
The problem with running fog on a NAS is a couple fold.
- NAS’ typically have very limited RAM. Typically just enough to run the NAS’ OS with a little space for an plugins they might support.
- NAS’ typically have underpowered CPUs. They are sufficient for moving data from the local storage to the network, but they are typically not designed to run a local database. Many are single core Atom processors.
- Not all NAS devices use IA32 instruction sets. This isn’t a big deal as long as the arch used has a decent repository for packages.
- FOG relies on a lot of other 3rd party technology for imaging. Again this goes to the distribution’s repositories have to be robust. FOG uses a lot of PHP libraries, your NAS’s distribution must support them if the FOG installer doesn’t supply them directly.
With that said, I’ve run FOG on a Raspberry Pi2 and Pi3 devices. They do work surprisingly well for how small they are. I would almost put these devices in the same class as a consumer NAS. They run Cortex ARM 4 core processors and do have limited on board RAM. The advantage of a PI over a traditional NAS is that raspbian has a large support base so they have available all of the modules that FOG uses. I’m not saying that the Pi is an ideal solution. Its just one way to accomplish a very tiny deployment.
You can run fog in somewhat of a split mode, where FOG could run on a VM or (I guess) repurposed desktop hardware with all of the storage on the NAS. In this case you would setup the NAS to emulate a FOG storage node, where nothing would be stored on the FOG Master node.
You do have a few options. If you are skilled you could even manually configure FOG on your NAS, assuming their repo has all of the modules FOG installs from a traditional linux repo.
FOG uses the traditional LAMP stack (Linux, Apache, MySQL, PHP). If your NAS supports the AMP part then you might have some luck.
-
RE: Help with Mass Hard drive cloning station
@zionda First you know my answer will be a bit biased toward FOG
From a logic standpoint, wouldn’t you want to use the same tool to initially deploy your images as you would for ongoing imaging? This is where I think FOG is a perfect solution. The same tool used to originally image the machines will be also used if the target computer is damaged and must be repaired and reimaged some time in the future.
The scope of your question has changed a bit now. In your OP I had envisioned that you would been to image 100s of PCs at the same time (mass deployment). FOG works great for this with its multicasting ability (sending 1 image to many computers). With your latest post your work flow seems to be a bit different. You will have to manually touch each computer to replace its hard drive. You could use a disk duplicator here or you can use FOG and unicast a single image to the target computer. In my company, with our fat image ~25GB it takes about 4 minutes to push the image to the target computer. If you think about your cycle time that image is faster than you can replace the hard drive in the next computer.
Regardless of the approach you take, you need to consider how much after the imaging is complete you have to / need to touch the computer. Will you have to name the computer? Will you have to connect it to the domain? Assign it to a certain OU? Install additional applications? Install any local hardware peripheral drivers? Make any other post imaging customizations? How frequent will these systems be reimaged (daily, monthly, yearly)? All of these steps may need to be taken into consideration when determining your imaging solution.
The image push is only the first step in the imaging process. You have quite a few others to consider when going from bare metal to finished product.
-
RE: FOG-casting across VLANs (subnets)
Part 2 Pfsense Router setup
In this design, the pfSense router will perform 4 different functions.
- Provide the dhcp addresses to the clients on the deployment network [192.168.23.0/24]
- Provide the necessary dhcp boot options to pxe boot the clients on the deployment network
- Act as a normal router to route traffic between the subnets
- Act as a IGMP route (via its built in IGMP Proxy server). The IGMP server will listen on its defined upstream interface [LAN] for any defined multicast streams and rebroadcast the stream on any of the defined downstream interfaces [WAN]. Please note I’m only using the concepts of LAN and WAN as interface names. I could have just as easily used em0 and em1, but inside pfSense they reference the logical names of LAN and WAN exclusively. To avoid confusion I’ll continue to use those labels through this document, just understand the are label and not based on functional intent.
I’m not going to go through the setup of the pfSense router since there are many fine examples of setting up pfSense as a basic router. I will go through the settings I changed to configure the igmp proxy setting.
In the graphic above I configured the pfSense router’s
-
Set the LAN interface address to 192.168.50.250/24
-
Set the WAN interface address to 192.168.23.1/24
-
Configured the dhcp server on the WAN interface to issue IP addresses from 192.168.23.10 to 192.168.23.250.
-
For the imaging network, the default route points to the pfSense WAN interface of 192.168.23.1
-
Configured the netboot section of the WAN’s dhcp server to send out the
{next-server}
of 192.168.50.100 with a bios{boot-file}
of undionly,kpxe, ia32 uefi boot file of i386/ipxe.efi, and ipxe.efi for the x64 uefi boot file.
-
In pfSense
Advanced Configuration
I disabled all firewall rules. In this setup I want pfSense to act as a normal unrestricted router and not as a screening or firewall appliance.
-
You will need to go into the firewall rules and add one rule to each interface (LAN and WAN) that is an allow all to any
WAN rule
LAN rule
-
With the static route configured on your FOG server and the pfSense router now setup on the network, you should be able to ping the deployment network’s router interface [WAN] from the fog server. If you can’t then something is setup incorrectly on the iP router side. Don’t proceed until you have basic IP routing working correctly.
-
RE: FOG-casting across VLANs (subnets)
Part 3 IGMP Proxy setup
The IGMP [Internet Group Management Protocol] proxy will be configured to listen on its upstream interface and will relay the multicast stream to any subscribers on its downstream interface(s). The pfSense igmp proxy service can only support one upstream interface, but may have many downstream interfaces. Think of an upstream interface is one that will listen for multicast data streams and then will only retransmit the multicast stream to those interfaces who have requesting clients. This avoids flooding all subnets with the multicast imaging data if there are no clients requesting to be imaged. You can further optomize your network by enabling the IGMP Snooping feature on your network switches.
-
IGMP LAN settings
-
IGMP WAN settings
-
-
FOG-casting across VLANs (subnets)
FOG-casting or imaging multiple computers simultaneously using a single source image (and data stream) works really (really) well if the clients are on the same subnet as the fog server. If your network is properly setup FOG-casting to many computers on multiple subnets works really (really) well. If your network is not setup for multicast transmissions, FOG-casting across your subnets will simply and frustratingly not work, even though you can image a single computer with no issues.
Simply, sending a single image to a single computer (i.e. unicast data stream) across subnet(s) uses standard TCP/IP communications. If IP routing is setup on your network then unicast imaging will work without any network reengineering. When you introduce multicasting into a pure IP routing nework, the multicast data streams are typically stopped by the subnet routers. This by intent and design. To propagate a multicast data stream across your subnets you need to use a mutlicast router instead of a traditional IP router. Some traditional IP routers natively support multicast routing but many do not. Some IP routers have helper services that can be enabled (akin to dhcp-relay) to forward the multicast stream to known targets. If you have a low end or consumer grade router, you are simply out of luck. Well, not totally out of luck there are a few open source multicast routers (mrouters) or multicast proxy services that we can utilize to allow the multicast data streams to flow across the subnets.
This is a documented is intended to be a proof of concept tool to show how you could configure a network to allow multicasting between vlans and/or subnets. So, let me also preface this with I’m not a multicasting expert. This document may not cover the ideal design for all situation. My intent is to document the process that could be used to allow multicasting across or between vlans (which small SMB networks are not typically configured by default).
The following is how I setup the proof of concept configuration. For completeness this design was constructed using 2 ESXi servers. The first ESXi server contained the FOG Server and the second ESXi server contained the pfSense router and the pxe client. The WAN interface of the pfSense router was connected to the pxe booting client via a isolated vSwitch.
FOG Server Setup
For this test setup the FOG server was setup on a fresh Centos 7 box. Once the Centos box was configured and updated with the latest updates, FOG 1.4.0 (stable) was installed.
I copied one of my test Win10 images from my development FOG servers to this proof of concept [POC] FOG server and then manually created the Image settings in the fog web gui. I did create create a static route on the POC FOG server to map a route to 192.168.23.0/24 subnet via the LAN interface of the PFSense router. This is needed because the FOG Server’s default route pointed to the ISP Router. We need this static route to tell the fog server how to reach the 192.168.23.0/24 [imaging network] for pxe booting and to send command and control information to the pxe booting clients. -
RE: No Network Boot Option in BIOS
@srnairn Interesting it should not be throwing that error.
One last place to check is in /etc there is probably a dnsmasq.conf file you shouldn’t have anything enabled in that file except for the line that says to look in /etc/dnsmasq.d for more files.
The very first line of the ltsp.conf file says “don’t act as a DNS server” which uses port 53 what its complaining about.
-
RE: Fog Image Import Issue
@george1421 Before we get too crazy deleting stuff lets do this.
We probably should backup the current state of the database with this command run as an elevated user.
mysqldump --allow-keywords -x -v fog > fogbackup.sql
From there log into the mysql user too with
mysql -u root fog
You should end up at a mysql command prompt
MariaDB [fog]>
Then key in this command
select imageID, imagename from images;
your output should look similar to this:MariaDB [fog]> select imageID, imagename from images; +---------+-------------------+ | imageID | imagename | +---------+-------------------+ | 1 | Drivers Container | | 15 | WIN7OEMX64 | | 16 | WIN7ENTSP1X6401 | | 22 | WIN7ENTSP1X8601 | +---------+-------------------+ 4 rows in set (0.00 sec)
These are all of the records in your images table.
-
RE: Fog Image Import Issue
Your post has me a bit confused too.
From an image standpoint there are 2 parts.
- The raw data files that are stored in /images/<image_name>
- The metadata that is stored in fog’s database.
What you view in the web gui is the database information. There is no way to directly view the contents of the raw data files from the web gui.
Now with that said, I’m suspecting that your data you uploaded via the csv file is missing something that the webgui needs. We can clean this up by working directly with the mysql database.
-
RE: Mounting /images/dev Permission Denied
@vkenny said in Mounting /images/dev Permission Denied:
I know the next question is going to be why do you need 5 FOG VM’s. The reason is we have 5 independent networks that cannot be accessed by any other. Each network is on a different VLAN with different IP schema.
Does your ESXi server have the potential access to all of these vlans?
-
RE: No Network Boot Option in BIOS
@srnairn please post what you have in your ltsp.conf file.
Also post the output of this command
ls -la /etc/dnsmasq.d
-
RE: problems Loading Windows iso in advanced menu.
@Rayco said in problems Loading Windows iso in advanced menu.:
TOOL_NB64_W10GPT
Just hacking your file name here. So all of these systems you are pxe booting are in uefi mode? If so we have seen some pretty flaky uefi firmware especially on Lenovo systems. I’m not saying this is your issue, just we have seen the issue. It is the handoff between either PXE rom and iPXE or between iPXE and FOS.
There is also another way to pxe boot instead of an iso image (I understand that is desirable for portability). In the link I previously posted, there is an second method for pxe booting into WinPE: https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog/6 I’m not suggesting this will fix your issue, but its something you could try.
-
RE: problems Loading Windows iso in advanced menu.
@Rayco said in problems Loading Windows iso in advanced menu.:
initrd http://${fog-ip}/fog/service/ipxe/iso/asus/TOOL_NB64_W10GPT_V1.3.3.iso
Not specifically related to your issue, but I wouldn’t place your files in the FOG package path if you want your files to survive an update. I would recommend you move the iso director to a root level directory on your fog server. i.e. http://${fog-ip}/fog/service/ipxe/iso -> http://${fog-ip}/iso
-
RE: Compatibility optiplex 7050 test Network Fail
You’ll also want to update if that 7050 was purchased with an NVMe drive. FOG 1.2.0 doesn’t support NVMe drives or Win10 very well.
-
RE: Hard drive doesn't expand after image
@lukeD said in Hard drive doesn't expand after image:
Yeah, thanks for the hit. It is the postdownloadscript/driverinstall.sh I got from here https://wiki.fogproject.org/wiki/index.php/Auto_driver_Install and it tries to mount sda2.
@Wayne-Workman That wiki page is really old. We might consider taking it down since it will only cause pain moving forward as there is issues now with nvme drives.
-
RE: Hard drive doesn't expand after image
@Tom-Elliott I have a script that you rewrote to be a bit more generic that supports nvme drives.
#!/bin/bash . /usr/share/fog/lib/funcs.sh [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/" case $osid in 5|6|7|9) clear [[ ! -d /ntfs ]] && mkdir -p /ntfs getHardDisk if [[ -z $hd ]]; then handleError "Could not find hdd to use" fi getPartitions $hd for part in $parts; do umount /ntfs >/dev/null 2>&1 fsTypeSetting "$part" case $fstype in ntfs) dots "Testing partition $part" ntfs-3g -o force,rw $part /ntfs ntfsstatus="$?" if [[ ! $ntfsstatus -eq 0 ]]; then echo "Skipped" continue fi if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then echo "Not found" umount /ntfs >/dev/null 2>&1 continue fi echo "Success" break ;; *) echo " * Partition $part not NTFS filesystem" ;; esac done if [[ ! $ntfsstatus -eq 0 ]]; then echo "Failed" debugPause handleError "Failed to mount $part ($0)\n Args: $*" fi echo "Done" debugPause . ${postdownpath}fog.log . ${postdownpath}fog.drivers . ${postdownpath}fog.ad umount /ntfs ;; *) echo "Non-Windows Deployment" debugPause return ;; esac
ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/6