Nanobsd_vga using serial in boot loader?
-
Some more testing in VirtualBox seems to confirm my suspicion: In a VM with no serial port, the boot loader hangs before producing any output as described above. When I add a serial port to the VM, the boot menu is sent there (and only there), and the system boots shortly thereafter (everything starting from BTX is shown on the VGA console).
Unfortunately, like many modern (legacy-free) systems, the actual machine that I want to install pfSense onto does not have a serial port, and so never even gets to the boot loader prompt.
How do I go about filing a bug report for this?
-
I'll have to run some tests to confirm this myself, but I have made quite a few fixes to NanoBSD+VGA over the last couple weeks helping a customer get images going on their new hardware, and it works for them now on their hardware, and for me in a VM (though it's VMware Workstation 8.x).
When you get it booted up, what do the following files contain?
/boot.config
/boot/loader.conf
/etc/ttys -
Do your customer's machine and your VM have a serial port present by any chance? Like I said, it's only really a problem (other than not being able to interact with the boot loader) if there isn't one.
I'll try and check the contents of the files you mentioned later today.
-
No, my VM has no serial port, and the customer device did not have one either (which is why they wanted nanobsd+vga)
-
OK, so using the pfSense-2.1-BETA0-1g-amd64-nanobsd_vga-20120911-1249 image, this is what I get:
/boot.config – does not exist
/boot/loader.conf -- empty
/etc/ttys -- the only entry with status "on" is this: ttyv0 "/usr/libexec/getty Pc" cons25 on secure
However, since I'm not even getting to BTX (and the kernel never even gets loaded in the first place) without a serial port, does /etc/ttys even matter? -
Also, I'm just realizing my terminology was off; it's the boot block that hangs, not the boot loader. I.e., this is what I get on the serial port:
1 pfSense 2 pfSense F6 PXE Boot: 1 -
So, I played around with this some more, and I think the problem is that the image uses the wrong boot block (boot0sio instead of boot0). "gpart bootcode -b /boot/boot0 [device]" fixes the problem immediately.
-
Yeah that's where my mind was heading next (though with boot0cfg instead of gpart)
There's probably a case missing in the image code that isn't excluding the nano+vga images from getting it. -
just committed a potential fix to the build process. New images to test will be up in a couple hours.
-
Should these have been posted by now? The snapshot page doesn't seem to list anything…
-
Should be up shortly.
-
Sweet, problem solved. Thanks much for your help!
