It is available in a CIFS and Samba flavor
EON 64-bit x86 CIFS ISO image version 0.59.3 based on snv_122- eon-0.593-122-64-cifs.iso
- MD5: 8be86fb315b5b4929a04e0346ed0168c
- Size: ~89Mb
- Released: Monday 14-September-2009
EON 64-bit x86 Samba ISO image version 0.59.3 based on snv_122- eon-0.593-122-64-smb.iso
- MD5: f68fefdc525a517b9c4b66028ae4347e
- Size: ~101Mb
- Released: Monday 14-September-2009
EON 32-bit x86 CIFS ISO image version 0.59.3 based on snv_122- eon-0.593-122-32-cifs.iso
- MD5: fa71f059aa1eeefbcda597b98006ba9f
- Size: ~56Mb
- Released: Monday 14-September-2009
EON 32-bit x86 Samba ISO image version 0.59.3 based on snv_122- eon-0.593-122-32-smb.iso
- MD5: 1b9861a780dc01da36ca17d1b4450132
- Size: ~69Mb
- Released: Monday 14-September-2009
- triple parity RAIDZ3, since snv_120
- added 32/64-bit drivers: bnx, igb
- Workaround fix for IP validation in setup.sh
- added /usr/local/sbin for bin kit to bashrc
- eon rebooting after grub in ESXi, Fusion and some versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"
36 comments:
Great, I like EON's stability.
in esxi 4.0 EON do cycled-reset :(
Thanks Alex,
Your work serves as an inspiration.
dimsoft,
I think I've seen what you are referring to on fusion. I haven't tested ESXi. I'm not sure what is causing this. Can you do me a favor and provide feedback on these actions:
-Press e at the boot splash/grub screen
-add -v -m verbose to the end of the line
-press enter, then b and see if you can get me a screenshot just before it cycles or tell me if its a kernel dump.
For the novice could you explain what this is in your blog article and why this is a great thing to run?
Thanks
e-blogger,
Please see the Wiki or the FAQ link in the upper right or the blog.
This is looking pretty interesting. I was messing around with the eon.x86 image file on zfs-based flash (disk-on-module), and got it booting. However, when making some minor changes to the image file to run the serial console at 57600, everything works well until the console-login service runs. After that, it seems that the 9600 speed is hard-coded. Also, I don't see ttymon running in the process list. Is there something obvious I'm missing as to how the console services are running?
Mark,
Most recommendations I recall seeing set 115200 if I recall correctly.
Serial redirect
Andre --
Actually, I had followed all the proper steps setting the serial speed @ 57600. When the box boots, I get the bios just fine, I get the grub menu just fine, and I get the initial boot up just fine. But, even though I modifed /var/svc/manifest/system/console-login.xml to change the "label" field to 57600, when the console-login service runs, my screen turns to garbage. when I exit tip, and go back in @ 9600 baud, I see the eon console login then. So I was wondering if something got hard-coded in the eon release, as I can't find where the 9600 baud setting is coming from. Also, I didn't see a ttymon process running, which I thought odd.
Thanks,
Mark,
Nothing hardcoded on the part of eon. When ttymon is running what value do you see as it's args for the speed?
Maybe ask in the general opensolaris discuss forums, also.
I repeated this test is running vmware workstation and made a video recording
http://rapidshare.com/files/282275189/EON_Movie003.avi.html
Andre --
The really weird part is when I did log in, multiple ps -ef calls never even showed ttymon running, and the boot process did not throw any exceptions to cause sulogin to run instead.
In a few days, when I have time again, I'll replicate the procedure with some screen shots, and should be able to put them somewhere accessible.
Thanks,
dimsoft,
Thanks for the video capture. I think this may be related to bug 6820576. Using the same sequence at grub press e and try adding on the end of the kernel line, only (not module line):
-B disable-pcieb=true
ok
it is work :)
I have to import my zfs pool every time I reboot. Is that normal?
Joseph,
Sounds like setup.sh has not been run to lock in a hostid. If the hostid is different from the last hostid that the imported the pool, then yes you would have to run zpool import. Running setup and ID'ing the system should fix that.
Maybe lighttpd or nginx instead of the bloated apache2? Just my two cents...
Bloated as in "too big, complex, etc. for a small, embedded NAS as EON", don't get me wrong apache people :)
Avram,
I actually have a lighttpd version but I don't know the user base preference of light vs apache. nginx is really nice but has no CGI support. I may give it a look.
It would be nice to know the user base preference of light vs apache. Maybe start a thread.
Have tried snv_119 & snv_122 where find . |grep anything
where . is at location of rawdisk and EON is on vbox.
Result is either hang or ZFS pool gone.
Is this version safe for use with raidz? (wasn't 122 affected by a bug?)
For people that need to run in VMPlayer (to create the USB installation from windows) is enough to copy the following lines to a file called "EON.VMX" and put the file in the same directory of .iso:
8<-----------
#!/usr/bin/vmplayer
guestOS = "solaris10-64"
displayName = "EON"
numvcpus = "1"
memsize = "512"
usb.present = "TRUE"
usb.generic.autoconnect = "TRUE"
sound.present = "TRUE"
sound.autodetect = "TRUE"
svga.autodetect = "TRUE"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "vlance"
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.generatedAddressOffset = "0"
floppy0.present = "FALSE"
ide1:0.present = "TRUE"
ide1:0.fileName = "eon-0.593-122-64-cifs.iso"
ide1:0.deviceType = "cdrom-image"
ide1:0.mode = "persistent"
ide1:0.startConnected = "TRUE"
ide0:0.present = "FALSE"
8<----------
PS: the file is based on 64bit CIFS (correct iso name or solaris version if different!)
Jezyk,
As far as I know snv_122 is safe for RAIDZ.
Thanks for the VMPlayer info. I would increase memsize = "512" a bit for 64-bit eon.
Maybe depending on the vmware version other two lines has to be added:
8<------
config.version = "8"
virtualHW.version = "4"
8<------
PS: by chance my avast antivirus was checking the 64bit cifs iso file and gulp reported "Win32:Siveras-B [Expl]" malware in "eon-0.593-122-64-cifs.iso\boot\x86.eon\mr20280"!...someone else found something like this?
Jezyk,
I can assure you it's a false positive. Most likely triggered by the compressed ufs that it cannot read. It contains all the (unix) files for eon.
If you wish to decompress as proof to yourself follow these steps on a solaris box or eon. Do not do this to the image you are booting off.
mv x86.eon x86.eon.gz
gzip -d x86.eon.gz
lofiadm -a /path/to/x86.eon /dev/lofi/1
mkdir -p /tmp/a
mount /dev/lofi/1 /tmp/a
cd /tmp/a
and there you will see all the same files you see when eon is booted.
Absolutely no malware in x86.eon!
In fact it was at least strange to find a windows virus in a solaris distribution, and sure solaris is safer!! :-)
Another thing: I was testing the distribution and installed on usb; in order to improve security I was willing to change users password. Looking at the passwd file I found: root (of course ;-), daemon, nib, sys, adm, lp, uucp, nuucp, dladm, smmsp, listen, gdm, zfssnap, upnp, xvm, mysql, openldap, webservd, postgres, svctag, nobody, noaccess, nobody4, admin!
Now, are these users all needed? And since we have a common distribution, there will not be security issues? (knowing available users or even passwords)
Sorry if is a silly question, but I wuold remove the unuseful and change the password after installation to the rest if possible!
Jezyk,
It is recommended to change the password of root and admin. The others are all system users and do not need any changes. You should also understand their use before changing them.
For example, nobody is the default user most daemons will switch to for security reasons.
i am impressed with the project and feel their is a real need in the Home/SMB NAS market for this. thanks Andre!
like Joseph (above) mentioned, i also have to do a 'zpool import' after a reboot.
running on a VIA chip system and a SanDisk 4GB Cruzer USB drive.
s/w is the 32bit, SMB, 0.59.3 .iso binary from genunix :
- burned and booted the CD, did an 'install' to the USB Drive
- booted from USB, ran 'setup', then created a zpool and zfs file sys (checked with zpool and zfs 'list'
- ran updimg.sh, no probs
- rebooted and zpool list says no pools available.
host name was changed and ../mnt/eon0/zpool.cache look fine.
was able to set up and use NFS before the reboot, and dmesg does show a dump core ...
"syseventd[152]: [ID 555171 daemon.error] Fatal:attempting to dump core"
looking forward to adding webmin and binaries ..., great stuff-
lc,
Thanks, I appreciate the feedback.
Can you do me a favor. I would like to try and reproduce the core dump caused by NFS. If you can forward me the steps/cmds that led to it.
With the zpool import issue. Can you paste the output to anew thread or to pastebin for
hostid
zdb -v
andre -
i posted to http://zdb-v.pastebin.com/m415a4ace
basicallym the prev. version with cics and dhcp works fine.
am trying to change dhcp to static cause that is what i need.
txs
lc,
I'm a little confused. Is there an actual core?
du -ak / | grep core
The 192.168.0.200 bug supposed to be fixed? Can you do
grep -n validate_ip /usr/bin/setup
And confirm if you see?
235: # validate_ip
Sound like you should restart with the oem image? If you run setup and enter IP then /etc/hostname.rge0 will contain an IP and no dhcp.rge0 file should exist.
If you run it again for dhcp /etc/hostname.rge0 will contain hostname and dhcp.rge0 will exist.
andre -
i installed 0.59.3-32-smb a few times with the same problem:
zfs config info went away, and i had to do a 'zpool import xxx'.
installed 0.59.2-32-cics, and zfs config info was saved across reboots from a USB drive.
am now testing with VirtualBox (on Osol) and usb pass-through (great stuff!) and with both versions of eon i see from "dmesg | grep core":
"Fatal:attempting to dump core"
i don´t see any cores from your command:
du -ak / | grep core
thanks for the help, i am going to use/test with 0.59.2 for now.
lc,
I would recommend using 0.59.3 based on snv_122 for quite a few reasons (better performance, validate_ip fix in updimg.sh, ...).
To workaround the zpool import issue, you can place the command in /mnt/eon0/.exec and it will be done automatically.
ok andre, will take your advice -
When I tried running install.sh from the eon-0.593-122-64-cifs.iso image, it failed to find GRUB stages 1 & 2. Tried by booting the image in VMWare Fusion, and when that failed, burned a CD and tried from a physical PC. No dice. Any suggestions?
Dave,
If grub stage 1 or 2 was not found it most likely means the cd/iso image was not mounted at boot time.
I was able to find and fix a few bugs with install.sh if run multiple times. I have a few workarounds but the easiest is to post the new install.sh for download, then after booting, retrieve and run the new version. You can then use updimg.sh to preserve the image with the new version.
Andre.. thanks for the great work
I am running into the grub stage not found error when I tried to install on my local server.
All the commands work up to that point, but when I run install.sh it doesn't work
You mention that most likely iso didn't get mounted. is there a manual work around?
Post a Comment