@itmod This piece of information still has not made it to the official docs (which are under work anyway). So here you go with a forum link: https://forums.fogproject.org/topic/16703/dual-boot-2-disks-unable-to-boot-grub

@dyacishyn Thanks for bringing this up and posting the log file. Very helpful indeed! Is this a fresh install or update from an earlier version of FOG? Pretty sure this is a fresh setup (logs show fresh MariaDB install) but just wanna make sure.

From what we see with Wayne’s installer tests Ubuntu 22.04 should work. As well I have done dozens of install/updates on 22.04 in preparation of the new release.

Looks like the Ubuntu install was not up to date to start with. Usually not an issue but I still think it’s worth to be aware of:

The following packages will be upgraded:
  apport apt apt-utils base-files cloud-init cryptsetup cryptsetup-bin
  cryptsetup-initramfs distro-info-data dmidecode fwupd fwupd-signed gzip
...

But then I am not sure why we see useradd: warning: the home directory /home/fogproject already exists. if this is a fresh setup?!

cp: cannot stat ‘/tftpboot/*’: No such file or directory

This error message is normal on a fresh install and can be ignored (see in the script code.

Fog installer fails at installing certificate

This is a bit missleading. I would think it’s actually failing when trying to compile the iPXE binaries with the self signed certificate as you seem to have selected for a HTTPS enabled setup. So please upload fog_ipxe-build_1.5.10.log - found in the same directory where you got the install log from.

@george1421 I am pretty sure the number is a typo because the distro name is for 16.04 which makes a little more sense than 10.04.

@Trev-lchs Officially we 1.5.10 does not support Ubuntu 16.04 as it reached the normal end of life cycle. And we don’t have a intaller test running for 16.04 either. But on the other hand I don’t see what change should make it impossible to use 1.5.10 on Ubuntu 16.04 in case you are using PHP 7.0 at the least. So I suggest you either setup a fresh test instance and see how it goes or even better you take a snapshot of your production server and just do an update to 1.5.10. Let us know how it goes.

By the way, even 14.04 is still hast so called extended security maintainance (ESM) just as 16.04 does according to wikipedia. This is definitely too much of official OS support we can stem. Not saying you cannot install FOG 1.5.10 on 14.04. I just haven’t tried.

Something I came to think about. How does Ubuntu handle things like PHP for such old versions. Are you still using PHP 7.0 on 16.04 while even 7.4 is not being updated anymore.

@Scootframer Maybe the server’s disk is failing? Have you checked the disk’s SMART bearings yet?

@Scootframer Do I get this right? The issue persists even after the server reboot?

@Scootframer Have you done a server reboot yet? From what I read this would fix the current issue you see.

@RogerBrownTDL said in Ubuntu Help - Boot Problem #N00b:

Filesystem                         Size  Used Avail Use% Mounted on
udev                               5.7G     0  5.7G   0% /dev
tmpfs                              1.2G  1.1M  1.2G   1% /run
/dev/mapper/ubuntu–vg-ubuntu–lv    490G   86G  384G  19% /

Nice, that looks great.

Marking as fixed.

@RogerBrownTDL Reboot and take a look at the disk space with df -h.

@RogerBrownTDL said in Ubuntu Help - Boot Problem #N00b:

If the system isnt running, surely I wouldnt be able to do anything, so it needs to be online?

Well, you can boot into a Live Linux ISO (Ubuntu or many others) to get to a command shell and do such things with the OS on disk not running. But I think you are fine doing it live after taking a snapshot backup.

@brakcounty said in ipxe boot slow after changing to HTTPS:

The delay is longer on my xencenter VMs vs VirtualBox VMs and physical PCs.

Let’s go back to this information. Are physical PCs as fast as it used to be with plain HTTP?

I do use VirtualBox in my test setups and never saw it going slow on HTTPS.

@RogerBrownTDL said in Ubuntu Help - Boot Problem #N00b:

Will it do that so that the full 500gb would be visible and the images stored remain intact?

Yes! Although I am not a 100% sure the filesystem resize (to full size) will work while the system is running. Should work but I can’t promise you it will. As well just for safety reasons I always suggest for people to take a backup copy before doing these kind of operations on a production server. Should be really easy taking a snapshot in Hyper-V before going ahead.

The other option I was talking about would be like adding a D:\ drive and moving all the images to that new partition. As I said it’s wise on the one hand so images can’t fill up your important C:\ drive (with the database on it) but on the other side you waste free space on C:…

@lukebarone I am wondering if it’s wise to create another volume instead of extending the existing one. This way the images could be put on the separate volume/partition and would not be able to fill the root partition. But that’s just me trying to prevent this from happening again.

The downside of my proposal is that the existing 100 GB root partition can’t be used by images and therefore are kind of wasted because the FOG server itself will never use 100 GB disk space with the images on a separate partition.

So maybe it’s actually wise to just extend as proposed and @RogerBrownTDL needs to keep an eye on the disk space from now on.

So if you wanna go this path, do:

lvextend --extents +100%FREE ubuntu-vg/ubuntu-lv --resizefs

@ikt_le When installing FOG you can tell it to setup DHCP for you. I suspect you said no when the installer asked you about that.

Is there a good reason to use FOG 1.5.4? This version is years old and many (!) bugs were fixed since then.

@RogerBrownTDL On the long run you need to look into purging some of the images and/or extending the disk space.

The other outputs you posted show that the root partition (LVM) really is only 100 GB in size while the whole VMDK container is 500 GB.

Extending the space is a bit more advanced but should be possible for you to achieve as well because things seem to be prepared already. After the reboot of the VM run the following commands and post output here:

pvs
vgs
lvs

@RogerBrownTDL Ok, there is really only one. Probably the one that failed to upload because it filled the disk. I suggest you remove that because with a full disk that is not going to be a valid image in any case.

rm -rf /images/dev/c8d9d2d4c8ac

Make sure you don’t mess with this command (e.g. use spaces in other places or *) because it can do a lot of harm if used the wrong way. Just wanted to get out this beforehand as you told us you are a Linux beginner.

Now run df -h to check the disk space available and reboot the whole VM.

@RogerBrownTDL Ok, your /images directory is on the root partition and just filled it up. Not too much trouble - let’s hope it didn’t break the database.

Run ls -al /images/dev and post output here. Pretty sure there will be old broken image captures that we can delete.

@RogerBrownTDL Please run the following commands and port output here:

df -h
du -h --max-depth=1 /
mount
lsblk

@DPR-SIO said in “could not complete tasking (/bin/fog.upload)”:

I Think I may have found the solution to my problem but I’m not sure

Would be interesting to hear what you found.

@kalafina Thanks for the update.

Nevertheless I opened an issue on github to look into making the fog-client a 64 bit application at some point.

After a certainly too long period since the last release we finally announce the new FOG 1.5.10:

https://news.fogproject.org/fog-1-5-10-officially-released/

Thank you very much to everyone devoting time to help getting this ready!!!

Find all the details in the new release notes…

This version was re-released (re-tagged) on 31st of March 2023 to patch issues with the location plugin that would cause trouble when updating from an earlier version.