Installation

A couple of months ago I installed m0n0wall on three new Soekris net4801s.

It sounds bizarre, but I succeeded or failed based on whether the net48xx image was copied onto my CF cards from an Intel vs a PowerPC Mac. The PPC-copied images boot m0n0wall, and the Intel-copied images don't. Same CF cardreader, same cards, same gzcat/dd syntax, same OS revision on all three tested machines.

The output from dd was identical in all cases (transfer time aside):

   $ umount -f /Volumes/Untitled
   $ gzcat net48xx-1.231.img.gz  | sudo dd of=/dev/disk1 bs=16k
   [password]
   gzcat: net48xx-1.231.img.gz: decompression OK, trailing garbage ignored
   448+0 records in
   448+0 records out
   7340032 bytes transferred in 15.003732 secs (489214 bytes/sec)

Exactly the same transferred byte count; the images on all three machines share the same MD5 hash.

When I boot a net4801 from a CF card copied on either a Macbook Pro or a Mac Pro, the LAN port never offers a DHCP lease. When I use the PPC Powerbook to copy the image, DHCP starts right up.

I brought all three 4801s into the office to plug them into a PC with a serial port, and my two intel-copied CF cards hang at "1 seconds to automatic boot", for as long as I let them.

Is there any reason why I should have expected this behavior? I'm not aware of any endianness issues with dd (the manpage says nothing), and I haven't found any discussion of a similar problem. The only way I stumbled across this solution was because I used this same PPC laptop to set up a 4801 I bought for myself a couple of years ago.

Because the cardreader doesn't require drivers on any of my three machines, my only guess at this point is that the problem might be an Intel-specific USB mass storage glitch in OS X. I'm not sure how to verify that, though; I can't seem to mount the UFS filesystem on any machines at my disposal.

I'm about to install 1.233 and wondered if anyone had any ideas to try. My remaining PowerPC machines won't last forever. Thanks.

I wonder what kind of CF reader you are using?  And CF?  My guess is a poor reader?

I've flashed using my MBP (2.2GHz Santa Rosa) using a Lexar Firewire reader using both SanDisk and PQI CF with no issues.

I am wondering why you umount and use "sudo dd" ?  You don't need to use sudo... and I'm wondering if it might be better to use Finder or Disk Utility to eject any existing?  I honestly don't know if there is any difference.. in theory it should be the same, but sometimes you never know if there is an interaction?

Aaron

[you can have this much more easy]

I had a similar problem here, writing an image for the net4501 on a CF card. My configuration: Intel iMac Dual Core, OS X 10.5, hama Cardreader on USB 2.0, Silicon System CF Card 1 GB (too much for m0nowall, I know ;-)

Thanks to your report, I tried to write it on other operating systems. Unfortunately I did not have any other physical box available, so I tried with virtualized PCs. All of them in VMware Fusion 1.1.1. My first try Windows  XP and physdiskwrite.exe failed. But I succeeded with a virtualized Ubuntu Server 6.01:

To prepare the following steps, insert the CF in the reader and connect it using the status bar of VMware Fusion.

First gunzip the file ($ gunzip -d net45xx ....)
Second type this command and make sure that you use the right disk (sdb may be different on your system!!):
dd if=net45xx-1.233.img  of =/dev/sdb bs=16k

Hope this helps, Ingo.

P.S. Seems as if you can have this much more easy - after rechecking my previous steps, I realized that if you use the right arguments and parameters you can do it also with dd from OS X (so without VMware fusion). The key is this line:

$ dd if=net45xx-1.233.img of=/dev/disk2 bs=16k

And that yo have to check, if the imagefile is still compressed or not (OS X may decompress it on the fly during download). This can be checked using the command "file". Following the output of an already decompressed imagefile.

$ file net45xx-1.233.img
net45xx-1.233.img: Unix Fast File system (little-endian), last mounted on /m0n0wall/mnt, last written at Wed Jan 23 23:28:47 2008, clean flag 1, number of blocks 7168, number of data blocks 6911, number of cylinder groups 1, block size 8192, fragment size 1024, minimum percentage of free blocks 0, rotational delay 0ms, disk rotational speed 60rps, SPACE optimization

Se also: http://lanti.wordpress.com/2008/05/23/installation-m0n0wall-auf-soekris-mittels-imac-os-x-105/ (German)

It works with intel mac, but be sure to use /dev/rdsink[n] instead of /dev/disk[n]