Blue View Imaging

Troubleshooting

Client doesn't receive a boot file

Symptom: A PXE client gets an IP address (if using DHCP) but then times out or reports something like "PXE-E53: No boot filename received" instead of loading the boot menu.

Cause: This almost always traces to DHCP options 66 and 67. Option 66 (next-server) has to point at the imaging server's IP address, and option 67 (filename) has to name the correct boot file for the client. If Blue View Imaging is not running its own DHCP service — which is the default — your existing DHCP server needs both options set. On a Linux DHCP server these are next-server and filename; on a Windows DHCP server they're literally labeled options 066 and 067.

Fix: Confirm option 66 is the imaging server's IP, then confirm option 67 matches the client's firmware:

Handing a UEFI client the BIOS binary (or the reverse) is a common variant of this same problem — the client receives a boot file, TFTP serves it without error, but the firmware can't execute it and the boot still fails, which looks identical to a missing boot file from the DHCP side. If you're running Blue View Imaging's own DHCP service, it generates separate class blocks keyed off the client's vendor-class-identifier so each architecture gets the right file automatically; if you're using your own DHCP server, you're responsible for setting that logic up yourself (vendor-class matching, or separate scopes per client type).

Installer appears to hang during repository setup

Symptom: The installer prints * Adjusting repository (can take a long time for cleanup).......... and nothing else happens — no further output, no prompts, no error.

Cause: On Debian-family systems this step (installPackages in lib/common/functions.sh) adjusts the distribution's package repositories before installing anything, which on most Ubuntu/Debian installs includes adding the ondrej/php and ondrej/apache2 PPAs for a current PHP version. On Linux Mint releases older than 19, this step calls the same PPA-adding code path Ubuntu uses — but Mint's add-apt-repository isn't the standard tool; it's the mintsources GUI wrapper, and run headless it blocks waiting for a display that never comes. (Mint 19 and later are deliberately exempted from this step for the same reason — see Getting Started.) If genuinely nothing progresses past this line for several minutes on an affected Mint version, this is the cause.

Fix: On old Mint, upgrade to Mint 19+ or install on Ubuntu directly, then re-run the installer. If you're not on old Mint and the step is merely slow rather than stuck, that can be a legitimately large repository metadata refresh over a slow connection — check error_logs/fog_error_<version>.log in the installer's directory for activity before concluding it's frozen.

/images permission and NFS export problems

Symptom (capture-time): A capture completes on the client but fails to finalize on the server, or the storage node logs an FTP-style 550 Rename failed error when moving the image out of the capture directory.

Cause: Blue View Imaging captures land in <storage location>/dev before being moved into place. The NFS export for that directory is written with all_squash, mapping every remote write to the local imaging service account's UID/GID — this is what lets an anonymous client write into a directory it doesn't otherwise have credentials for. If that export instead has no_root_squash (for example, from a hand-edited /etc/exports, or an installer run with -E/--no-exportbuild against a stale export file), captures land owned by root, and the subsequent move — performed as the ordinary imaging service account — fails permission checks with exactly that 550 Rename failed error.

Fix: Replace the export options for <storage location>/dev with all_squash,anonuid=<uid>,anongid=<gid>, where <uid>/<gid> are the imaging service account's IDs (id -u <user> / id -g <user>). The simplest way to get a correct export is to let the installer regenerate it: re-run installfog.sh without -E/--no-exportbuild.

Symptom (SELinux hosts): On RHEL-family installs with SELinux enforcing, storage-node operations over HTTP, FTP, or SSH fail, but nothing about the failure shows up in Blue View Imaging's own logs.

Cause: The installer builds and loads a small SELinux policy module so the web tier can make the outbound connections storage-node replication needs. If checkpolicy or policycoreutils aren't installed, that module can't be built, the installer skips it with a warning, and SELinux silently denies those connections under enforcing — a policy denial doesn't produce an application-level error, so the application logs look clean.

Fix: Install checkpolicy and policycoreutils, then re-run the installer so it can build and load the module. Check journalctl or /var/log/audit/audit.log for AVC denials to confirm this is the cause before assuming otherwise.

Log locations

More from Blue View

Blue View OSThe AI you control.An agentic AI operating system. Use the model you want, keep the data you own, and prove what happened with a tamper-evident audit trail.PapertrailYour home file cabinet, intelligently organized.Imports, classifies, and indexes your documents so you find anything in seconds.VAMPProgram management for school districts.Create a program, take enrollments through custom forms, and move each one through an approval workflow.Read2MeYour reading list, read to you.Save a link or a document and have it summarized, archived, and queued into a listening playlist.