Reset before setup has finished results in broken system.

[kpa]

2.2-ALPHA (i386) 
built on Thu May 22 22:15:16 CDT 2014 
FreeBSD 10.0-STABLE

This is on a Parallels for Mac virtual machine. I did a reset (equal to pressing the reset switch on real hardware) of the virtual machine to add a second network interface to the system before the initial interface setup had finished. This resulted in config.xml not being saved but the system thought that there was no need to run the interface setup again on next boot resulting in unusable system. I had to reinstall from scratch.

[jimp]

To be clear, did you install to the HDD before that part? As in pressing "i" during bootup from the CD rather than waiting for the CD to boot, ask for interfaces, and then install using menu option 99?

[kpa]

I did a normal installation on the HD and then booted to the installed system. However, I just remembered something that might have to do with the issue. FreeBSD 10 i386 on any kind of virtual machine might suffer from disk corruption on UFS filesystem unless a sysctl is used to turn off so called "unmapped I/O".

http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046154.html

The sysctl as you would put it in /boot/loader.conf.local (in pfSense, under standard FreeBSD just /boot/loader.conf) is:

vfs.unmapped_buf_allowed=0

I'll see if I can replicate the issue and see if the sysctl cures it.

[kpa]

No difference at all with the sysctl. I was able to reproduce the error two times out of two tries resetting the virtual machine after assigning a WAN interface but before assigning a LAN interface. The error message I'm seeing on the console is "Config.xml is corrupted and is 0 bytes.  Could not restore a previous backup."

[jimp]

What do you consider a "normal" HD installation?

For me, "normal" means you boot the CD all the way to the menu and use option 99 to install, but you'd already have to set the interfaces to get that far so it should be impossible to break it in that way since nothing would be permanent yet.

To others, "normal" might mean pressing "I" during the boot sequence to do the install early.

It's a matter of preference, but it can have an impact on the behavior.

[kpa]

Aah yes, sorry. I'm selecting 'I' during the boot up from the install CD. I'll see what difference using '99' on the live cd menu makes.

[jimp]

I tried it both ways and couldn't replicate the behavior. Each time I tried it always returned me to the assign interfaces prompt.

If you can get it to happen again, check /conf.default and see if there is a file inside.

Also mention specifically which install image is being used (amd64, i386, snapshot timestamp, filename, etc.)

[kpa]

The CD-image I'm using is

pfSense-LiveCD-2.2-DEVELOPMENT-i386-20140522-1233.iso

I was able to reproduce the problem again by doing the install via 'I' during the CD boot up and rebooting to the installed system and resetting the system mid-way of the interface setup. There is a config.xml file of size 17989 bytes under /conf.default

Using '99' on the livecd menu resulted in working system but of course there is no opportunity for messing up the configuration while doing the interface assignments because that configuration is not yet written to the real disk.

[jimp]

Where exactly in the interface setup did you reset?

[kpa]

After typing 'vtnet0' at the prompt for WAN interface and pressing enter.

[jimp]

Hmm, I can't reproduce it. I'm using VMware workstation on a PC, i386 VM, I installed using "i" and then rebooted. Let it come to the assignment screen, entered em0, then enter, and then reset the VM.

It came back up, ran fsck, and returned me to the interface assignment.

[kpa]

I'll see if I can reproduce this on another VM, let's say VirtualBox, or even on real hardware.

[jimp]

OK. It could be something specific to Parallels, I know others have abandoned it because of issues and moved to VBox or Fusion.

[kpa]

Well, it does the same thing under VirtualBox. I used 512MBs of RAM, 8GBs disk and two vtnet NICs. This has to be some sort of data loss problem that somehow isn't reproducable on your VM.

I wouldn't be using Parallels otherwise but it's so far the only one that offers proper Direct3D 9/10 graphics under Windows guest.