Hello,

I’ve ran into a problem. When upgrading from Debian 12 to Debian 13 I no longer can get to the webpage for fog. I get a 503 service unavailable. After seeing that I decided to re-run the installer to see if that would help but then I get the following dependency conflicts and was wondering if anyone has ran into this yet with Debian 13 Trixie.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
systemd-sysv : Conflicts: initscripts but 3.14-4 is to be installed
Conflicts: insserv but 1.26.0-1 is to be installed
Conflicts: startpar but 0.66-1 is to be installed
Conflicts: sysv-rc but 3.14-4 is to be installed
Conflicts: sysvinit-core but 3.14-4 is to be installed
sysvinit-core : Conflicts: systemd-sysv but 257.9-1~deb13u1 is to be installed
Recommends: orphan-sysvinit-scripts but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: The following information from --solver 3.0 may provide additional context:
Unable to satisfy dependencies. Reached two conflicting decisions:

1. sysvinit-core:amd64 is not selected for install because:
   1. systemd-sysv:amd64 is selected for install
   2. systemd-sysv:amd64 is available in versions 257.9-1~deb13u1, 257.8-1~deb13u2
      [selected systemd-sysv:amd64=257.9-1~deb13u1 for install]
   3. sysvinit-core:amd64 Conflicts systemd-sysv
      [selected systemd-sysv:amd64=257.9-1~deb13u1]
      For context, additional choices that could not be installed:
   • In systemd-sysv:amd64 is available in versions 257.9-1~deb13u1, 257.8-1~deb13u2:
     • systemd-sysv:amd64=257.8-1~deb13u2 is not selected for install
2. sysvinit-core:amd64 is selected for install because:
   1. sysv-rc-conf:amd64=0.99-10 is selected for install
   2. sysv-rc-conf:amd64 Depends sysvinit-core

@Tom-Elliott Thank you for replying back. This did work but it doesn’t seem to be a time issue, the time on the linux machine is correct. Would there be anything else I could check to possibly fix this?

Hello,

So I am having problems with a few machines when I try and download from github the fog script. I get a “Error certificate is not trusted”. I’ve had this issue a few times when you try to install debian netinstall.iso with no internet and then set a static IP address, but works fine when you run the installer with internet. The reason I’m bringing this up is because these computers are in a location were dhcp is not present and a static ip is required. Would anyone know what can fix this. This issue continues even into the install of fog itself. Thank you for any suggestions you have.

1. I’ve tried re-installing the ca-certificates
2. Force updated all the certificates as well.

@snipdor One more idea, check and make sure both drivers are formatted the same. For example if the primary image is formatted with MBR make sure the drive in the laptop is also MBR. Same applies if the primary image was make with GPT.

@snipdor A few things you can check. I know I’ve run into this issue but can’t remember off hand what causes it. These are a few things I make sure I change before uploading.

1. Make sure the storage size of the deployed computer is equal or greater. If its smaller you will have issue.

2. Disable Secure boot in the bios if you haven’t done so already.

3. Try changing storage controller setting from Raid to ACHI.

I know with Fog it doesn’t like Raid but in recent revision’s I’ve seen it image using raid but doesn’t hurt to change it.

@jisd Please post the full logs for fog and see if there is also a log for the Apache web service.

@cwufog Have you tried taking the golden image and instead of sysprepping it, remove it from the domain making sure you have a local admin user and upload the image that way. Assuming the golden image works with the VPN and AV. Then register the next machine in fog with a different computer name and then deploy the golden image to the new machine. Just thinking it might be sysprep is resetting something that maybe the browser uses.

@jisd Depending on your setup. You might be better off starting from scratch with a new install of ubuntu 22.04. But that all depends on your setup and if you need to keep your images.

@jisd Have you thought of trying to update to an LTS release or newer release in general. Ubuntu 20.10 no longer has support so the repositories its trying to access no longer exist. Updating to like 22.04 LTS would help resolve that part which hopefully should help with being able to install the package you failed on.