0.684b is very close

Written by admin on .

I’ve found the problem with openssh-portable : It seem that openssh-portable haven’t the same default value as the FreeBSD sshd implementation. It needs the line “PasswordAuthentication yes” on the sshd_config file.

And I’ve added some messages about umouting drive that are used by swap file or iSCSI target and other little fix and prevent to format “used in a software raid drive” disk.
Now the code seem ready for 0.684b ;-)

User documentation is updated about the last features added: Only one choice for UFS (screen shot updates), and permit to use an USB key for storing configuration when using FreeNAS CDROM.

I’ve tried the just created FreeNAS-amd64 release CDROM, but my QEMU crash when I boot the CDROM… there should be a bug somewhere on the make.sh with the amd64 release :-(

Successful booting my software modified XBOX with the FreeBSD release (xbox-6stable-20060821.iso) .But I’ve just seen that the XBOX have only 64MB of RAM… And FreenNAS need a minium of 96MB :-(

For solving this 64MB problem I think that I should add a new install process for hard drive: It should no more use the method as flash device (using a RAM drive), but being installed directly on the hard drive (this will permit to simplify user modification of FreeNAS too). But this task is complex and will not be planned for the 0.684b. pfSense seem to use this method: I should check their code. This install method will permit to create a real SWAP partition too (permit to solve the ‘not enough RAM’ for fsck problem).

I’ve meet a problem since I’ve replace mini_httpd with lighttpd (there is a long time) : On the exec.php page the output of some commands (help option or error message) are no more display, but are send to the error.log of lighttpd… Perhaps this problem is solved on the pfSense project.

Add recovery tools and improve performance under VM

Written by admin on .

Yesterday I did a big mistake: I’ve upgrade my NAS server with a non-tested release of FreeNAS. And this release had a big bug that prevent me to start it again :-(

The process for recovery my system is quite simple:
1. Boot from a working FreeNAS CDROM
2. Mount the partition where is installed the bugged FreeNAS
3. Copy the config.xml from this partition to a tmp directory (in the RAM drive)
4. Unmount the partition
5. Re-install a working release of FreeNAS on this partition
6. Re-mount the partition where is now the working release
7. Copy the backuped config.xml from the RAM drive to this partition
8. reboot the computer

I choose to automated this process and add this tool as option on the install menu of FreeNAS (the install menu is now displayed only when booting from CDROM).

I found an interressant post on the forum that link to this cool blog:
This article explains how to increase the performance of FreeBSD under a VM machine by replacing the network drivers and changing one kernel parameter.
Changing a network driver is not users transparent (because they must re-configure their LAN interfaces)… But I should not forget to add this mention in the 0.684b release notes:
If your FreeNAS is using a “lnc” interface, plug a keyboard/screen on your PC before to start the upgrade because you will have to reconfigure your LAN interface for using the new “le” driver!

I’ve installed FreeBSD on my laptop too (removed ubuntu)… This will permit to play with my aironet card and WPA one day.

I’ve still not added the code for protecting to format a disk used in a RAID volume :-(
I think to hide them for the format option, but it’s more complex that I thought.