How are the pfSense CF images written differently to the m0n0wall ones?
UnEsxi last edited by
Like many, I've been waiting to try the 2.0 RC for a while now, so finally got around to loading RC3 last week.
But I still can't get any of the embedded ISOs to boot my old Dell P4 PC from the CF card. It's been running m0n0wall for years and does suffer from 'limited' BIOS/CMOS settings (E.g. HDD recognition, and nice-to-haves like 'boot from USB'). So I was not surprised to hit trouble. However I've been troubleshooting for hours now and instead loaded m0n0wall to get back online :(
This PC has been running m0n0wall for 5+ years. Talk about great re-use (E.g. due to such eXcellent software). With the right settings (E.g. manual C/H/S HDD parameters). However when loading a CF with a pfSense image dd'd onto it, it completely refuses to boot. Placing the card in the CF slot and booting, the PC would get to the point of mounting the boot-loader (just past POST) and stop with a single unblinking horizontal cursor in the top left side of the screen.
After trying different CHS settings, I verified exactly what they should be. So then thought it may be the CF card, however my Mac was dd'ing the 512MB images without error.
After repeating and checking
- that the MD5 checksums of the images I was using were correct
- making sure the cf card was unmounted/ignored properly during the process
- trying to unpack the .gz files first, then use dd to write directly (on my Mac I was using the single gzcat command in the pfSense installation instructions)
- repeating using physdiskwrite.exe on a windows host, jic
Frustrated, I tried some pfSense 1.2.3 images also. Alas, they too can't load the boot loader.
Hunting for causes and came across numerous posts about Kingston cards being problematic (mine's a Kingston Elite Pro CF/512FE).
So I tried a couple of Sandisk ones, a 1GB and a 256M, using the 512 and 1G nanobsd images, just in case it were those or the CHS settings.
Ended up downloading the LiveCD ISO also and installing to a Hard drive from that. But the install failed towards the end, (was installing to a 4GB IBM Microdrive via the USB socket). Maybe I was expecting too much, as I found Manuel's doco on his efforts to add support for Microdrives and it seemed like a fair bit of Work: At that point gave up and went back to m0n0wall, even though my OEM microdrive looked to be working okay via USB and IDE reader.
All I've discovered is that any of the m0n0wall images, when burned the same way as the pfSense ones, work fine with any of the cards I was using (cries). What can be wrong/different?
Unfortunately I don't have a FreeBSD box (or the time) to compile my own CF image right now.
Could it be that the pfSense memory card images are formatted in a way my old BIOS does not support (?)
Do they require the host BIOS to explicitly support DMA (my Dell BIOS makes no mention of it)
Many Thanks in advance!
Here are the images I was using from the download mirror:
The nanoBSD images use the serial port for the main console.
If you're not connected via a null modem cable you won't see anything after the botloader.
UnEsxi last edited by
*** thank you ***
Oh snap! I was wondering what nanobsd meant.
So of course, I tried one now and it boots! Came up with Install or Repair, I tried install but failed, then just booted from the Live-image. All was great for 20 mins whilst I configured everything… then all the config was lost when it threw some errors writing to disk (md0) and the web UI stopped responding.
I tried rebooting a few times, but it failed again.
Maybe I need to avoid going to the repair option- perhaps it corrupted the config on the card.
Memstick is a bad name, should be pfSense-flashimage or something like that, slang terms like thumbdisk, usbkey, memorystick(TM), etc are a bit confusing.
PS. One thing that helped me: as my BIOS/CMOS has no options to control DMA, I changed to a non-UDMA cable... a DMA one will prevent the disk controller using that mode. So long as the DMA cable is used m0n0wall is cool. However perhaps pfSense needs it... will go look now.
EDIT: Looks like I've found what to do (search and much good will come)
I just found I must mount the CF card and add:
hw.ata.ata_dma = 0
to /boot/loader.conf.local, and must create the file if it doesn't exist.
(As my system has no way to do this in the BIOS and using an old cable does not achieve the same thing... )
dreamslacker last edited by
(As my system has no way to do this in the BIOS and using an old cable does not achieve the same thing… )
There's no such thing as a Non-UDMA cable. The difference between the 40 and 80 conductor cable is that the former supports up to UDMA-33 whereas the latter supports 66/100/133 modes.
Using the older cable still enables UDMA-33 mode; it does not downgrade the link to PIO mode.