It is pure USB3.0 controller no USB 2.0.

But PXE booting is not the issue. It is indeed PXE booting with undionly.kkpxe. It is explicitly hanging on xfering the bg.png file; which is not the first thing that is transferred.

Reminds me of when the background image kept tripping up PXE booting Hyper-V 2012r2 VMs.

My turn!

Okay, the scenario:

• CentOS 7.2.1511

• FOG build 7394

• Kernels 4.5.1

• UEFI/BIOS set to Legacy mode only

• Secure Boot is disabled

• F12 Booting from PCI LAN > Realtek PXE B00 D14 ( Realtek RTL8153 USB Ethernet Controller (xHCI) v2.00 (05/20/15) )

Using undionly.kpxe it stalls at iPXE initialising devices.
Using ipxe.pxe it stalls at iPXE initialising devices, then eventually fails to DHCP.
Using undionly.kkpxe it stalls at http://172.19.244.13/fog/service/ipxe/bg.png… 12% or 39%

I have verified that each of the iPXE boot processes still work on other systems.
I can web browse to http://172.19.244.13/fog/service/ipxe/bg.png and see the graphic fine.
I have tried both USB3 ports on the Yoga with the same results.
I have updated the Yoga’s BIOS to UEFI (n1get62w - 1.41), Embedded Controller (n1ght44w - 1.21) just released 04/27.

'elp!

Did you ever try [SHIFT] + [SHUTDOWN] ?

It’s not a Windows 10 thing. A chkdsk + reboot prior to uploading is something I’ve been advocating hereabouts since Win95. It’s just good file system health management. It’s an easy and painless way to eliminate one avenue of problems for capture / deployment whether you’re mastering on virtual or physical.

On Windows 7- you’d property the partition and schedule a chkdsk at next reboot.

For Windows 8+ you CMD: chkdsk /offlinescanandfix

PartClone and Windows are both a bit twitchy about that. Especially when WinPXE booting to access the partition/drive. Adding files from a WinPXE can seriously fubar and ultimately poison the file system and OS if you’re not careful.

If you never encountered this before, you were lucky.

Are you building the original image on a physical machine or in a VM?

I haven’t starting building Windows 10 images yet, but have you tried “shutdown -s -t 0” from a CMD prompt?

Could you add a textual notice to the process that indicates that only the definitions are deleted and not the actual image files when deleting multiples?

So yer right.

Mounting the shared folder is easy enough, but NFS wants a block device with a file system, which a directory is not.

boo.

Back to an attached .vhd I go.

Oh I have other solutions alright, but it is THIS nut that I’m hoping to crack.

How to gurus?

The scenario:

1. Virtual Machine is built in Oracle VirtualBox 5.
2. Created a Shared Folder “images” in the VBox VM and pointed it to a local folder “C:\VirtualBox\images” on the Host OS (Windows).
3. CentOS 7.2 is installed to VM.
4. The folder /images is created in the VM in order to …
5. Install FOG build 7180. (if /images didn’t already exist, installer fails at setting up NFS)

• no biggie, /images can be moved easily enough.

I want to use that VBox Shared Folder “images” as my /images folder inside FOG instead of /images inside the CentOS VM.

I’m working my way towards what I think will be the answer, but I’m not there yet. I’m hoping someone here may know the 100% answer?

p.s there are further details surrounding GuestAdditions etc, that I will detail tomorrow from work.

How did you LLF?

I’m wondering now if the database backup failure was caused by the bloating of the history table like I experienced on another server? hmm …

Too bad I didn’t check for that.

You betcha. thx again!

Thanks Tom! It was indeed the history table. I did the following for happy, happy, joy, joy.

mysql -u root -p
use fog;
DROP TABLE IF EXISTS `history`;
CREATE TABLE `history` (
  `hID` int(11) NOT NULL AUTO_INCREMENT,
  `hText` longtext NOT NULL,
  `hUser` varchar(200) NOT NULL,
  `hTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `hIP` varchar(50) NOT NULL,
  PRIMARY KEY (`hID`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

Build 7180 on CentOS7.1.1503

Performing my monthly backups I have encountered one server that upon selecting Configuration Save from Fog Settings, has output a 927 MiB .sql .

Ordinarily I would expect a 4-9 MiB file.

What can I do to fix/trim this sucker down to size?

Host and Image export file sizes are normal.

Not quite an uninstall but it did the trick for what I wanted.

mysql -u root -p
DROP DATABASE fog;
mv /opt/fog /opt/fog.old

So I :

mysql -u root -p
DROP DATABASE fog;
mv /opt/fog /opt/fog.old

Then launched the installer and I’m your uncle.

Still no love for my original problem on this particular naughty server.

PXE booting without a DHCP is reallll hard.

I’ve always preferred `nuke the site from orbit’, but in this case I’m trying to avoid it.