Install issue, boot failure on Live ISO: "Enter full pathname of shell"

thebozz

Hello GhostBSD community,

I am reaching out for some assistance as I'm hitting a wall trying to boot the GhostBSD Live ISO on bare metal and install it on a mini PC I have. I've had a great experience testing GhostBSD in a VM on a different machine, I really like the look and feel of Gershwin, and wanted to give it a go on bare metal.

The Issue:

Whether I use the current new release or the previous release, the boot process reaches the loading screen, detects an Ethernet connection (and appears to download some software), but then fails with the following error:

Enter full pathname of shell or RETURN for /rescue/sh

A prior message mentions being unable to perform an action on the file system right before dropping to this prompt.

Hardware Specs:

CPU: Intel N200
RAM: 8 GB (in another thread with a similar error, it was mentioned that there is an 8 GB RAM requirement for GhostBSD).
Storage: 120 GB SSD (currently has Linux Mint installed).
USB Media: Tested with both SanDisk and Kingston drives, ranging from 16 to 64 GB.

What I've Tried So Far:

Imaging Methods: I've written the ISO using the Fedora ISO Image Writer and also tried dd on macOS to rule out a bad flash.
Versions: Tried both the latest (all 3 ISOs) and a previous release with the same result.
BIOS Settings: When selecting the boot device, the USB shows up with "(UEFI)" next to it. I noticed in this thread - https://forums.ghostbsd.org/d/568-live-iso-full-pathname-why, that some users suggested Legacy BIOS mode, but I am unsure how to force that on this specific hardware.
Downloading the ISOs from a different location (I've used both Canada and France), verified the shasum matches with the shasum file on the download page. I've tried the following ISOs: GhostBSD 26.1-R15.0p2, GhostBSD 26.1-R15.0p2 - XFCE, GhostBSD 26.1-R15.0p2 - Gershwin Community Preview, GhostBSD-25.02-R14.3p2.

Questions:

Could the existing Linux Mint installation on the SSD be somehow interfering with the Live ISO's ability to mount the file system?
Is there a specific kernel boot flag or setting I should try at the loader menu to get past the mount failure?
Is the CPU underpowered for GhostBSD?

Any guidance or troubleshooting steps would be greatly appreciated.

Thank you!

vpx

The iGPU is probably using some of the 8 GB system RAM.
You could try reducing the reserved RAM for the iGPU in the BIOS if there is such an option.
Or you have to upgrade the memory.

You should also try booting FreeBSD 15.0, when it has the same error we could rule out insufficient memory.

This post says it it caused by booting into single user mode: Solved - Enter full pathname of shell or RETURN for /bin/sh:

But I don't see why the Live ISO would do that.

I just thought again and it's probably the RAM as the GhostBSD Live ISO is loading everything into it, and you are below 8 GB because it is shared with the iGPU. The installed Linux Mint can't be the issue then.

thebozz

I ended up swapping out the 8 GB stick and replaced it with a 16 GB one, sadly the same issue happened. Could the issue be that the mini PC is just underpowered for GhostBSD?

The specs are:

CPU: Intel N200 (4) @ 3.700 Ghz
GPU: Intel Alder Lake-N (UHD Graphics)
RAM: 16 GB (DDR4)

I tried the same set of USB sticks with the GhostBSD ISO written to them via dd, and I end up at the same place with the prompt for rescue.

Not sure what else to try here, I will give FreeBSD a go and see if it will boot and report back.

me12345

Hi,

Your hardware is certainly not under powered for GhostBSD. Keep in mind low-end modern hardware is generally much faster then mid-range hardware from 5+ years ago.

Can you provide a screenshot or video showing the details ?

I suspect your boot image is likely corrupt. Try redownloading the image and run checksum. What exact dd command did you use and from what OS ?

thebozz

me12345

So I have tried with both an Ethernet connection to the Internet and without...

Without an Internet connection I get to the GhostBSD - Welcome to GhostBSD menu where there is an option for Boot Multi User, Boot Single User, etc...

I do not press anything, then it starts to load the kernel, then the GhostBSD logo appears in the center of the screen. After a few seconds this is what appears:

==> Remount rootfs as read-write
==> Make mountpoints /cdrom
Waitihng for GhostBSD media to initialize
found /dev/iso9660/GHOSTBSD
==> Mount cdrom
Required memory 4GB for memdisk
Detected memory 16GB for memdisk
==> Mount swap-based memdisk
==> Replicate system image to swap-based media

It starts transferring data at this point, fails at around 100-120 MB then this appears:

cannot receive new filesystem stream: checksum mismatch 39 MB/s
Enter full pathname of shell or RETURN for /rescue/sh:

With an Internet connection I get to the GhostBSD - Welcome to GhostBSD menu where there is an option for Boot Multi User, Boot Single User, etc...

It fails at 1097 MB transferred and says the same as above:

cannot receive new filesystem stream: checksum mismatch 38 MB/s
Enter full pathname of shell or RETURN for /rescue/sh:

For the memory it is 4294967296 and 17179869184 to be exact.

I used the following commands to check the

echo "ff6c4df357df412d3b0c87e054204682b7c13e0cb90bcf61dcda58528a4f948e GhostBSD-26.1-R15.0p2.iso" | shasum -a 256 -c
shasum -a 256 GhostBSD-26.1-R15.0p2.iso

The first command returned: GhostBSD-26.1-R15.0p2.iso: OK
The second command returned: ff6c4df357df412d3b0c87e054204682b7c13e0cb90bcf61dcda58528a4f948e GhostBSD-26.1-R15.0p2.iso

The dd command I used (on a Mac) was sudo dd if=GhostBSD-26.1-R15.0p2.iso of=/dev/disk2 bs=1M, which I have done across different USB sticks to no avail.

vimanuelt

thebozz
Your ISO checksum verifies correctly, so most likely the ISO file is not the problem. The important clue is the “cannot receive new filesystem stream: checksum mismatch” error during the “Replicate system image to swap-based media” stage. At this point, GhostBSD copies the live system into memory. Usually, this type of checksum mismatch means data corruption during runtime, not a bad download. Also, the failure happens at different transfer points between boots, sometimes around 100–120 MB and other times around 1097 MB. This behavior often points to unstable RAM, USB controller problems, firmware settings, or corruption while reading from the USB device.

Since you already verified the SHA256 checksum and tested multiple USB sticks with and without an Internet connection, the ISO itself is probably fine. First, I would check BIOS settings for XMP, EXPO, or any RAM overclock profile. If enabled, disable it and run memory at default JEDEC speed. Even small RAM instability can produce checksum mismatch errors during boot or installation. Running MemTest86 is also a good idea because even one memory error can cause this exact problem.

I also recommend rewriting the USB installer using the raw disk device on macOS. Instead of “/dev/disk2”, use “/dev/rdisk2”. For example: “sudo dd if=GhostBSD-26.1-R15.0p2.iso of=/dev/rdisk2 bs=4m status=progress” and then run “sync”. On macOS, the raw device is usually faster and more reliable for writing bootable media.

Another thing to try is using a USB 2.0 port instead of USB 3.x. Preferably use a rear motherboard USB port and avoid front panel ports or USB hubs. Sometimes FreeBSD-based systems have compatibility problems with certain USB 3 controllers during early boot stages. It may also help to disable Secure Boot and Fast Boot in BIOS and test both UEFI mode and CSM/Legacy boot mode.

Finally, if possible, test another live system such as FreeBSD, NomadBSD, or Ubuntu. If those systems show similar boot instability, then most likely the issue is hardware or firmware related and not specific to GhostBSD. Based on your description, the most likely causes are unstable RAM settings or USB controller compatibility problems during the memdisk replication stage.

thebozz

vimanuelt

Will give this a shot, I was able to boot up Devuan and Ubuntu Live USB without an issue, but will try the bash commands you mentioned above. The mini PC does not appear to have a USB1 or USB2 port, they are all USB3 ports from what I can see, but will try the rear USB ports instead.

vimanuelt

If you are performing a bare metal install, assign it an entire hard drive instead of a partition.

Clivewi

To get the description to something simple, "Install Issue"

Answering questions from other posts.

ISO Image boots, with 20GB Ram, 6 CPU Cores, 60GB disk.

Messages as they appear just before it starts to go wrong: -

Replicate system image to swap-based memdisk.
cannot receive new file-system stream: checksum mismatch 08s 142 MB/s
Enter full path name of shell or RETURN for /rescue/sh:
Can't read termcap database;
using dumb terminal settings.
#

Lets dismiss its a hardware problem, I have windows 11 on another disk runs all right.
I have had Fedora 40, 41, 42, 43,and now 44 running the physical machine on a second disk with no crashing problems with the Virtual machine running on top of it.

I have run Debian 13, Ubuntu 26.05, Fedora 45, on the virtual machine and 45 is still being run.

I have no over clocking going on.

I have told the virtual machine manager I am booting freeBSD 15.

Questions, comments, or suggestions on how to get past this point?

Any suggestions what to check once you have a terminal prompt?

vpx

Clivewi Let me guess, you downloaded from the French server, right?

There was a really rare bit flip in this image that we discovered. Please download it again and check the SHA256 checksum.