@tomas-voboril The button would still be visible, but I am fairly sure it would not work.

@Rudolf So Fog can do what you want there’s just a few steps you skipped.

Fog will essentially do the same idea of copying the SSD from one to another but in a more centralized manner with more customization capability.

Basically, you need to

Install and configure the OS on a Virtual or Physical machine (virtual is easier to maintain if you already have a virtual infrastructure) Capture the image of that machine with fog Deploy the image to hosts

See https://docs.fogproject.org/en/latest/capture-an-image and https://docs.fogproject.org/en/latest/intro for some more info.

You can also expand further with customization of how you update your reference image, with windows there’s sysprep and other tools to help create a reference image, I’m sure linux has tools as well, I’m just not as well versed in them.

You can also edit the fog pxe menu to boot to an iso, I’m sure we have some examples in the forum for that.
There are also pre/post scripts so you can have a linux bash script that runs after an image is complete to do further customization of the image.

It sounds like Fog is the tool that will do what you’re trying to do, there’s just a bit more setup.

@plegrand said in upgrade Debian 11 to 12:

127.0.0.1:9000

This is the communication port that apache talks to php-fpm (PHP Execution Engine). For some reason during the update php-fpm was not updated or failed to restart correctly.

Well done getting this resolved on your end.

@Envy said in Help Required: Debugging PXE Boot Error on Mixed-Environment Network:

Problem: Some of our UEFI computers fail to obtain an IP address during PXE boot attempts, while others appear to continue but finally clock out with a “No configuration methods succeeded” error.

First since you have a mix environment I would start with setting up your dhcp server to send both bios and uefi boot files: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Second the no configuration methods succeeded and not getting an IP address sounds a lot like you have the default spanning tree configured. Where you should be running one of the fast spanning tree protocols like port-fast fast-stp, rstp, mstp, or what ever your switch mfg calls it. A quick test is to put one of those cheap 5 port unmanaged network switches between the pxe booting computer and the enterprise switch. If that fixes the problem then talk to your network admins to enable one of the fast stp protocols on all network ports where you have clients that need to pxe boot. Understand this is an infrastructure issue and not specifically a fog issue.

Also make sure you have the latest version of FOG installed or at least recompile ipxe to the latest version: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

But I think I would work on the first two issues I mentioned first. Your network troubles really sound like the second issue I mentioned.

@gothikserpent What are the issues you’re seeing in the Single Disk resizable method?

I ask because while, from a purely technical standpoint, a resizable image would indeed be able to be on a slightly smaller disk (assuming your linux partition is in an EXT format, not LFS) the capture itself doesn’t change, just the restructuring of the partitions.

@george1421 I can’t point you to the ISO, only to their website to purchase a copy (Parted Magic Store), but I’ve grabbed 3 different cfgs and attached them. From what I see it appears that the iPXE format used is fine. And maybe this is not an iPXE issue anyway.

kernel ${win_base_url}/pm/bzImage initrd ${win_base_url}/pm/initrd.img imgfetch ${win_base_url}/pm/fu.img imgfetch ${win_base_url}/pm/m.img imgfetch ${win_base_url}/pm/files.cgz imgargs bzImage initrd=initrd.img initrd=fu.img initrd=m.img initrd=files.cgz edd=on vga=normal boot

The above seems to line-up fine with what I see in other cfgs.

kernel ${win_base_url}/pmagic/bzImage initrd=initrd.img initrd=fu.img initrd=m.img edd=on vga=normal netsrc=wget neturl="${win_base_url}/pmagic/pmodules/" netargs="-U pmagicboot" initrd ${win_base_url}/pmagic/initrd.img initrd ${win_base_url}/pmagic/fu.img initrd ${win_base_url}/pmagic/m.img boot

The code above loads the init stuff, but does say “/proc/cmdline: line 1: bzImage: command not found” but it does start to download the SQFS. However, that download fails around 76% with another error. Downloaded it in a browser to make sure my webserver isn’t wonky, and it compares without issue to the original in the ISO. Also, the ISO boots fine…
grubcfg.txt
sample_pxelinuxcfg.txt
syslinuxcfg.txt

@george1421 thank you so much this is what I was searching for.

@jaapvdpol Well lets see if we can get a few things sorted out here.

Scale: I have not seen an install yet with 100 storage nodes. Each storage node will need to be managed at some point in time.

I kind of see this as a two phase project.

The initial push to move from windows to linux. Will you have boots on the ground at each location to do this? If yes they can bring a mobile deployment server with them (laptop kitted with what they need for imaging). If you are trying to do this all remote I can see it taking a while to complete. Post upgrade to linux. From time to time you may need to image failed computers. How will you handle that? Have a fog server at each site? Will you train local folks to be able to do this? Or is a drop ship a new system and they return the failed one for repair a bit of a better solution? Now I’ve used a raspberry pi for a fog server to image low volume systems. But that is before the prices of those critters when crazy. You think about it, with a site of 20 computers, you might, and I say ‘might’ reimage 1 computer a year. Is there value in having 100 storage nodes? I’m not saying one way or the other is right, just think about what you are trying to achieve and how much management work you are willing to do.

Now in regards to dnsmasq, that is a service we can install on the FOG server. With our configuration it will send out pxe boot information to the local subnet its connected to. You don’t need to touch anything on the router or network. So when the mobile fog server arrives, so does the pxe boot information. When the mobile fog server leaves, so does the concept of pxe booting. In this design (mobile deployment server) the target computers are not designed to pxe boot through the fog server, but instead a tech sitting in front of the computer presses F10 or F12 during booting to get to the efi boot manager where the tech picks pxe boot.

Understand I’m just trying to tell you what’s possible. Since I don’t know 100% of your use case I can only give suggestions based on how FOG works.

@boros There is no RHEL/CentOS since they are both dead to me now that IBM had its way…

BUT, someone with the proper motivation can probably make it work. I would start with my post here: https://forums.fogproject.org/post/103324 That will give you the basic layout. Now lets mix it with these instructions. https://docs.centos.org/en-US/8-docs/advanced-install/assembly_preparing-for-a-network-install/

The most useful section is from the syslinux boot menu.

label linux menu label ^Install system menu default kernel images/CentOS-8/vmlinuz append initrd=images/CentOS-8/initrd.img ip=dhcp inst.repo=http://10.32.5.1/CentOS-8/x86_64/iso-contents-root/

While FOG uses iPXE its possible to translate between the two formats. From the first link this is what I used to call centos 7 installer.

kernel tftp://${fog-ip}/os/centos/7/vmlinuz initrd tftp://${fog-ip}/os/centos/7/initrd.img imgargs vmlinuz initrd=initrd.img root=live:nfs://${fog-ip}:/images/os/centos/7/LiveOS/squashfs.img ip=dhcp inst.repo=nfs:${fog-ip}:/images/os/centos/7 splash quiet boot || goto MENU

So to update the syslinux format to iPXE

kernel tftp://${fog-ip}/os/centos/8/vmlinuz initrd tftp://${fog-ip}/os/centos/8/initrd.img imgargs vmlinuz initrd=initrd.img ip=dhcp inst.repo=http://${fog-ip}/centos8/ splash quiet boot || goto MENU

So you will need to copy vmlinuz and initrd.img from the iso to the fog server into /tftpboot/os/centos/8 directory. This places the boot files in scope of the tftp server. The next is to place the contents of the iso (extracted) into the scope of the web server in /var/www/html/centos8 directory. So the target computer will load linux and the initrd from the tftp server and then access the rest of the centos files from the contents uploaded to the web server.

@george1421
Thanks, that’s very helpful. I’ll do some debugging and see what I can find.

@sega You can try something like this:
https://superuser.com/questions/29450/how-to-do-a-powershell-or-other-script-to-change-screen-resolution

Sure it’s a help site, but it should be there to help out.

@PhilienTaylor I’m not sure what your question is here. Your end goal is not clear based on what you have posted.

FOG doesn’t support imaging over Torrent. FOG doesn’t support Secure boot. There is a tutorial on how you can create your own keys and then sign the boot files. This will require you to upload the certificates into each hardware. Or to go to microsoft and go through the process to get microsoft signed signing keys for what you want to boot on the target hardware. FOG doesn’t have any utlity for hypervisor environments. The FOG server can run as a vm client, but FOG has no relationship with virtualization.

@george1421

Absolutely, I already had http serving in-place so the additional 1GB size result was negligible impact. Thanks for the additional insight, however.

Happy to help out, I just noticed a majority of posts about this ended with users reporting Hiren over PXE was “solved” by simply updating their wimboot version, with no other notes. While it does fix booting it, it is only part of the solution. It’s necessary to do that but it is not a complete fix. You need the Y:\ mount fixed or else the booted ISO is still heavily broken. Hopefully this helps some people out. HBCD is a great Swiss Army knife.

PS: I changed BOOT EXIT TYPE and EFI BOOT EXIT TYPE and the rEFInd menu appeared and the Windows was booted.

Just curious to know if that fixed the situation or renaming the files which I mentioned before.