@sebastian-roth I successfully installed 1.5.9 in Ubuntu 18.04! It installed php7.2 on it. Thanks!.. It’s interesting to update installation wiki, because there is written 16.04 as high Ubuntu release that support FOG.

Posts made by ***Redbob
-
RE: Cannot install FOG 1.5.9 in Ubuntu 16.04 because cannot install php7.1 (Is Ondrej repository empty??)
-
RE: Cannot install FOG 1.5.9 in Ubuntu 16.04 because cannot install php7.1 (Is Ondrej repository empty??)
@sebastian-roth I’m not interested in keep Ubuntu 16.04 in these machines. I’ll try in 18.04, for example, but I tried installing a fresh in Ubuntu 22.04, and the error was exactly the same!! But I think this release is too new for this test, ok? I’ll be back with the results about upgrading my server to 18.04
-
Cannot install FOG 1.5.9 in Ubuntu 16.04 because cannot install php7.1 (Is Ondrej repository empty??)
Hi!
I tried update FOG from 1.5.7 to 1.5.9 in my servers. We have 7 fog servers spreading across our State, two running Fedora and others running Ubuntu 16.04. The last two servers (16.04) I couldn’t update because the installer cannot install php7.1 at all.
The error is this:dpkg-query: no packages found matching php7.1 dpkg-query: no packages found matching php7.1-bcmath dpkg-query: no packages found matching php7.1-cli dpkg-query: no packages found matching php7.1-curl dpkg-query: no packages found matching php7.1-fpm dpkg-query: no packages found matching php7.1-gd dpkg-query: no packages found matching php7.1-json dpkg-query: no packages found matching php7.1-ldap dpkg-query: no packages found matching php7.1-mbstring dpkg-query: no packages found matching php7.1-mysql dpkg-query: no packages found matching php-gettext php-gettext
It’s funny, because I connected to Ondrej repository properly. Look:
gpg: keyring `/tmp/tmph5l8tm4m/secring.gpg' created gpg: keyring `/tmp/tmph5l8tm4m/pubring.gpg' created gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com gpg: /tmp/tmph5l8tm4m/trustdb.gpg: trustdb created gpg: key E5267A6C: public key "Launchpad PPA for Ondřej Surý" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK gpg: keyring `/tmp/tmpcfmwjn32/secring.gpg' created gpg: keyring `/tmp/tmpcfmwjn32/pubring.gpg' created gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com gpg: /tmp/tmpcfmwjn32/trustdb.gpg: trustdb created gpg: key E5267A6C: public key "Launchpad PPA for Ondřej Surý" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
It doesn’t matter if the server is newer or just an update. I didn’t installed at all. It seems Ondrej has thrown off these packages, because I added Apt key successfully, as you can see in the attached fog_error_1.5.9 and foginstall logfiles here. You can check, the installer installed php7.0, instead. But the installation ended unsuccessfully.
Any ideas? May I wait for Ondrej to fix his repository?
-
RE: PXE Chainloading error after FOG images menu
@george1421, it’s funny again. I scheduled a Deploy Task for the device. So it entered in a loop:
- Boot UEFI ipv4;
- Error after the message “BzImage…” (I post an image with this error)
- Restart and Boot UEFI ipv4.
Suddenly, the computer began to deploy the image!!!
It’s sure I have connectivity issues, no?
-
RE: PXE Chainloading error after FOG images menu
@george1421 Yes. What I don’t understand is why it could boot on PXE, but goes to error other there? Before this, PXE error occurred at boot time, not after certain operation. It’s like PXE wants to re-register Client at the middle of the operation.
-
RE: PXE Chainloading error after FOG images menu
@Sebastian-Roth these are two images:
this image is from a computer I didn’t registered on Server, chosing Deploy Image from FOG PXE Menu
This other image is from the same computer, but here I registered on Server and attached a Deploy Basic Task. -
RE: PXE Chainloading error after FOG images menu
@george1421, PXE boot client is not in the same subnet. Boot Client is at VLAN 12 (172.24.12.0/23) and FOG server is at Default VLAN (172.24.0.0/22). As I told before, I could do a Deploy over Legacy Boot, but errors in UEFI boot remain.
-
RE: PXE Chainloading error after FOG images menu
@Sebastian-Roth here you are:
[root@srvfog-mt ~]# iptables -L -n -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination [root@srvfog-mt ~]# getenforce Permissive [root@srvfog-mt ~]# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a2:02:9d:1b:e5:0a brd ff:ff:ff:ff:ff:ff inet 172.24.3.71/22 brd 172.24.3.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever inet6 fe80::6d9c:8567:1786:2562/64 scope link noprefixroute valid_lft forever preferred_lft forever
-
RE: PXE Chainloading error after FOG images menu
@Sebastian-Roth, yes I change my server. I installed in another distro (Fedora 30) and set IP 172.24.3.71, because I’m tired to deal with Ubuntu is FOG Enemy.
-
RE: PXE Chainloading error after FOG images menu
@george1421 here are the answers:
- Yes, I raised another server. It’s not 172.24.3.144 anymore. It’s based on Fedora 30;
- Yes, here’s the output from “http://172.24.3.71/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00”:
#!ipxe set fog-ip 172.24.3.71 set fog-webroot fog set boot-url http://${fog-ip}/${fog-webroot} cpuid --ext 29 && set arch x86_64 || set arch i386 goto get_console :console_set colour --rgb 0x00567a 1 || colour --rgb 0x00567a 2 || colour --rgb 0x00567a 4 || cpair --foreground 7 --background 2 2 || goto MENU :alt_console cpair --background 0 1 || cpair --background 1 2 || goto MENU :get_console console --picture http://172.24.3.71/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console :MENU menu colour --rgb 0xff0000 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap Host is NOT registered! item --gap -- ------------------------------------- item fog.local Boot from hard disk item fog.memtest Run Memtest86+ item fog.reginput Perform Full Host Registration and Inventory item fog.reg Quick Registration and Inventory item fog.deployimage Deploy Image item fog.multijoin Join Multicast Session item fog.sysinfo Client System Information (Compatibility) choose --default fog.local --timeout 3000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU :fog.memtest kernel memdisk initrd=memtest.bin iso raw initrd memtest.bin boot || goto MENU :fog.reginput kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=manreg imgfetch init_32.xz boot || goto MENU :fog.reg kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=autoreg imgfetch init_32.xz boot || goto MENU :fog.deployimage login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme param sysuuid ${uuid} :fog.multijoin login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param sessionJoin 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme param sysuuid ${uuid} :fog.sysinfo kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=sysinfo imgfetch init_32.xz boot || goto MENU :bootme chain -ar http://172.24.3.71/fog/service/ipxe/boot.php##params || goto MENU autoboot
- Yes, I can manage all operations from WEB UI
- I could access LEGACY Boot interface and I’m doing a deploy right now . But UEFI messages remain. Strange, because the interface of FOG menu changes color to red on black (The colors I set on server are blue on white).
-
PXE Chainloading error after FOG images menu
Hi,
I already faced situations about PXE chainloading error(https://forums.fogproject.org/post/120560), I never noticed this error after Images menu.
- The computer gets a XPE boot normally, goes to 1st FOG menu; I chose
deploy image
; - It goes to auth screen, I logon
- Shows Images Menu, and I chose one of them to deploy.
Just after that, I face this error message:
http://172.24.3.71/fog/service/ipxe/boot.php... Connection reset (http://ipxe.org/0f0a6095) Could not boot: Connection reset (http://ipxe.org/0f0a6095) Could not boot: Connection reset (http://ipxe.org/0f0a6095) Chainloading failed, his 's' for the iPXE shell; reboot in 10 seconds
Any new ideas? Why this error, if it could accept PXE boot normally before?
- The computer gets a XPE boot normally, goes to 1st FOG menu; I chose
-
RE: Database connection unavailable
@george1421, great stuff! How couldn’t I see this before?
lol!!!
Well, I reinstalled it, and already applied what Elliot said. Let’s see if it will take things easy. Thanks!! -
Database connection unavailable
Hi, everyone!
I know that whenever FOG Web Interface shows this message when I try to access it:
it’s to time to reinstall it.The problem is: this situation occurs every 2 months the average.
Is there another way to solve this unless reinstalling it? -
RE: IPXE Chainloading error in certain type of computer
@Sebastian-Roth it’s funny but… I decided change the client IP (added
172.24.12.49
into DHCP Exclusion Zone now client received172.24.12.65
), so it worked!Maybe some lockout from FW or Core rules… but it’s working, as I figured out on other computer with some specification. Could you check PCAP of
172.24.12.65
? It’s here: new PCAP, just to understand it, because I know, FW and Core rules are not the target of this forum -
RE: IPXE Chainloading error in certain type of computer
@Sebastian-Roth these are the answers, as followed:
- No, MAC address from client is 10:05:01:9c:7b:24 (that’s from 2nd image); MAC adress from FOG Server is 34:64:19:00:26:86;
- That’s Core Switch (My network is splitted in subnets - FOG is in default subnet - mask 255.255.252.0, the client is in another subnet - mask 255.255.254.0);
- As I know, there’s no firewall rules restricting LAN-level access, just WAN-level. See IPTABLES from FOG server:
userutil@moringa:~$ sudo iptables -L [sudo] password for userutil: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- anywhere anywhere multiport dports mdns ACCEPT tcp -- anywhere anywhere multiport dports 4000 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
- Yes, I could access WEB UI from the client normally.
-
RE: IPXE Chainloading error in certain type of computer
@Sebastian-Roth , I did a capture directly from FOG server (172.24.3.144) by Wireshark, the troubled client is 172.24.12.49. Here you have it: https://drive.google.com/open?id=1oolDaPqrF4gFIzN8gRfIXrnyKC18ahHj
-
IPXE Chainloading error in certain type of computer
Hi,
I still have the ipxe.efi chainloading tantalizing me… I already posted another issue about it (11240) and it worked when I followed instructions to “connect” to a unmanaged switch over building switch “as a workaround”…
…we have here several types of computer with UEFI boot. Some of them is working properly. That’s its behavior:
on the other side, I have some computers will no work, they gave me this kind of error:
Any ideas? As I see, it’s not properly IPXE issue, because some UEFI are booting from IPXE… Is the second type of BIOS “lazy” to process IPXE Boot request??
-
RE: Fog crash. Database connection unavailable?
I have this problem in FOG every 3 months aproximately. All I just do is to reinstall it and everything turns well, wihout any lose of data or settings.
-
RE: Deploying FOG in a raw SSD disk
@Sebastian-Roth, it’s funny. Fog deployed successfully all partitions, simply pressing ENTER after each breakpoint.
-
RE: Deploying FOG in a raw SSD disk
@Sebastian-Roth That’s what I did.
Follows Settings you suggested:
After usual messages, these are what I get. Here are the images: