Nanobsd for WRAP

[techq135]

Will the nanobsd image also work on a WRAP board? I've seen several topics on a "boot0" packet mode problem, but I just like to know
if this will be resolved if/when PCengines makes a new BIOS or if this will be resolved in the nanobsd image (if that is at all possible).

[jimp]

It isn't looking promising for a new BIOS on WRAP, and even when we can get nano to boot on a WRAP, it will only boot the first slice so upgrades will not work.

WRAPs may be stuck with the old style embedded and 1.2.2 for the time being.

If you are aware of the risks, and have a spare BSD box (or idle non-production pfSense box) you can plug the CF in, and change the image to nopacket like so:

boot0cfg -o nopacket /dev/da0
(Or whatever device the card shows up as)

[techq135]

Thanks for the info.

I tried the boot0cfg, this worked.

As a reference for others, you can also use a spare freebsd machine and "update" the image file with boot0cfg

mdconfig -a -t vnode -f <imagefile>(returns mdx, where x is number of md-device)
boot0cfg -o nopacket /dev/mdx
mdconfig -d -u x

After this, just put the image on the CF-card as usual.</imagefile>

[blastkiller]

Hello,

I tried "boot0cfg -o nopacket /dev/mdx" but it dont work. It returns only "bad magic". Im not a FreeBSD User so I dont know what to do next.

Thanks for help

[dotdash]

x refers to the number of the device, this will be 0 on a stock FreeBSD system.
After you issue the first command it should return md0, md1, or whatever.
Then substitute the number for x in the following commands.
EG:
boot0cfg -o nopacket /dev/md1
mdconfig -d -u 1

[blastkiller]

i know. but after boot0cfg -o nopacket /dev/md1 it replys with a bad magic. is this ok or a error ?

[jimp]

@blastkiller:

i know. but after boot0cfg -o nopacket /dev/md1 it replys with a bad magic. is this ok or a error ?

No, that's not normal.

You are better off writing the image to a CF and then altering after it has been written, if possible.

The mdconfig method has always worked for me. I tried it again, too:

# mdconfig -f pfSense-1.2.3-RC3-NanoBSD-512MB.full.img
md0
# boot0cfg -o nopacket /dev/md0
# mdconfig -d -u 0

[Slam]

Just thought I'd add this and save people tearing their hair out, as I did for a few weeks.

I tried booting my wrap board with the modified cf but I couldnt get an ip address from the lan port, this is because (correct me if I am wrong) but the nanobsd images have vr0/vr1 set as the interfaces, it should be sis0/sis1 on wraps.

After executing the above commands posted by other board members, you will also need to modify the config.xml file and edit the <if>tags to reflect the wrap ethernet ports, which are sis0 and sis1 respectively.

I achieved this and the nopacket command using a spare alix board and then my wrap booted up as expected and I recieved an ip from its lan port.</if>

[jimp]

Slam,

If you have a serial cable connected and are monitoring the serial console, it should have stopped to ask for interface assignment. You could just type in sis0/sis1 at that point instead of hand editing the configuration.

[Slam]

Jim, I did have a serial cable connected, I see the POST then the boot prompt with 1)pfsense 2)pfsense, it commences to boot up but with x0xxx0xxx0x characters scrolling the screen and thats the same characters I also see on my alix boards (.99h), just for reference, I used "pfSense-1.2.3-512mb-20091201-2042-nanobsd.img.gz" from the nanobsd dir on the snapshot server using a wrap 1E-2 (1.11).

Perhaps initially after I modified the cf I didnt wait long enough (I did wait about 5 mins) for the wrap to boot up, but as I said, all I have ever seen on the nanobsd images loading were the above characters, Ill retest tomorrow and report back.

[jimp]

Sounds like you might have your serial client setup with the wrong settings. It should be 9600/8/N/1

[Slam]

Jim you were right, I had the wrong settings in putty, I feel so stupid!

Thanks for pointing it out  ;D

[jimp]

You're welcome. Glad it was such an easy fix  8)