Wednesday, February 18, 2009

EON 64-bit 0.58.9 based on SNV_104 is released!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! As always lots of thanks to Al and Genunix.org for download hosting.

It is available in a CIFS and Samba flavor
tryitEON 64-bit x86 CIFS ISO image version 0.58.9 based on snv_104
tryitEON 64-bit x86 Samba ISO image version 0.58.9 based on snv_104

32 comments:

Jon said...

Hi, Andre!

I had some questions about EON, if you've got the time:

Is EON similar to NexentaStor or Sun's Amber Road? i.e., it's a free, simpler version of them?

Would EON be a good choice for a purpose-built home NAS/Fileserver using new hardware? Or is this better suited to using older hardware that you've already got?

Thanks!

Andre said...

Hi Jon,

EON is similar to nexentastor and suns amber road with a lot less features and geared more for personal NAS(no web interface yet but one can use wemin). It provides the core storage interfaces and protocols (iscsi, smb, nfs)

EON uses the OEM opensolaris kernel (snv_104 for this release) vs debian style (nexenta). Amber road internals are very similar (solaris) with the addition of AKD (appliance kit daemon) and analytics (very powerful for stats).

EON is definitely a good choice for a home NAS because it's always one hard drive greener than a HD install. The show won't stop because of a boot drive failure. And upgrade/maintenance presents minimal risk.

It runs on older, newer and mini-itx hardware. Runs great on 64-bit hardware. It has built-in performance of the rock solid ZFS. It is a bit memory hungry if you want the performance. Sorry for the rant there :)

Jon said...

No apologies necessary, that's exactly the kind of info I was looking for!

I'll definitely be giving this a shot in the next few days. Are you developing this on your own? Is there anything I can do to help support the project? Unfortunately I can't code, so I'm no help there.

Andre said...

Currently i'm the only person working on it. It was a pet development for a solution at home.

Currently, people are asking for the follwoing additions
- a DLNA server.(upnp, mediatomb, etc)
- a Freenas like web interface

For now your feedback is appreciated.

Ramoonus said...

a DLNA server makes it the ideal home NAS

Mark50+ said...

I have started on a port of the FreeNAS web gui to Solaris. A real challenge, but I'm making slow progress so far.
Not too many packages to add, and a few apps to write, and almost all the backend will need to change.

Anyone else doing this ?

Andre said...

Mark,

I have a decent amount done. No authentication. I think its from the 0.686/0.7 trunk as ZFS is still beta on freenas. I'm also not sure if permission is needed first from the freenas guys.

We can arrange a transfer if you want to look at what I converted so far.

I stalled working on it, as the focus shifted to building mediatomb.

Mark50+ said...

I'd be interested in anything you did, and will give you an update when I've a working package.

I've made some progress, but the change from PHP4 to PHP5 is causing some grief.
I'm heading down the rewrite path for much of it, as zfs removes the need for part, and I'll save the config in SMF.

DM said...

Is it possible to download snv_104? build 108 seems to be the only version available for download. (we need to add the si3124 driver).

Andre said...

DM,

here's a cpio archive of the 32/64 sil3124 drivers (redundant links)

http://www.badongo.com/file/13640171

http://rapidshare.com/files/204296639/sil3124.cpio.html

Andre said...

Mark,

Here's the freenas web interface conversion (aka freon), I have so far.

http://www.badongo.com/file/13649073

It also includes mod_php5.2.so to replace the one in /usr/apache2/2.2/libexec/mod_php5.2.so because the stock solaris version does not yet include "gettext" calls which freenas code uses.

Just unpack the files /var/apache2/2.2/htdocs.

Brandi said...

Hi Andre,

i have a question regarding the CIFS bug. How did you manage to fix this problem with the "kernel bind error".

I'm also creating a ramdisk based distribution (PulsarOS) and it would be fine to fix this nasty bug.

Thanks in advance

Cheers Thomas

DM said...

Thanks for the si3124 driver package Andre.

My goal this year is to build an embedded solaris based image that will drop onto a soho NAS appliance such as the Thecus series or similar - perhaps some driver porting might be needed, but I will cross this bridge later (hopefully not...). In the mean time, several Dell SC430 and SC440s are it, with an additional si3112 pci-e controller to give me 6 sata disks in each.

Your release of EON, and the tremendous effort you have put into EON thus far gave me the idea of using EON as the base image for my project. Ultimately I would like a drop in replacement to say windows storage server or similar in an sme type environment. Given everyeon here is all using solaris, I probably don't need to going into the pros or cons of solaris over linux, etc here.

The original release included image build scripts, several SMF templates, etc, but the latest EON release does not appear to have these. I have quite a lot of other packages I need to merge, and building a new image is probably easiest. I have a few errors using the original set of build scripts against b108.

Just thought I would ask for an updated copy of your build environment before I start re-inventing the wheel.

Please keep up the fantastic work!

Thanks - Darren

Andre Lue said...

Brandi,

I haven't seen the error you mentioned. Build snv_104 was used for this release. Is the bug supposed to be present in this release?

DM,

I haven't tested the build against snv_108 as yet. As soon as I have some time I'll cleanup the 104 build and share it.

Brandi said...

Hm very strange. I'm also using the snv_104 build. If I try to run /usr/lib/smbsrv/smbd I get the "Kernel bind error".

Do you have a package list? Maybe I missed something.

Brandi said...

Me again. I also tried it with you "imgsol.sh" builder script and with snv_104 and it didn't work. Maybe you changed something in your newest build?

Cheers

Thomas

joseph.schafer said...

Hello Andre,
Great work!
I'd like to use EON as a lightweight NAS in a VM. What's the easiest way to install it to a 4GB virtual drive in a vm?
thanks,
joseph

Andre Lue said...

Joseph,

4GB is a lot for EON. 1Gb should be more than enough. After booting http://eonstorage.blogspot.com/2008/11/eon-storage-embeddable-onopensolaris.html

There seems to be a bug with install/fdisk I'm still investigating. The way around this is to format the vm disk using format interactive. then install.sh

joseph.schafer said...

Hello Andre,
Thank you. I redid it with a 1GB drive and followed the NOV 2008 steps.
The Nov list has the /usr/bin/setup step, but the Dec list does not, so appreciate confirmation on the neccessity and order of the steps.

Here's what I did:
1. Create a vm - solaris with 1gb virtual drive
Name:eon-vm
Location:[standard]
Guest Operating System:Sun Solaris 10 (64-bit)
Memory:540 MB
Processors:1
Hard Disk:1 GB
Network Adapter:Using "Bridged"
CD/DVD Drive:Using "[standard] ISOs/eon-0.589-b104-...
USB Controller:Yes

2. Boot vm with the eon-xx.iso
3. Log in as "root/eonsolaris" and do ifconfig -a to get ip
192.168.80.211

4. Use putty to login {putty is easier to cut & paste vs vm console}

login as: admin
Using keyboard-interactive authentication.
Password: eonstore
Last login: Wed Mar 4 17:32:15 2009 from 192.168.80.231
Sun Microsystems Inc. SunOS 5.11 snv_104 November 2008

5. eon:1:~>su
Password: eonsolaris

6. format - the vm disk and "label" to write it out
7. /usr/bin/setup
8. /usr/bin/install.sh

Then reboot – but it comes up in grub??
Thoughts welcome,
joseph

joseph.schafer said...

Andre,
Here's some additional detail. I recreated the VM and went through the steps and ended up with a bootable image on the vm, but I don't seem to be able to configure it.
thanks,
joseph

OK, redo the vm
eon:1:~>su
Password:
eon:1:~#format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 [VMware,-VMwareVirtualS-1.0 cyl 510 alt 2 hd 128 sec 32]
/pci@0,0/pci15ad,1976@10/sd@0,0
Specify disk (enter its number): 0
selecting c1t0d0
[disk formatted]
No Solaris fdisk partition found.
format> fdisk
No fdisk table exists. The default partition for the disk is:
a 100% "SOLARIS System" partition
Type "y" to accept the default partition, otherwise type "n" to edit the
partition table.
y
format> p
partition> 0
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 0 (0/0/0) 0

Enter partition id tag[unassigned]:
Enter partition permission flags[wm]:
Enter new starting cyl[0]: 3
Enter partition size[0b, 0c, 3e, 0.00mb, 0.00gb]: 1000mb
partition> p
Current partition table (unnamed):
Total disk cylinders available: 1020 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 unassigned wm 3 - 1002 1000.00MB (1000/0/0) 2048000

format> quit

eon:2:~#/usr/bin/setup
This process will step thru the necessary configuration information.

Hostname: veon
Hostname: veon correct [y,n?] y
Configure network interface [e1000g0] via DHCP
(Dynamic Host Configuration Protocol) [y,n?] y
Hostname: veon
DHCP: YES
Is this correct [y,n?] y
Initializing interfaces
eon:3:~#/usr/bin/install.sh
This script installs EON live to a destination listed below:
1. c1t0d0 (1020MB)
Enter destination choice: 1

!!! WARNING !!! All data on device [c1t0d0] will be LOST !!!

Proceed with formatting, install [y,n?] y
searching /etc/mnttab ...
searching /mnt/eon0 ...
found: /mnt/eon0/boot/grub/stage1
found: /mnt/eon0/boot/grub/stage2
c1t0d0 :: /dev/rdsk/c1t0d0s0 :: /dev/dsk/c1t0d0s0
Physical Geometry:
cylinders[1024] heads[64] sectors[32]
sector size[512] blocks[2097152] mbytes[1024]
Virtual (HBA) Geometry:
cylinders[130] heads[255] sectors[63]
sector size[512] blocks[2088450] mbytes[1019]
About to write fdisk table:
SYSID ACT BHEAD BSECT BEGCYL EHEAD ESECT ENDCYL RELSECT NUMSECT
191 128 32 33 0 138 8 130 2048 2095104
100 0 0 0 0 0 0 0 100 100
100 0 0 0 0 0 0 0 100 100
100 0 0 0 0 0 0 0 100 100
Clearing VTOC labels from NEW table
Clearing primary VTOC at byte 1049088 (block 2049)
Clearing backup VTOC at byte 1073725952 (block 2097121)
Clearing backup VTOC at byte 1073726976 (block 2097123)
Clearing backup VTOC at byte 1073728000 (block 2097125)
Clearing backup VTOC at byte 1073729024 (block 2097127)
Clearing backup VTOC at byte 1073730048 (block 2097129)
cut_root_slice /dev/rdsk/c1t0d0p0 failed
newfs: construct a new file system /dev/rdsk/c1t0d0s0: (y/n)? y
pfexec mkfs -F ufs /dev/rdsk/c1t0d0s0 2088960 32 64 8192 1024 16 6 120 2048 t 0 -1 8 128 n
/dev/rdsk/c1t0d0s0: 2088960 sectors in 1020 cylinders of 64 tracks, 32 sectors
1020.0MB in 64 cyl groups (16 c/g, 16.00MB/g, 7680 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 32832, 65632, 98432, 131232, 164032, 196832, 229632, 262432, 295232,
1771232, 1804032, 1836832, 1869632, 1902432, 1935232, 1968032, 2000832,
2033632, 2066432
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)?y
stage1 written to partition 0 sector 0 (abs 2048)
stage2 written to partition 0, 267 sectors starting at 50 (abs 2098)
stage1 written to master boot sector
168400 blocks
EON install complete on /dev/dsk/c1t0d0s0
eon:4:~#
eon:4:~#/usr/bin/updimg.sh
usage: updimg.sh /path/image_name
updimg.sh /mnt/eon0/boot/x86.eon
eon:5:~#/usr/sbin/init 0
Initializing shutdown ...
eon:6:~#

==rebooted without the iso / cd – but the setup configuration did not take to try setup again.
=====
login as: admin
Using keyboard-interactive authentication.
Password:
Last login: Wed Mar 4 21:09:55 2009 from 192.168.80.231
Sun Microsystems Inc. SunOS 5.11 snv_104 November 2008
eon:1:~>su
Password:
eon:1:~#/usr/bin/setup
This process will step thru the necessary configuration information.
Hostname: veon
Hostname: veon correct [y,n?] y
Configure network interface [e1000g0] via DHCP
(Dynamic Host Configuration Protocol) [y,n?] y
Hostname: veon
DHCP: YES
Is this correct [y,n?] y
Initializing interfaces
eon:2:~#/usr/bin/updimg.sh
usage: updimg.sh /path/image_name
updimg.sh /mnt/eon0/boot/x86.eon
eon:3:~#df -h
Filesystem size used avail capacity Mounted on
/devices/ramdisk:a 272M 204M 41M 84% /
/devices 0K 0K 0K 0% /devices
/dev 0K 0K 0K 0% /dev
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 347M 348K 347M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1
272M 204M 41M 84% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
/dev/dsk/c1t0d0s0 959M 82M 819M 10% /mnt/eon0
swap 347M 0K 347M 0% /tmp
swap 347M 32K 347M 1% /var/run
eon:4:~#
eon:4:~#
eon:4:~#ls -lash /mnt/eon0/boot/
total 154122
2 dr-xr-xr-x 5 root root 512 Dec 31 1969 .
2 drwxr-xr-x 4 root root 512 Dec 31 1969 ..
2 dr-xr-xr-x 2 root root 512 Jan 11 17:02 amd64
2 dr-xr-xr-x 3 root root 1.0K Dec 31 1969 grub
2 dr-xr-xr-x 4 root root 512 Dec 31 1969 platform
154112 -r--r--r-- 1 root root 75M Feb 16 08:15 x86.eon
eon:5:~#/usr/bin/updimg.sh /mnt/eon0/boot/x86.eon
backing-up x86.eon to /mnt/eon0/boot/x86.eon.1
gzcat /mnt/eon0/boot/x86.eon > /tmp/x86.486

crashed

I tried this several times, and reboot brings us back to “eon” installed on the vm partition. So, perhaps we can’t do the updimg.sh on the installed system.

Did I do some of the steps in the wrong order?
Thanks,
joseph

Andre Lue said...

Joseph,

The install.sh has a problem with disks vdi/vm disks. I'm looking into this.

First you have to get it installed to the vm disk and boot off that. Then you run setup, then updimg.

For now, after manually formatting the disk and cutting s0 (manual install.sh).
newfs -v /dev/rdsk/c0d0s0
installgrub -m /path_to_iso/boot/grub/stage1 /path_to_iso/boot/grub/stage2 /dev/rdsk/c0d0s0
mount /dev/dsk/c0d0s0 /mnt/install
cd /path_to_iso
find boot | cpio -pdum /mnt/install

reboot

all should come up ok from the vm disk.
setup
updimg.sh (to preserve changes)
reboot

Andre Lue said...

Joseph

gzcat /mnt/eon0/boot/x86.eon > /tmp/x86.486

If it crashes on the above it most likely means you don't have enough ram for the uncompressed image + the running memory. Temporarily increase the vm memory to 850Mb.

Brandi said...

Hi Andre,

do you have an actual build script to verify the installation with an snv_104 or later build?

I created an image with your imgsol.sh script and snv_104 and snv_108 and I cannot get the cifs server to work.

Thanks

Cheers Thomas

Andre Lue said...

Brandi,

I remember getting this error in the past and filed a bug with sun. When I tried snv_104 and it worked I just assumed it fixed.

The error is caused by the smbsrv module loading but failing to bind. I will clean up the dev environment as soon as I have some BW and share it but I didn't do anything out of the ordinary to get smbsrv loaded and attached.

joseph.schafer said...

Andre,
Thank you very much. Your clarification did it.

After manually cutting the slice as I described earlier, I was able to run install.sh.

Then shutdown, remove the iso, boot and run setup & updimg.

thanks again,
joseph

joseph.schafer said...

And also I increased the vm memory to 1gb.
thanks again,
joseph

joseph.schafer said...

Andre,

Thanks again. I've got it working, but it has a couple of issues.

Most serious is that the shares "disappear" after a time and the vm freezes up. I've seen this in other recent solaris distros such as nexenta as well. The only hint I can find is the NbtDatagramDecode errors every twleve minutes. But that could be a complete distraction. I appreciate any advice.

Here's a tail of dmesg:

#dmesg
...
Mar 6 21:03:07 veon /sbin/dhcpagent[52]: [ID 778557 daemon.warning] configure_v4_lease: no IP broadcast specified for e1000g0, making best guess
Mar 6 21:03:17 veon svc.startd[7]: [ID 652011 daemon.warning] svc:/network/http:apache22: Method "/lib/svc/method/http-apache22 start" failed with exit status 95.
Mar 6 21:03:17 veon svc.startd[7]: [ID 748625 daemon.error] network/http:apache22 failed fatally: transitioned to maintenance (see 'svcs -xv' for details)
Mar 6 21:03:19 veon genunix: [ID 390243 kern.info] Creating /etc/devices/devid_cache
Mar 6 21:03:24 veon smbd[416]: [ID 766186 daemon.error] NbtDatagramDecode[11]: too small packet
Mar 7 14:01:28 veon ntpdate[561]: [ID 774510 daemon.notice] step time server 192.43.244.18 offset 61080.112255 sec
Mar 7 14:01:28 veon xntpd[562]: [ID 702911 daemon.notice] xntpd 3-5.93e+sun 03/08/29 16:23:05 (1.4)
Mar 7 14:01:28 veon xntpd[562]: [ID 301315 daemon.notice] tickadj = 1, tick = 1000, tvu_maxslew = 999, est. hz = 1000
Mar 7 14:01:28 veon xntpd[562]: [ID 266339 daemon.notice] using kernel phase-lock loop 0041, drift correction 0.00000
Mar 7 14:01:28 veon last message repeated 1 time
Mar 7 14:01:31 veon genunix: [ID 390243 kern.info] Creating /etc/devices/devname_cache
Mar 7 14:02:28 veon smbd[416]: [ID 766186 daemon.error] NbtDatagramDecode[11]: too small packet
Mar 7 14:07:44 veon last message repeated 4 times
Mar 7 14:10:48 veon smbd[416]: [ID 766186 daemon.error] NbtDatagramDecode[11]: too small packet
#

Also there's a message about a bad time-of-day battery on startup - and you can see the big adjustment in the dmesg above.

Thanks again and appreciate any insight,
joseph

Andre Lue said...

Joseph,

The NBt message are normal but I have not seen the freezing, but I don't use eon under vmware. I may give it a look.

The bad time of day mesg is a vmware - solaris thing. There are quite a few fixes
- ignore it, but time is off, maybe 1970
- delete the line 'nvram = "sol10.nvram" ' in your .vmx machine file
- set tod_validate_enable = 0 in /etc/system and install vmware tools

There are other solutions you can google to find more info.

joseph.schafer said...

Andre,
Thank you for the quick response.

What does the Nbt error mean?

joseph

CC said...

I would like you to try something for me. I've been using Nexenta 1.01 and the v2 beta 2. I'm using WinSCP and Filezilla to transfer files to my directory.

No matter if I use SFTP or SCP, with the 'preserve timestamp' turned on, my folder timestamps and, randomly, my file timestamps are changed. It doesn't do it on my Fedora core 5 server. I'm wondering if this is a Nexenta issue, or if it is a Opensolaris issue.

Could one of you guys test this out on EON? Thanks!

Andre Lue said...

CC,

Don't think it's opensolaris.
I'd say double check your
- client
- TZ of the server

beauty:~ andrel$ scp -p pre* admin@192.xxx.xx.26:/tmp
The authenticity of host '192.xxx.xx.26 (192.xxx.xx.26)' can't be established.
RSA key fingerprint is e9:ad:9d:c6:bf:98:9d:03:78:3e:34:1d:bc:2f:04:f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.xxx.xx.26' (RSA) to the list of known hosts.
Password:
pre-SUNWapch22r 100% 9677 9.5KB/s 00:00
pre-SUNWapch22r-104 100% 9919 9.7KB/s 00:00
pre-SUNWcsu 100% 41KB 41.0KB/s 00:00
pre-SUNWdtrc 100% 16KB 15.6KB/s 00:00
pre-SUNWesu 100% 2241 2.2KB/s 00:00
beauty:~ andrel$ ls -al pre*
-rw-r--r-- 1 andrel andrel 9677 Mar 19 01:07 pre-SUNWapch22r
-rw-r--r-- 1 andrel andrel 9919 Mar 19 01:07 pre-SUNWapch22r-104
-rwxrwxrwx 1 andrel andrel 42018 Mar 18 18:52 pre-SUNWcsu
-rwxrwxrwx 1 andrel andrel 15957 Mar 18 17:31 pre-SUNWdtrc
-rw-r--r-- 1 andrel andrel 2241 Mar 19 00:58 pre-SUNWesu

beauty:~ andrel$ ssh admin@192.xxx.xx.26
Password:
Last login: Fri Mar 20 21:29:57 2009 from 192.xxx.xx.23
Sun Microsystems Inc. SunOS 5.11 snv_109 November 2008
eon:1:~>ls -al /tmp
total 186
drwxrwxrwt 2 root sys 544 Mar 20 21:29 .
drwxr-xr-x 19 root root 512 Mar 20 21:27 ..
-rw-r--r-- 1 root root 0 Mar 20 21:27 iconf_entries.437
-rw-r--r-- 1 admin stor 9677 Mar 18 22:07 pre-SUNWapch22r
-rw-r--r-- 1 admin stor 9919 Mar 18 22:07 pre-SUNWapch22r-104
-rwxrwxrwx 1 admin stor 42018 Mar 18 15:52 pre-SUNWcsu
-rwxrwxrwx 1 admin stor 15957 Mar 18 14:31 pre-SUNWdtrc
-rw-r--r-- 1 admin stor 2241 Mar 18 21:58 pre-SUNWesu
eon:2:~>Connection to 192.xxx.xx.26 closed.

CC said...

Thanks Andre,

I've been doing more testing, and it looks like the folder itself is getting its timestamp modified to the current time (and not the files inside).

All folders, recursively within a folder, are also being modified to the current timestamp. Any files timestamp is modified if I interrupt the transfer on WinSCP. I've had entire directories modified of their timestamps for no reason. I can't seem to reproduce things though.

Could you see if you get a folder timestamp modification, especially when you transfer over folders and their recursive directories? With my limited knowledge, you have proven that the files don't change timestamps. Thanks!