Posts made by george1421

@tom-elliott Let me confirm. I should have worked, or I wouldn’t have documented it in 2015

It may take me a bit to setup that environment again.

First of all, I can say No I haven’t worked with the 3379.

But from your post its hard to tell what’s not working? Where are you getting an error? A clear screen shot of the error would be helpful in understanding the context of the error.

@tom-elliott OK I stand here a bit red faced. I missed that this was in iPXE still. Too many threads, and not enough extra brain cells to pay attention all the time.

@george1421 The instructions are for pxe booting the MDT wim file, but also applies to any generic wim file.

When I say the alias I’m referring to these in the parameters section.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot

Specifically the line
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD

Notice that after the file to load there is BCD in upper case characters. Those are the alias values I’m talking about.

Directly taken from that post:

Method #2

This second method involves taking the LiteTouchPE_x86.wim and LiteTouchPE_x64.wim created in the MDT environment and combining them with elements of the WAIK to create a directly bootable MDT litetouch image that can be launch via FOG’s ipxe menu.

1. On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.wim and LiteTouchPE_x64.wim.
2. Download the Windows Automated Installation Kit (WAIK) for Windows 7 from the following link: http://www.microsoft.com/en-us/download/details.aspx?id=5753
3. Install WAIK on a development system (workstation). You will only need WAIK installed long enough to extract the boot images.
4. Once WAIK is installed Follow this path Start menu->All Programs->Microsoft Windows AIK->Deployment Tools->Command Prompt. Selecting this menu should open a cmd shell. This next step we will create both the 32-bit and the 64-bit versions of the WinPE boot environments. In the command shell key in the following:
   mkdir %temp%\fog\mdtboot
   copype x86 %temp%\fog\mdtboot\x86
   copype amd64 %temp%\fog\mdtboot\x64
5. Download wimboot from this link: http://git.ipxe.org/releases/wimboot/wimboot-latest.zip
6. Extract the wimboot file from the zip file and save the (wimboot) file only in the follow folder: %temp%\winpe\fog
7. Copy LiteTouchPE_x86.wim and LiteTouchPE_x64.wim from the MDT deployment share to the %temp%\fog\mdtboot folder
8. Using 7-zip or similar tool create a zip file of %temp%\fog*.* as mdtfog.zip
9. Move the mdtfog.zip file to the FOG web server’s base directory (either /var/www/html or /var/www depending on the linux distrobution).
10. On the FOG server navigate to the FOG web server’s base directory as indicated in step 7
11. Use the linux unzip program to extract the mdtfog.zip archive to the web server’s base directory using this command: unzip mdtfog.zip (warning if unzip is not installed for your linux distrobution you will need to install it using the following command [rhel based] yum install unzip -y [deb based] sudo apt-get install unzip )
12. From the FOG management GUI select the following Fog Configuration->iPXE New Menu Entry
13. Fill in the following details:
    Menu Item: winpe.BootMDT
    Description: Boot MDT LiteTouch
    Parameters:
    cpuid --ext 29 && set arch x64 || set arch x86
    kernel http://${fog-ip}/wimboot
    initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
    initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
    initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
    boot
    Menu show with: All Hosts
14. Your configuration should now be set to boot MDT via the wim images from within the FOG PXE menu.

Interesting. That ID translates to a Realtek RTL8153

A quick trip to the realtek store: http://www.realtek.com.tw/DOWNLOADS/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false shows us this for a driver.

FOS Is currently running 4.11 as its kernel. So (Mr. Kernel Guy, you know who I mean), does this mean that the realtek driver won’t compile under 4.11 or they only tested it up to 4.8? Is that something that can be integrated into the FOS kernel for a small fee?

Look at Method #2 here: (scroll down a bit to find it)
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

Different wimboot file but the same process. At first glance you are missing the alias names. Remember that case is important.

@predator

Simply the setenforce 0 disables selinux (think MS Windows UAC) off without having to reboot your server. Updating the selinux conf file will make the change persistent across reboots. We are recommending you set the value to permissive. This is done so that selinux will record the events but not block them. If you require selinux enabled because of your company’s security policy you can take these logged events and create a selinux profile. This fog selinux profile then can be enabled to allow FOG to run while selinux is enabled.

@jphipps Does this firewall filter internal traffic or only external traffic (not generated by your site)? I probably worded that poorly. What I’m trying to identify if there is any restrictions to internal routing between the sites.

@jacoboren PHP 7 should work no problem. Most of the major disrobutions have moved to php 7 in their current OS releases.

Attempt to login with AD credentials, then access the FOG server linux console. There should be some AD log messages in the Apache error log. Depending on the OS the log file will be in /var/log/httpd/error_log or /var/log/apache2/error.log Tail that file to see any ldap errors. Please post the errors here.

Also I noticed from your original post, are you keying in the domain with the user name domain\user ?? I think the code requires just user because the domain is set in the LDAP connector code.

@jphipps As long as routing is working then FOG should be happy. Each local dhcp will point to the local fog server. If you are using the fog client then your fog clients will need to “check in” to the FOG Master node for instructions. Depending on the size of your organization that may add load to your site to site link. The FOG servers use FTP to replicate from the master node to the storage nodes.
While its possible to run in a network where there is a firewall between the sites, its easer to setup if you don’t have any network restrictions between your sites.

Just thinking about this. If it was me and I planned on deploying Linux client OS to target machines, I would not choose to use LVM (with expanding partitions or not). The issues is that FOG / partclone can only capture / deploy the image as raw. This is a slowest way of deploying the image. I would use native partitions on the disk.

Right now deploying that captured LM partition will take about 28 minutes to finish. The native partitions are much faster.

For ubuntu/kubuntu by @kmstory https://forums.fogproject.org/topic/10403/boot-iso-from-ipxe-menu/5 Note that you will need to place the ubuntu extracted images in /images/ubuntu on the fog server to access them via nfs. If you are using fog 1.3.0+ you can use the built in functions to build the ipxe boot menu.

kernel nfs://${next-server}/images/xubuntu/casper/vmlinuz.efi
initrd nfs://${next-server}/images/xubuntu/casper/initrd.lz
imgargs vmlinuz.efi acpi=off root=/dev/nfs boot=casper netboot=nfs nfsroot=${next-server}:/images/xubuntu locale=en_US.UTF-8 keyboard-configuration/layoutcode=us mirror/country=US
boot

Actually there is another thread that is discussing deploying a LM target OS at this moment. I think deploying it that way (as you would any target OS) would be a better solution.

But in regards to pxe booting into the iso, since LM is akin to ubuntu there are instructions for that.

@tom-elliott said in Failure to expand shrunken resizeable image from Linux machines:

I’ve tried for all I’m worth, but I’m only one man, sorry.

Tom, to be honest, as I posted before about 90% of the deployments are MS Windows, with about 8% Mac and the rest other bits (my feels like numbers). With MS doing its Win10 crap hopefully more will start to migrate to Linux based desktops. When issues arise you jump on them with both feet. The key is knowing about the issues to fix.

@xipher said in Failure to expand shrunken resizeable image from Linux machines:

@george1421 Close to my findings wherein the first partition (sda1) will grow proportionally, but the rest… no go.

If you create the same layout but have the root partition where you currently have the boot partition, it will grow the root and ‘work’ as it seems it would be intended.

If you were to make a home partition in the same place, it would grow but not the boot or root… etc

IMO In the case of Mint with the lvm. I would consider the /boot and [swap] partitions to be fixed in size. This would equate the System partition of Windows. In my ignorance I would have expected the disk layout to match the source image and have 15GB of air left in the target disk. Since LVM partition is copied as raw and both the /boot and [swap] were fixed.

My goal here was to see if I could come up with a way to extend the lvm disk.

I was just looking at my ubuntu example and I found something not right. The image is LVM so FOG can only copy that in raw mode. So no expansion can happen (this is A reason for using standard partitions). But when I went from a 50GB original image to a 65GB target computer is grew the /boot partition to by 15GB (the difference between 50 and 65). I would have thought that the /boot partition would be a fixed size partition (as with MS Windows). I created a new LM master image based on LVM and it happened the same as with ubuntu. My original intent was to have some extra space in the physical disk so I could test some LVM expansion tools.

Linux Mint with LVM defaults.

jondoe@jondoe-VirtualBox ~ $ lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                  11:0    1 1024M  0 rom  
sda                   8:0    0   65G  0 disk 
├─sda2                8:2    0    1K  0 part 
├─sda5                8:5    0 49.5G  0 part 
│ ├─mint--vg-swap_1 253:1    0    1G  0 lvm  [SWAP]
│ └─mint--vg-root   253:0    0 48.5G  0 lvm  /
└─sda1                8:1    0 15.5G  0 part /boot
jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem                 Size  Used Avail Use% Mounted on
udev                       474M     0  474M   0% /dev
tmpfs                      100M  3.6M   96M   4% /run
/dev/mapper/mint--vg-root   48G  5.0G   41G  11% /
tmpfs                      496M  168K  496M   1% /dev/shm
tmpfs                      5.0M  4.0K  5.0M   1% /run/lock
tmpfs                      496M     0  496M   0% /sys/fs/cgroup
/dev/sda1                   15G   67M   15G   1% /boot
cgmfs                      100K     0  100K   0% /run/cgmanager/fs
tmpfs                      100M  4.0K  100M   1% /run/user/108
tmpfs                      100M   20K  100M   1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $ 

@hregis You didn’t mention you had other storage nodes in the group. This error is still consistent with what I said. Each fog server or fog storage node has a built in user account called fog that is created by the fog installer. On your FOG master node (the one that has the mysql database) it needs to know the value of this fog user password on each storage node (including the master node). These values are kept in the storage management section of your fog server. I would focus on the server listed in your error message. Make sure the storage node settings are correct for that server.

For some background on this error. FOG uses FTP to manipulate image files on remote storage nodes as well as replication to remote storage nodes. If this password isn’t right you will get the error above.

This user ID and password is listed in the storage node configuration.

We typically see errors in this area when people change the password for the linux user account fog. We have seen people attempt to use the linux user account fog for system management. This linux account fog is an internal account used by the FOG system.

If you have changed this user account password you will need to resync the system. The current value FOG keeps in the file /opt/fog/.fogsettings. Take this value and reset the password for the linux user fog. Then go into the storage node settings for the fog server and ensure the management password matches the .fogsettings file. Once that is done, rerun the FOG installer installfog.sh to fix the rest of the bits.

For the next test I spun up a 50GB ubuntu image (knowing the default layout is on lvm) and captured that. We all know since the disk layout is LVM FOG will capture the lvm partition as raw even for single disk resizable. That means the LVM partition is not resizable from within FOS at this point.

Here is the ubuntu reference image layout

Here is the ubuntu image deployed to a larger hard drive (65GB target vs 50GB reference image) target computer.

Here is the results of trying to deploy a 50GB captured image to a 25GB target computer: