@GreenItSolutions Great to hear that it’s working with a dump switch. Please let us know when you find the solution and explain it here for other people who might run into the same issue… Thanks in advance!
Posts made by Sebastian Roth
-
RE: Windows 8.1 + FOG Server 1.2 revision 7001
-
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec Looks good! What about the commands??
kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 imgstat imgfetch http://x.x.x.x/fog/service/ipxe/init.xz imgstat boot
-
RE: Dell E6410 - Solid State Drive (SSD) Compatibility
@Omanimous Well, I am not sure what this means now? Tom already pointed out what is wrong with that image… So what happens if you set the type back to resiable and re-upload the whole image from the source disk??
-
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec It seams like it is able to load the kernel via HTTP as imgstat shows correct file size as well. But it is not able to select it for booting. Usually this only happens if that kernel is older than version 3.16 because EFI_STUB was added then. But from what I have seen so far you are using the normal kernel that FOG installed for you and therefore should not have an issue with EFI_STUB!! So here is a debug enabled ipxe.efi binary for you to test - install on the FOG server like this:
sudo -i cd /tftpboot mv ipxe.efi ipxe.efi.orig wget -O ipxe.efi https://forums.fogproject.org/uploads/files/1459426655465-ipxe.efi
Then boot your client. This will bring you straight to the shell now as I did not embed the full iPXE script we usually have. As well you will see colored debugging output. Try the exact same commands then last time and take picture(s) along the way.
-
RE: Private key failed
@raumin There have been so many error messages and solutions… Please open a new topic and post your own error messages there! Including FOG version, OS, OS version, …
-
RE: Windows 10 UEFI PC opens from fog server but boots into Windows instead PXE
@hariskar Please get another pcap dump and while it is waiting access this URL from your browser: http://192.168.1.5/fog/management/index.php?node=client&sub=wakeEmUp&mac=00:00:00:00:00:01 (put in your client’s MAC address instead)
-
RE: Windows 10 UEFI PC opens from fog server but boots into Windows instead PXE
@hariskar Thanks for log info and the new PCAP. It’s empty again… I am kind of lost with this. Will check the code to see how we can further debug this.
-
RE: Virtualbox image fails
@Quazz I thought about that a couple of times but never got to it. As well I am not exactly sure if we always have the information (original disk size) available. It’s probably easy to grep (and then calculate) if we have d1.partitions but would be a little bit trickier to get from d1.mbr (although possible I suppose). Would you please open a new topic in “Feature Requests” section and we see what we can come up with.
-
RE: Windows 8.1 + FOG Server 1.2 revision 7001
@GreenItSolutions Usually this is due to an issue in your network setup. Your description is very brief but from what I read between the lines you get the FOG menu but when selecting options like “Quick image” or “… registration” the host hangs when trying to get an IP. For this you need to understand that for the client to show the menu it needs to request an IP via DHCP twice already (PXE boot ROM and iPXE)! So this is not a general DHCP/network issue but usually caused by:
- Faulty patch cables (don’t laugh, we have seen this)
- spanning tree (configure your client port to ‘port fast’!)
- ethernet energy saving (disable EEE/802.3az on your switch if it has those!)
- auto negotiation problems (configure to 100MiB or 1GiB fixed speed for this client port)
If non of the methods help please give detailed description of what you tried and what happened. Otherwise we need to guess and go mostly wrong. As well tell us more about your client (model, NIC (PCI IDs!), …).
Please report back if you could make it work. What exactly did you do? This will be useful for other users in the future.
-
RE: Windows 10 UEFI PC opens from fog server but boots into Windows instead PXE
@hariskar said:
[03-31-16 11:52:20 am] * 0 active tasks waiting to wake up.
[03-31-16 11:52:20 am] * No tasks found!Did you actually schedule a task when capturing the PCAP dump?? Sorry for asking those questions but I cannot help myself. WOL is working great here and I cannot reproduce what’s going wrong on your system.
-
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec Are you absolutely sure secure boot is disabled?? I just remembered the
imgstat
command - please see what you get from:kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 imgstat imgfetch http://x.x.x.x/fog/service/ipxe/init.xz imgstat boot
If this is not giving us enough hints we might need to compile a debug enabled binary for you… Just noting down the debug flags here for later (
realtek,netdevice,image
). -
RE: FOG menu don't boot Windows - Chainloading failed
Those receive errors in the picture (“Operation not supported” and “The socket is not conected”) should not cause the problem. Those usually mean packet dropped because of unknown protocol (e.g. IPv6) or wrong destination (e.g. ignoring spanning tree broadcasts).
Sizes of bzImage and init.xz seam ok to me. As well the installer does checksums nowadays and we should not see corrupted kernels on the FOG server anymore.
-
RE: Dell E6410 - Solid State Drive (SSD) Compatibility
@Omanimous Well, the fdisk output is telling a different story:
Disk /dev/sda: 119.2GiB, 128035676160 bytes, 250069680 sectors ... Sector size (logical/physical): 512 bytes / 512 bytes ... /dev/sda2 616448 488392703 243008128 7 HPFS/NTFS/exFAT
Your current disk (the SSD I suppose) has 250069680 sectors (multiplied by 512 byte sector size ~ 120GiB). But the partition sda2 which was created by dumping the d1.mbr file (MBR including the partition layout) to your SSD ends on sector 488392703 (multiplied by 512 byte sector size ~ 233GiB). So either your source disk was actually larger or it used a smaller block size (never ever seen this! Not talking about file system cluster size or something but actual disk block size). Please upload
/images/DLE6410TU/d1.mbr
here in the forum and I might be able to find out a little more.image type was already set to resizable
What do you mean by this? From all the outputs (logs and files in /images/DLE6410TU/) this is NOT a resizable image. If you change image type you always need to re-upload/capture the image again!!
-
RE: SVN 7009 FTP errors after image capture: Updating database failed, ftp_login(): Login incorrect
@mr626 It’s all over the forums. Try searching…
It means that your FTP credentials are incorrect. This usually happens if you change those but don’t reflect the change in /opt/fog/.fogsettings. When re-running the installer things mess up. Follow this article: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP and don’t forget to get your .fogsettings correct as well!
-
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec I just tested loading kernel and init without the full URL again and it is working for me. This is kind of weird. Can you please try again using the URL (put your FOG server IP instead of x.x.x.x):
ifstat kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 ifstat imgfetch http://x.x.x.x/fog/service/ipxe/init.xz ifstat boot
-
RE: Windows 10 UEFI PC opens from fog server but boots into Windows instead PXE
@hariskar The PCAP file is completely empty. Either something went wrong with capturing or your server does not send WOL packets. The ServiceMaster Log looks ok to me! Please check the FOGScheduler log again. Change “Number of lines” to 1000 so you see it all. On (re)start the scheduler should print the FOG logo and then a couple of lines like:
Interface Ready with IP Address: ...
Please post that part of the logs here.
-
RE: no default.ipxe
@Tom-Elliott said:
derp guessing I was in systemctl mode thinking lol.
I guess so… Funny thing is that this was wrong for months and no one noticed. In earlier versions (before NYE) we even had sysvinit and systemctl mixed up…
chkconfig $dhcpd on >/dev/null 2>&1 service $dhcpd restart >/dev/null 2>&1 sleep 2 systemctl status $dhcpd >/dev/null 2>&1
-
RE: no default.ipxe
@jdmg94 I think you found a bug which nobody has noticed for quite some time… see my patch - I guess you can add this yourself and let the installer run again!
@Tom-Elliott (untested) patch proposal:
diff --git a/lib/common/functions.sh b/lib/common/functions.sh index 7f9347f..2aaea23 100755 --- a/lib/common/functions.sh +++ b/lib/common/functions.sh @@ -1878,7 +1878,7 @@ configureDHCP() { sleep 2 service $dhcpd start >>$workingdir/error_logs/fog_error_${version}.log 2>&1 sleep 2 - service status $dhcpd >>$workingdir/error_logs/fog_error_${version}.log 2>&1 + service $dhcpd status >>$workingdir/error_logs/fog_error_${version}.log 2>&1 ;; 2) sysv-rc-conf $dhcpd on >>$workingdir/error_logs/fog_error_${version}.log 2>&1
-
RE: no default.ipxe
@jdmg94 Should be
dhcpd
for CentOS, see inlib/redhat/config.sh
(second line from last). -
RE: Virtualbox image fails
@wdmartin As you see in the first screen it says /dev/sda1 where it shows /dev/sda2 in the second screen (
Not expanding ...
). So the 100 MB is only the first partition but not the whole image. The second partition fails. My guess is that the destination disk (in the VM) is simply too small to fit the sda2 image!Please check the original partition table (
/images/<image-name>/d1.partitions
) on the FOG server to see what size the original disk was. You need to create the VM disk at least that big in your case - using legacy format partimage and sda2 obviously being a RAW/imager partition. Post the contents ofd1.partitions
here and we should be able to help you calculate the original disk size.