@banana123 As a point of data collection, how did this disk get created in this state? This is not how the M$ installer creates the disk layout.
Through MDT its efi, c drive 99% of free, recovery partition 100% of free space.
Someone/thing had to create this format structure intentionally.
@Quazz said in Windows 10 single disk resizable, stuck on BIOS screen after process:
your first partition is missing essential flags (namely System and Active),
Only adding color commentary here: That is because it (the first partition is neither). The first partition is a recovery partition which isn’t typically bootable. While the partition layout is functionally ok, its not standard or correct. In almost all instances the uefi boot partition should be the first partition on the disk so the uefi firmware can find the boot files. It is possible to update the uefi firmware by creating an entry in the uefi boot manger to look for the uefi files on the second partition, that seems a bit awkward to do that for every system this image is deployed to. Its best to fix the partition table to match the MS standard layout. And again the recovery partition is not typically needed in an enterprise environment.
@banana123 Looks like your first partition is incorrectly identified as being resizable, which is likely at the root of your problems.
Though, it looks like that partition has been altered in some way.
Currently, FOS uses partition flags to attempt to identify “non-resizable” partitions.
As far as I can tell, your first partition is missing essential flags (namely System and Active), causing FOS to misidentify the partition as a normal NTFS data partition that should be resized.
@Sebastian-Roth and anyone else who worked on this, great work on continually improving the client that some of us rely so heavily on!
Did you happen to change the “fogproject” user account’s password on the Server? This account is only meant as a service account for FOG and is not meant to be used to manage fog. If you did, you must match the passwords in the following places:
Web Interface -> Storage Management -> [Your storage node] -> Management Username & Management Password
Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD
The local 'fogproject' user's password on the Linux FOG server
Server file: /opt/fog/.fogsettings -> password
The easiest method on fixing this if you did change the service account password (fogproject) on the server is to change that password on Ubuntu to match the other locations by doing this
sudo -i
passwd fogproject
You will be prompted to enter a new password. Please ensure it matches the password elsewhere.
IMO the partition table isn’t created correctly. The first partition must be the uefi boot partition. Without that partition the uefi bios can’t find the boot file and the system won’t boot. You can probably make it work if you modified the the bios setting to look on the second partition for the uefi boot loader, but its probably better if you just fix the partition layout,
Also I question the value of a recovery partition in an enterprise environment where it may be just quicker to reload the image with FOG than trying to recover the system using the recovery partition.
@Sebastian-Roth He’ll need newer inits that include the NVME package since it wasn’t included in the 1.5.7 package iirc.
@EduardoTSeoane said in Bottleneck on DATABASE:
@fry_p Yeah I read it, but my first hit is to keep it more simplest as posible, I think that before to start to implement that it’s bette to do lesser works, there are a few months than I’m thinking that myISAM is not an optimal engine for this, almost for me, and I’m alone as FOG Sysadmin and need to keep my workload under control, I have not much experience with clusters and load balancing, and it’s no so good.
When I can I share documentation about our installation and customizations.
Lone FOG admin? That sounds awfully familiar 
(I am too)
I have 0 experience with this other than the testing I did. Perhaps when I am recovered I will dig back into this using my work environment. I am glad you will share your findings when you find time and look forward to reading them.
Scalable FOG would really expand the usage of FOG (pun intended) in bigger use-cases. I understand this is all volunteer with everyone having day-jobs, so perhaps while I am on medical leave, I can set up a home lab. I have 2 servers, a few desktops, and proper networking equipment at home. IDK how I will replicate the number of clients we need to properly test large environments, but at least I can do some more proof of concept work.
Give me a few weeks (I will be couch bound at my parent’s place starting Feb 7th for about two weeks at least after surgery) to recover and then I can do some testing. If I don’t do something like this, I will most likely go crazy from boredom lol.
@Sebastian-Roth well then, today I learned! MSI’s only advantage is you can deploy via GPO I suppose. To my knowledge you have to call a script for an exe. Either way works. Thanks for the clarification.
@EduardoTSeoane It would be helpful if you could document the changes you have made to your fog installation. The developers don’t have FOG installations as large as what you have so its hard to simulate the workloads you are seeing. It would be helpful for both the Developers as well as other large campus FOG installations if you could share what you have learned. @fry_p does have a large campus network where he was working on a similar issue to what you have.
So it would be very helpful if you could share what you learned from your testing for everyone.