Hello mates.
I am working recently with new Intel nuc series NUC11ATKC2 and I have random problems, many times deployes stuck in aleatory % on BzImage or Init.xz but others times work correctly.
I update kernel to most newest and MAC address but the problem persist.
I use FOG 1.5.10, kernels 6.1.22.
Someone have the same problem solved?
Thank you in advance.
@rayco I solved this problem changging it manually.
nano ./fog/lib/pages/fogconfigurationpage.class.php
public function maclistPost()
{
if (isset($_GET[‘update’])) {
self::clearMACLookupTable();
$url = ‘http://linuxnet.ca/ieee/oui.txt’;; <-------------------------- Changing this link for; ‘http://standards-oui.ieee.org/oui/oui.txt’
Current Records: 31239 successful
Hello,
I never had problems with mac list update, but in my last update FOG cannot open http://standards.ieee.org/regauth/oui/oui.txt because isen’t a valid link now.
I visit ieee.org website and now the link is different; http://standards-oui.ieee.org/oui/oui.txt
How can I do manually update? or, How can I change updater url?
Thank you in advance.
Finally, I had to reinstall FOG and everything was fixed.
Thanks guys for the answers.
@sebastian-roth I have changed the partition part of recovery using partedmagic, placing the recovery before the partition of the system, with an identical result, but with great detail, once the deploy is done I can extend the partition of the system from within the windows itself, using the graphic environment in disk manager, extend partition. But the recovery stops working. I understand that this happens because the partition is not where the system points.
I am thinking that an easy solution would be to find in the bowels of Microsoft EDT the way in which it creates the partitions automatically and force it to place the partition originally before the one of the system.
@sebastian-roth correctly, I’m sure the problem is recovery partition.
I’m traying diferents methods but with unlucky results.
@quazz The weekend I deleted all images I had created in 1803, and today to pass you the logs of the partitions I did the whole process of capture and deploy again.
Could it be because the recovery partition is hidden?
@quazz I deployed on a 500gb hard drive in search of patterns, with the same result.
@sebastian-roth Thanks for response.
d1.fixed_size_partitions
:1:2:4
d1.minimum.partitions
label: gpt
label-id: FAD8F34F-08FC-4068-8435-9AFFAAA13980
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 60460795
/dev/sda1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFDA3487-867C-48F9-8177-810EF4EB6F0C, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=24E9E9B1-D1A8-4FED-818C-60FF804F64E7, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start= 239616, size= 27075584, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=7359A249-2F8A-42E8-AFDB-48FD43250DC5, name="Basic data partition"
/dev/sda4 : start= 58615808, size= 1843200, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=68BF7C08-141B-4607-BC65-A537B0ECDC5E, name="Basic data partition", attrs="RequiredPartition GUID:63"
d1.partitions
label: gpt
label-id: FAD8F34F-08FC-4068-8435-9AFFAAA13980
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 60460795
/dev/sda1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFDA3487-867C-48F9-8177-810EF4EB6F0C, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=24E9E9B1-D1A8-4FED-818C-60FF804F64E7, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start= 239616, size= 58376192, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=7359A249-2F8A-42E8-AFDB-48FD43250DC5, name="Basic data partition"
/dev/sda4 : start= 58615808, size= 1843200, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=68BF7C08-141B-4607-BC65-A537B0ECDC5E, name="Basic data partition", attrs="RequiredPartition GUID:63"
For more details, I attached some SS.
Template image:
Source master image in ssd 30Gb:
Deployed to HDD 1Tb:
I tryed to swap system partition with recovery, with the same issue, deployed:
Hello mates.
I have worked correctly with windows images without recovery partition, but now, for production reasons I have to make a new image with recovery partition.
I am working with Express Deployment Tool and it automatically generates the partition for me.
The problem that I have, is that when configuring the template as a single disk rezisable does not expand all the gigabytes.
For example, when I deploy to 240Gb SSD, it gives me an unpartitioned 3.4Gb, with no partition at the end of the disk.
If I do it on a 1Tb HDD, it leaves me at the end of the disk without partitioning, almost 34Gb.
As I mention, in other versions without the recovery partition at the end it worked correctly. Before creating the image I have also changed the partitions of place, putting the partition of recovery ahead of the system and it has worked, but the function of restoring the computer fails.
Has anyone had any similar problem with the hard disk regain?
Running Version 1.3.5
SVN Revision: 6067
Hello guys.
Finally, with wimboot systems work fine in all computer.
This was the code:
#!ipxe cpuid --ext 29 && set arch amd64 || set arch x86
kernel http://${fog-ip}/iso/asus/133/wimboot
initrd http://${fog-ip}/iso/asus/133/BOOT/BCD BCD
initrd http://${fog-ip}/iso/asus/133/BOOT/BOOT.SDI boot.sdi
initrd -n boot.wim http://${fog-ip}/iso/asus/133/SOURCES/BOOT.WIM boot.wim
boot
Thank all, a lot.
Thanks you guys, I appreciate your advice, I will change the path of the iso folder, adopt wimboot system, and will check it tonight.
THX a lot !!!
initrd http://${fog-ip}/fog/service/ipxe/iso/asus/TOOL_NB64_W10GPT_V1.3.3.iso
chain memdisk iso raw ||
goto MENU
This is a config menu.
@Tom-Elliott
If some computers work well, I must think that those that do not work is by the configuration of ipxe?
I will check it, in few hours I answer you.
If one model fail, all of this models fails too. But if burned in to bootable cd, work fine.
Thank you a lot.
@george1421 Thanks for your interest.
We have one WinPE for each Laptop model. In some models work fine, in other not, but in one cd bootable work fine in all.
Each one has his own WinPE, some models use the same WinPE.
Yes, they have the same size in bytes.
When one model work fine, work fine in all of the same model.
We think the problem is on some hardwares configurations.
I will test your suggestion of remove bootfix.bin.
@george1421 Thank you for ur fast answer.
All computers have bios updated and WinPE’s has drivers incluided.
I got a screenshot with the trouble. I think we have a problem with a trunked image when go to mapped in memory. (But not all computers fails, several do it nice)
Maybe we have a problem with image or drivers?
Thank you a lot.
Hi, I have the same problem, but not in all computers.
Some computers work fine, and load WinPE correctly.
But others computers loaded at 100% iso file, and did a self restart.
Someone with a idea ?
I cheked cables and switches too.
[Sat Apr 29 00:00:34.054499 2017] [:error] [pid 1136] [client 192.168.67.11:61226] PHP Fatal error: Uncaught exception ‘UnexpectedValueException’ with message ‘RecursiveDirectoryIterator::__construct(/var/www/html/fog/service/ipxe/iso/asus/EFI/Microsoft): failed to open dir: Permission denied’ in /var/www/fog/commons/init.php:125\nStack trace:\n#0 [internal function]: RecursiveDirectoryIterator->__construct(‘/var/www/html/f…’, 4096)\n#1 [internal function]: RecursiveDirectoryIterator->getChildren()\n#2 [internal function]: FilterIterator->next()\n#3 /var/www/fog/commons/init.php(125): iterator_to_array(Object(RegexIterator), true)\n#4 /var/www/fog/commons/init.php(344): Initiator->__construct()\n#5 /var/www/fog/commons/base.inc.php(48): Initiator::startInit()\n#6 /var/www/fog/management/index.php(22): require(‘/var/www/fog/co…’)\n#7 {main}\n thrown in /var/www/fog/commons/init.php on line 125
You were right. They were just permission problems. Sorry for the silly question.
“sudo chmod -R folder/” , for repair.
Thanks for the fast response.
Hello.
I’m following this manual; ( https://wiki.fogproject.org/wiki/index.php?title=Include_any_ISO_in_the_FOG_Bootmenu ) for integrate HIRENS in iPXE Boot Menu, but when I extract ISO file in to “/var/www/html/pmagic/” folder, website show me a “ERROR 500”. Then I delete this folder “/pmagic”, and website return to work fine.
I need re-install fog? migrate to trunk?
Apache is ok al all times.