@arnaudrigole There is not much information in OPX390.pcapng. I see three DHCP discovery packets (probably from this machine) but nothing else related to DHCP or PXE booting. So this does not look like the boot process is being captured. As well I see “MSFT 5.0” being set as vendor class identifier in thos DHCP discovery packets. Is it windows asking for an IP address? Anyhow. This is not helpful, sorry.
Posts made by Sebastian Roth
-
RE: Impossible to boot on PXE......
-
RE: USB Boot target device into FOG OS Live (FOSL) for debugging
@george1421 said:
The one thing that is missing (I think) is once you have your usb flash drive, is a way to refresh the kernels as new kernels are released over time.
I really hope that we can get this streamlined into Tom’s compile tool chain. So if he builds new kernels and inits and uploads those to the website he could also add a current ISO to https://fogproject.org/isos for example. Self updating process within the ISO is not worth the scripting effort I reckon as we will have lots of trouble with NIC issues and people behind proxies. So if we update the kernel people just need to download the most current ISO again.
@Wayne-Workman said:
Just be sure to include “troubleshoot” in the name / menus so that people don’t get the wrong idea and think this is the way to go for every time they wanna use fog.
Sure we will! But this is still a very early stage and I am not sure how well this will work. Would you mind giving it a try? Just download the ISO, dump it onto an empty stick and try booting it on various machines/architectures. I don’t have access to different machines right now as I am not working at university anymore…
-
RE: Imaging issue, dhcp server?
@mitzayapa Great to see that you were able to fix this yourself. Looking at the packet dump helps quite often!
-
RE: USB Boot target device into FOG OS Live (FOSL) for debugging
@george1421 said:
The easiest thing for users would be for the devs in the fog program to either use dd or some process to capture a functioning usb and make that available for download for testing.
That’s exactly the point why I thought about an ISO image. Sure you can take an image (using dd or other tools) from a good prepared USB stick but to me that seams a bit like putting the cart before the horse (please don’t get me wrong, not meaning to be offensive here!)
Generating an ISO that is multiboot on BIOS and EFI (32bit and 64bit!) is possible without much effort. So Tom can add this step to his kernel compile/upload toolchain and we will have current kernel/init.xz and bootable ISO file ready to download for users all the time.
Hugh advantage would be that we only need one “simple” description of how to dump this ISO onto USB sticks. As well a generated ISO is just big enough to take up all the things needed. Whereas an image file (dd or what) is usually created with a fixed size. Sure you can grow/shrink it to suit your needs but it adds some unnecessary inconvenience to it.Thanks heaps for all the effort you are putting into this and all the tutorials you wrote. I am sure users will find this really helpful even if we end up providing an easy to handle ready to go ISO file!
I’ve played with syslinux (http://www.syslinux.org/wiki/index.php/Isohybrid) for about two hours just to find out that its UEFI support is still kind of young. Does not mean it is impossible to achieve but I found a way easier solution using GRUB2. To generate a FOG debug ISO I downloaded the kernel/init files, wrote a grub.cfg like you have, put it all in a local directory called ISO_root and called
grub-mkrescue -o fog_debug.iso ISO_root/
. This is on Debian Jessie. Out comes a ready to go ISO file which I can boot in qemu! Testing it on USB Stick now…Edit: Sorry, I was wrong. This simple command only generates an ISO usable on BIOS machines - at least on my BIOS machine right now. Might take some extra effort to generate BIOS/UEFI ISOs or just the right packages installed. Reading on…
Edit2: Needed to install grub-efi-amd64-bin and grub-efi-ia32-bin to have grub-mkrescure build a multiboot ISO. Here is a first try which also tries to detect 32/64bit Arch (grub cmd cpuid): https://drive.google.com/folderview?id=0B-bOeHjoUmyMM2c4LV90Z1NyNWc&usp=sharing (wow, 60 MB just for a plain BIOS/EFI 32/64bit debug ISO… may I ask you guys to give this a try on various platforms? Just dump it on USB stick using dd/win32 disk imager/unetbootin etc.)
-
RE: USB Boot target device into FOG OS Live (FOSL) for debugging
@george1421 This is a great idea!! (Wonder why I haven’t come up with this already )
Reading through your posts I thought about building a hybrid ISO file that people could dump onto their USB sticks. Might be a little easier for most users. But it’s not perfect as people still need to use tools like dd/unetbootin/… What do you think? At least it would be a little more straight forward instead of using grub here and syslinux in another case.
Edit: In the grub.cfg the kernel parameter “initrd=init.xz” is missing. Is this still working? Maybe this is only needed with iPXE but I remember we had trouble if we didn’t add this parameter.
-
RE: Dell Optiplex 3020 Micro with new Samsung SSD 850 EVO
@Aaron-Kearns said:
I tried using the original hdd, and I was able to begin registration of the host. I stopped and swapped in the ssd to see if I could get to the same spot, but I didn’t get that far.
That’s really interesting! Are you sure this is the case? Can you please try and confirm that it hangs if using the SSD when trying to register!? One of the first things that happen in the registration script is checking the hard disk. So this might actually be an issue. Can you then please register/add this host by hand (web GUI) and run a debug task for it. Does it boot up into the debug session? If so, please see what you get from those commands:
fogpartinfo --list-devices
,cat /proc/partitions
andlsblk
-
RE: Verification for downloaded kernel and initramdisk
You are the man Tom!! Hopefully this can prevent some of the kernel/init issues in the future.
Let me know if I can add something to it as well.
-
Verification for downloaded kernel and initramdisk
As we see trouble with corrupt bzImage/init.xz files quite often I wonder if we can add some kind of verification. Debugging this kind of error takes a lot of asking questions forth and back and causes a lot of confusion on both sides.
I haven’t really come up with a good idea yet. One way could be to download a checksum file with the kernel images and verify those checksums once in the installation process. Or we could calculate checksums every time a client requests bootmenu.class.php (probably slows down the bootup which is not good I think).
Any ideas on this?
-
RE: PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)
@Matthieu-Jacquart Hope we’re not asking too many things here from you. But would it be possible to take a short video of the whole bootup process. Sometimes there are small hints that we only see if we have it right in front of our eyes…
-
RE: Yet Another TFTP/PXE Issue?!?!
@cschneider-tech said:
When I run command tftp <192.168.13.236> GET undionly.kxpe it returns “The system cannot find the file specified”
After reading the whole lot it all boils down to TFTP not delivering files properly. This can be caused by firewall settings on the FOG server, missconfigured TFTP, permissions on /tftpboot and many more things. Please follow this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP
-
RE: Surface Pro 4 won't get to registration menu
Too bad that we don’t get any more news with higher log level. Tried some google foo (wonder why I didn’t do this earlier) and came up with this:
http://superuser.com/questions/1005825/linux-on-new-surface-pro-4
https://www.reddit.com/r/SurfaceLinux/comments/3zytfw/status_of_arch_linux_on_sp4/
https://www.reddit.com/r/SurfaceLinux/comments/3xhmu7/just_installed_chakra_linux_on_surface_pro_4_i7/
https://www.reddit.com/r/SurfaceLinux/comments/3w8du2/outofthebox_support_for_linux_mint_173_cinnamon/ (see the EDITs on Pro 4)There seam to be a lot of things that don’t work but I guess most of that is irelevant for cloning. By the way, have you disabled secure boot?
-
RE: HP Compaq Elite 8300 don´t boot
There you go, see the problem? bzImage32 and init.xz don’t go together! Should be bzImage+init.xz OR bzImage32+init_32.xz. Please check your FOG settings in the web GUI.
-
RE: Issue with FOG installation, Apache Web server
@j.schumacher99 said:
I’m sort of flying blind and any input would be great
Same here!! kidding
You need to be a bit more specific for us to be able to help. Which version of FOG are you trying to install? 1.2.0 or trunk?
Where do you want to install? CentOS, Fedora, Ubuntu, Debian, Arch?
Which error do you get (post the full error message!) when trying to install packages manually? -
RE: Upload Image from HP Probook 450 G3
@Seydoo Are you sure you are using the FOG DHCP server? I am asking because the config you posted shows “undionly.kpxe”. At some point you said something about changing to ipxe.pxe because of some Lenovo device. And from my understanding of iPXE we should not see this legacy NIC wrapper warning if you really use undionly.kpxe (maybe I am wrong here!!).
And there is something else I am wondering about. In your first post it says: “iPXE 1.0.0+ (53653)”. This is not the number of the official FOG 1.2.0 released iPXE binary (should be 3a02). Please check which version you see in the blue cloud in the web GUI. If it really is 1.2.0 then at some point someone has changed the iPXE binary.
Maybe you can try updating just that iPXE binary again to the very latest version and see if that helps. iPXE binaries are usually in /tftpboot on your FOG server. So maybe try this as root (hope I am getting this right, please pay attention when doing this!):
service xinetd stop mv /tftpboot /tftpboot.BACKUP svn export http://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/ /tftpboot chmod 755 /tftpboot chmod 644 /tftpboot/* service xinetd start
Then try again booting your device and see what you get.
Edit: Thanks for the PCI IDs. Those Realtek 8168 seam to cause quite some trouble here and there. Some revisions of this adapter behave well but others are a nightmare. Here you have two emamples: http://forum.ipxe.org/showthread.php?tid=7356 and https://forums.fogproject.org/topic/4173/realtek-8168-nic-issue-with-pxe-bootmenu
-
RE: PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)
@Matthieu-Jacquart There is no log file. You will see more output on the screen when your tablet boots up - if so. But maybe you won’t see any more information. Can you boot other clients properly? Just asking to make sure your kernel/inits are fine.
-
RE: Manually typing TFTP address after booting
@Quazz Thanks for letting us know. Please keep us posted if you see this again. You are probably better of using proxydhcp in your case!
-
RE: PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)
@Tom-Elliott Hmm, but I guess Matthieu’s setup is working for other devices, right?
@Matthieu-Jacquart As you are using FOG trunk (signature), can you please try to increase kernel loglevel and enable debug. You can find those settings in FOG configuration in the web GUI. Maybe we see some more info then.
As well I really like George’s idea to boot any kind of live Linux from an USB thumb drive to see if you can get Linux up at all. -
RE: PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)
@Tom-Elliott Maybe I am wrong but I think George is right about Matthieu’s request. Sounds like iPXE is working fine (using ipxe.efi/snp.efi) as it comes up with the menu.
Any option I choose, screen stay black after loading file bzimage and initzx …
Black screen after loading the kernel. It could still be related on how iPXE is loading the kernel on those devices but we don’t know yet I reckon.
-
RE: USB Boot BIOS client into FOG menu
@george1421 I do understand your intend to emulate PXE booting as close as possible. This is fine. I was just suggesting that it can be cut down by a fair bit. Right now I can’t see a reason why we would abandon loading default.ipxe straight away.
If you like you can edit your initial post and add this as a second step. Like, if loading iPXE worked for you, try loading default.ipxe to straighten things up. This is no have to!