Current dev-branch version 1.5.5.3 now fails at “Setting up fog password”. It indicates that the account password includes characters that the installer cannot handle from the .fogsettings file, and then it will list a random set of numbers. Changing or removing completely the password field from .fogsettings does not appear to affect this at all. I am assuming a change was made to the installer that broke this. Is there a fix, or should I go back to the ‘working’ branch?

Ever since I updated to 1.5.x I have not been able to load the Parted Magic PXE files on any of my systems. Support at PM say there is nothing wrong on their end, and that it must be an issue on mine or my setup. I must be missing something here because for the life of me I cannot figure it out.

Here is my menu entry:
:fog.pmagic
cpair 0
cpuid --ext 29 && set arch 64 || set arch 32
kernel http://${fog-ip}/pmagic/bzImage${arch}
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m${arch}.img
imgargs bzImage${arch} boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot || read void

Everything loads just fine up until it gets to mounting the file system, and then just takes a big old fail. I verified that the file exists in that path, but cannot locate any other errors. This seems to affect all versions of Parted Magic including older ones off of the Hiren’s disk booted from FOG. Has anyone else encountered this? I’m not having issues loading any other live system… Just Parted Magic.

No updates of the system have been performed, and FOG is the only software in use on this system. I’ve had zero issues upgrading all along from 1.3 through various RC releases as they come out and onward to this final 1.4.0 release. This is the first time I’ve seen a failed message during an upgrade.

Specifically the error log shows:
“update-rc.d: error: cannot find a LSB script for FOGMulticastManager”

I was able to bypass the issue by grabbing the init.d scripts out of the packages folder, and manually placing them into /etc/init.d following with a chmod +x. Once those scripts were copied into init.d the foginstaller script moved along nicely.

Server

• FOG Version: 1.4.0 Release
• OS: Ubuntu 16.04

Description

Upgraded my installation using the installfog script as I always have, but encountered an issue near the end of installation. Database migration and all setup tasks all went through without a hitch… the problem comes when trying to bring up services.
“Configuring FOG System Services”
“Setting permissions on FOGMulticastManager.service script…OK”
“Enabling FOGMulticastManager.service Service…Failed!”

Manually attempting to start this service after installation brings up an error saying the service changed on disk, and to perform a daemon-reload. After doing this task the service starts up without issue. Subsequent runs of the installer script fail in the exact same way. What could be going on here? Could there be an issue with my install, or is this a bug with the new release? Never encountered this before.

@Tom-Elliott said:

@AndrewC I’m not seeing the problem, but I would imagine you are seeing this in particular with EFI style systems?

Yes. It was an issue with the particular test machine. Did not have a problem with any others BIOS or EFI. Worry not.

@Tom-Elliott said in Extra menus / Advanced menu no longer working in 1.3.5:

Please update to RC 8. I just pushed it up and it corrects this, which is why I moved this into the “bugs” and solved it.

You da man! RC-8 definitely fixed the custom menus. They now load perfectly fine in BIOS or EFI. Everything boots successfully from the menus with one exception… apparently Memtest is now broken. Running Memtest stops loading, and it hangs at “Loading boot sector… booting…”

Edit: Nevermind… the Memtest issue was related to a buggy test machine. It works on all others. Disregard

Here is an example of the test menu I threw together in Advanced just to see if I could get it to work:

menu Just a Test Menu
item DebianTest Run the Debian 8.7.1 (64-bit) net/installer
item ReturnTest Return to previous
choose target && goto ${target}
:DebianTest
kernel http://${fog-ip}/debian87x/linux
initrd http://${fog-ip}/debian87x/initrd.gz
imgargs linux vga=788
boot || goto MENU
:ReturnTest
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || prompt
goto MENU

Regardless of what is included in the menu or how much… it always fails with the usage statement for the “choose” command. I have tried every possible way to phrase that command, but get the same result. “choose target && goto ${target}” in the test menu was taken right from the iPXE.org website.

Server

• FOG Version: 1.3.5-RC-7
• OS: Ubuntu 16.04

Description

I posted previously about custom menus not working under UEFI, but working okay with BIOS booting. I have since come to realize that all custom menus are no longer working no matter what image I am booting (tested with a VM as well as 3 different physical systems). I understand that since I’m using the latest RC that there are bound to be bugs, but I have not seen anyone else report this problem as of yet.

As a test I enabled the built-in Advanced menu item, and made it accessible to all. I then wrote a very simple 2-line menu to see if it would work to no avail. I got the same result:

Usage:

  choose [-m|–menu <menu>] [-d|–default <default>] [-t|–timeout <timeout>] [-k|–keep] <setting>

See http://ipxe.org/cmd/choose for further information
Could not boot: Result too large (http://ipxe.org/46162085)
Could not boot: Result too large (http://ipxe.org/46162085)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds

It seems the “choose” command in the menus is somehow not the correct perimeters, but I was not able to get the menu to display no matter how I set it. This worked perfectly fine until about the 1.3.5 RCs. I’m not sure if this is an overall bug, or some kind of mis-configuration of my system. Any ideas?

These are the custom menus we are using. Again there are no problems with BIOS… just with calling these menus from UEFI does it fail. Perhaps you can spot something I missed. All I can think of is that perhaps the menu format is somehow different when booting from UEFI. I’m still learning the setup so pardon any mistakes

Thanks in advance for the help.

:MENU
menu Live Boot Systems
item --gap -- ---------------------------------------------
item fog.mint181c3 Run the Mint 18.1 Cinnamon (32-bit) disk/installer
item fog.mint181c6 Run the Mint 18.1 Cinnamon (64-bit) disk/installer
item fog.deb871net Run the Debian 8.7.1 (64-bit) net/installer
item --gap -- ---------------------------------------------
item fog.return Return to previous
choose --default fog.local --timeout 5000000 target && goto ${target}
:fog.mint181c3
kernel http://${fog-ip}/en_mint181_cin32/casper/vmlinuz
initrd http://${fog-ip}/en_mint181_cin32/casper/initrd.lz
imgargs vmlinuz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/var/www/html/en_mint181_cin32/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us mirror/country=US
boot || goto MENU
goto start
:fog.mint181c6
kernel http://${fog-ip}/en_mint181_cin64/casper/vmlinuz
initrd http://${fog-ip}/en_mint181_cin64/casper/initrd.lz
imgargs vmlinuz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/var/www/html/en_mint181_cin64/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us mirror/country=US
boot || goto MENU
goto start
:fog.deb871net
kernel http://${fog-ip}/debian87x/linux
initrd http://${fog-ip}/debian87x/initrd.gz
imgargs linux vga=788
boot || goto MENU
:fog.return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || prompt
goto MENU

----------------------------------

:MENU
menu Utilities Menu
item --gap -- ---------------------------------------------
item fog.memtest Run Memtest 86+
item fog.pmagic Run PartedMagic Software
item fog.pmagic32 Run PartedMagic Software (32-bit Older Systems)
item fog.clonezilla Run Clonezilla Imager
item fog.hirens152 Run the HIRENs 15.2 disk
item --gap -- ---------------------------------------------
item fog.win7 Run the Windows 7 Recovery Tool
item fog.win8 Run the Windows 8 Recovery Tool
item fog.win10 Run the Windows 10 Recovery Tool
item --gap -- ---------------------------------------------
item fog.return Return to previous
choose --default fog.local --timeout 5000000 target && goto ${target}
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web="redacted"/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch init_32.xz
boot || goto MENU
:fog.hirens152
initrd http://${fog-ip}/isos/util_Hiren.BootCD.15.2.iso
chain memdisk iso raw ||
boot || goto MENU
:fog.win7
kernel wimboot
initrd http://${fog-ip}/wims/w7_recovery/bcd BCD
initrd http://${fog-ip}/wims/w7_recovery/boot.sdi boot.sdi
initrd http://${fog-ip}/wims/w7_recovery/boot.wim boot.wim
boot || goto MENU
:fog.win8
kernel wimboot
initrd http://${fog-ip}/wims/w8_recovery/bcd BCD
initrd http://${fog-ip}/wims/w8_recovery/boot.sdi boot.sdi
initrd http://${fog-ip}/wims/w8_recovery/boot.wim boot.wim
boot || goto MENU
:fog.win10
kernel wimboot
initrd http://${fog-ip}/wims/w10_recovery/bcd BCD
initrd http://${fog-ip}/wims/w10_recovery/boot.sdi boot.sdi
initrd http://${fog-ip}/wims/w10_recovery/boot.wim boot.wim
boot || goto MENU
:fog.pmagic
kernel http://${fog-ip}/pmagic/bzImage64
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m64.img
imgargs bzImage64 boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot || read void
boot || goto MENU
:fog.pmagic32
kernel http://${fog-ip}/pmagic/bzImage
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m32.img
imgargs bzImage boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot || read void
boot || goto MENU
:fog.clonezilla
kernel http://${fog-ip}/clonezilla/vmlinuz
initrd http://${fog-ip}/clonezilla/initrd.img
imgargs vmlinuz boot=live username=user fetch=http://${fog-ip}/clonezilla/filesystem.squashfs union=overlay locale=en_US.UTF-8 keyboard-layouts=NONE
boot || echo failed to boot
prompt
goto MENU
:fog.return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || prompt
goto MENU

Server

• FOG Version: 1.3.5-RC-3
• OS: Ubuntu 16.04

Description

No problems at all with systems using BIOS. I have a few newer systems that use UEFI, and I have configured co-existence as per the wiki instructions (ipxe.efi). UEFI systems boot just fine into the main menu, and everything can be selected without issue except our custom menus. We have two custom menus set up (Utilities) and (Live Boot), and neither work when selected.
I have attempted to look up the problem here, wiki, and ipxe.org to no avail. Perhaps I have missed something small in setup.

Output when custom menus are selected under UEFI booting:
"
Usage:

choose [-ml–menu <menu>] [-dl–default <default>] [-tl–timeout <timeout>] [-kl–keep] <setting>

See http://ipxe.org/cmd/choose for further information
Could not boot: Result too large (http://ipxe.org/46162085)
Could not boot: Result too large (http://ipxe.org/46162085)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds
"