17.1 images will not boot

[hedberg]

I would like to test 17.1 at a fairly new J1900 based machine with 4 intel nics.

This is the machine type:
https://www.amazon.co.uk/Celeron-Firewall-Fanless-Desktop-Computer-x/dp/B01IG5O95W

Tried both VGA versions from a USB stick and both CD-ROM versions with no success. Same machine booted one of the 16.7 versions just fine and I just installed a FreeBSD 11 on it to verify it wasnt the FreeBSD 11 that was at fault.

The CD-ROM load some small files and then dies. The USB version doesnt even boot.

Any ideas? 

[screege]

I bought the msae machine and can assure is not the machine with problems, I tried to boot on 5 different machines with no success (amd, intel) it will simply restart the machine, I tried it all usb sticks changed, downloaded all images and isos, ran win32, rufus, roadkills etc and nothing the images will simply not boot, I can tell you that the machine is ok since I could install the other firewall with no problem, xpenology, ubuntu and windows

[adem0x]

I have exactly the same problem.

Tried various (known to be good) USB sticks. Used the latest Rufus.

To see if the problem was with the computer, I have tried a Linux Mint and FreeBSD ISOs both of which worked just fine.

Only OPNSense fails to boot to install.

[xillar]

I have a similar issue with the same hardware (Intel J1900 processor@2 GHz, 8 GB DDR3L RAM, 120 GB SSD).

I am using the 17.1 vga image on a 4gb USB drive.  I found that the usb drive image created by rufus will not load the boot loader. However, creating the image on a usb drive using dd will allow the boot loader to run.

However, after boot loader runs and booting starts, it hangs almost immediately.  On the display, 6 lines after "Booting..." there's a line that starts "masks" and the boot hangs at that point.

This appears to be an OPNSense issue as using the installation method with a stock FreeBSD image boots without a problem.

[guest11051]

I experienced all of the issues listed while updating my Mac Mini 2012 to 17.1.

• Issue: 64-bit VGA .img file will not boot when created with Rufus
• Resolution: Create USB Boot drive in linux using dd.  Or, Ubuntu has a GUI ImageWriter that accomplishes the same thing very easily.

• Issue: Bootup Process shows "Booting..." then details some EFI console resolution info before completely freezing up with no bootup.
• Resolution:  See Franco's advise below.  Jumping into the Loader Prompt will allow you to make a temporary change to vt(4) and console settings which should allow the device to boot as desired.  Be sure to use the GUI in System -> Settings -> Admin to enable vt(4) and EFI moving forward.

I really don't know why FreeBSD decided to change the old defaults to not boot anymore. I'm sure it was a fix for something, but breaking devices here is, er, suboptimal.

Try this:

Escape to loader prompt (3)
Type: set kern.vty="vt"
Type: set console="efi"
Type: boot


Cheers,
Franco

[screege]

Hi from your answer I could to get a little more of boot now it stays under:

Mounting from ufs:/dev/ufs/OPNsense_Install failed with error 19

vfs.root.mountfrom=ufs:/dev/ufs/OPNsense_Install
vfs.root.mountfrom=.options=ro, noatime

Manual root filesystem specification:

a bunch of help and then asks me to:

mountroot>

I have succesfully installed on the same machines I am testing pfsense and untangle, don´t know why it is so hard to opnsense to do anything.

Regards,

[screege]

I tried adding this from:

https://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_from_USB

set kern.cam.boot_delay="10000"
boot

while on the esc promp
no luck

I can´t beleive how difficult this is.

[Rooster18]

Working on installation of 17.1 on a Netgate 4860, it previously had version 16.1 installed and I decided to explore Openbsd.  After a long experiment, I decided to return to OPNsense.  Could not get 17.1 to show the splash screen, using serial image.  Finally decided to try 16.7, booted and installed perfectly!

[Rooster18]

Quite possible that FreeBSD 11 switching from sc(4) to the vt(4) console utility may be an issue with this problem.  Just a WAG. 

[CraigHead]

Have you tried my alternative method?

https://forum.opnsense.org/index.php?topic=4526.0

[franco]

It's rather difficult to say where all of this leads due to switching defaults, changing "static" options, to the point where different tools like makefs/mkimg or old school vndconfig + gpart produce wildly different results for different hardware.

It's hard to believe there is nothing wrong with the images per se and how fragmented the hardware acts on those images due to intricacies of the underlying OS and the way the images are assembled, partitioned and aligned.

If we go back to some other tool other than mkimg the Nano image growfs breaks, not using GPT breaks UEFI or requires a single boot environment leading to requiring to release more images for every single flavour.

At the moment, the image build only has a single maintainer on a voluntary basis.

If people with the knowledge can help fix this for almost everyone without adding more images or changing the tooling jeopardising currently working setups we are very happy about every tiny bit of progress.


Cheers,
Franco

[Mr.Goodcat]

It's rather difficult to say where all of this leads due to switching defaults, changing "static" options, to the point where different tools like makefs/mkimg or old school vndconfig + gpart produce wildly different results for different hardware.

It's hard to believe there is nothing wrong with the images per se and how fragmented the hardware acts on those images due to intricacies of the underlying OS and the way the images are assembled, partitioned and aligned.

If we go back to some other tool other than mkimg the Nano image growfs breaks, not using GPT breaks UEFI or requires a single boot environment leading to requiring to release more images for every single flavour.

At the moment, the image build only has a single maintainer on a voluntary basis.

If people with the knowledge can help fix this for almost everyone without adding more images or changing the tooling jeopardising currently working setups we are very happy about every tiny bit of progress.


Cheers,
Franco

Hi Franco,

a while back on 17.1RC1 I also reported having problems with installing OPNSense from several USB sticks, with BIOS and UEFI. Recently I had to setup my Box anew and tried decided to try a different method. Originally Windows tools such as Rufus were used to write the image to USB. This time however linux with a simple dd command was used to write the 17.1 image to the very same USB stick. This actually allowed the system to install from USB. Either the 17.1 image has some improvements compared to RC1 or rufus and co. simply don't handle the image properly.

Best,
Fabian