Hello,
Nice! that worked. I’d swear I had tried that before as I was scouring different dnsmasq guides most of the night trying to get it started automatically.
Thanks again.
That thing it did after running the command, I never saw that come up last night.
Ooops I got the formatting wrong. Here is a text output.
Sorry guys I am frazzled been up all night messing more with Linux.
dnsmasq is in rc.d and after booting
service --status-all
shows dnsmasq present in the list but it has a minus sign (not started). Starting dnsmasq manually - all good no errors.
My router runs DHCP and dnsmasq is (now) on the FOG server for UEFI and Legacy PXE boot. The awesome guide by @george1421 worked like a charm.
https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server
I found this in syslog
Apr 26 07:25:25 fogger systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Apr 26 07:25:25 fogger dnsmasq[2610]: started, version 2.84rc2 DNS disabled
Apr 26 07:25:25 fogger dnsmasq[2610]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Apr 26 07:25:25 fogger dnsmasq-dhcp[2610]: DHCP, proxy on subnet 192.168.1.100
Apr 26 07:25:25 fogger systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Apr 26 07:25:25 fogger systemd[1]: Reached target Host and Network Name Lookups.
Then further down in syslog dnsmasq entries related to the ltsp.conf settings. There are no errors or anything.
I can provide any logs or confs if needed to solve the problem. I am so close and was thinking I could just start the service using cron
@reboot sudo service dnsmasq start
That seems like cheating and there has to be a correct way to do it.
Thanks
It was just a hiccup. Running the installer again without git pull there weren’t any errors.
Thank you.
There was one error during the upgrade process but it completed.
Everything seems to be working so far. copied over the inits for dual NVMe and I was able to capture an image without any problems.
Thanks. I do have Internet access and have been updating FOG dev branch every time a new version is released. PHP 7.1 packages are not available on 21.04. I just think it is odd that it is looking for 7.1.
I just upgraded to Ubuntu 21.04 everything was great then I tried to update to 1.5.9.73 from 1.5.9.68 but got these error messages about php. Now I can not access the fog web management. It just displays the php code. I can’t pxe boot either.
Why is FOG looking for and trying to install PHP 7.1? Isn’t that really old?
When I ran $ php -version shows PHP 7.4.16 (cli)
When I try to upgrade FOG again it removes php and apache and tries to reinstall them but the same error occurs.
@will said in M.2 not recognised during deploying stage:
But when put these 2 modules together
What do you mean by put them together? Like in onboard RAID?
Is it possible like with NVMe drives, the M.2s are initializing at different times during the boot process and the drives switch places? Like changes from say /dev/nvme0n1 to /dev/nvme1n1?
Thanks. I updated and instead of checking I got lazy and posted. Where can I find info on what’s changed in each dev build? Github didn’t seem to have anything listed.
Quick question. Does 1.5.9.36 dev build have these NVME related intits?
So yes, this is a perfect solution since Primary host disk can now be set by size. I have one image for the OS disk, and one for the “D” drive. I just switch the Primary Host disk setting depending on which image I want to capture or deploy.
I copied over the updated init.xz to
/var/www/html/fog/service/ipxe/
Then set the host primary disk to 1000204886016 and attempted to capture
It worked great
Thank you very much
Thanks. I will test as soon as I can. Probably middle of the night or early tomorrow.
No worries I didn’t expect the fix to be available when I updated. I was just testing/wondering about .size files and why they were missing and or not being created automatically. I didn’t know they were only created in all disk mode and thought maybe something else was wrong. Thanks for clearing that up.
Wow. After creating the .size files I captured an image from each NVMe drive to their corresponding existing image. the .size files are now gone. Did I need to change the owner of the .size files to root?
Anyways so I updated FOG dev build to the latest as of today 1.5.9.29 captured an image from the NVMe. The .size files weren’t created. Maybe this is indicative of another problem?
@Sebastian-Roth
Thanks
Some of the images were initially captured on the 1.5.9 RC candidates 11 - 16 from the dev branch. One new image was captured on 1.5.9 final dev branch, (just a couple days ago), neither image directory had the .size files.
I have created d1.size and d2.size files inside the directories of the 2 NVMe based images using the values from the blockdev --getsize64 output
