madburg

Right, I've noticed some strange things with MAC addresses as well - but haven't really looked into yet. I am going to release -beta4 and then I have to release 5.0.6, and then I can get to this. Understood, I assumed you where close to getting beta 4 out, so it would have to be after. Would be good to nip this in the bud before it comes out of beta. I will add some comments later as I don't have time today and have to run. Thanks for the acknowledge reply. If you saw @bonienl webgui code a few posts back in this thread and can add to beta 4 for testing that would be great, if not please don't lose track of it for following beta; so there's no nagging involved later. Thanks.

Tom have a bug for you. It didn't occur to me at first, but everytime I rebooted v6b3 (default boot not XEN) on physical HW or Virtual Machine I received a different IP from DHCP (should not be the case as the lease wasn't expired, but dint think anything off it at first). So later on I decided to make a DHCP reservation on the mac address (like i have for a dev v5 vm), thats when I saw the problem. v6b3 generates a new mac address (unique identifier) with each reboot and it isnt the traditional six groups of two hexadecimal digits, its 36 hexadecimal digits in total? The console shows the 12 hexadecimal digits (for eth0) but thats not what is being transmitted. The last 12 digits of the 36 digit Unique Identifier is the mac address of the nic. See screenshot of the v6b3 vm on my dev vlan 10.10.150.x See screenshot of the v6b3 physical host on my prod vlan Secondary (i think), I wondered what if I release the dhcp address and renewed it, that worked so it generates a new Unique Identifier only per reboot. But while testing a release/renew 'dhcpcd -n' on v6b3 it brings up other network interfaces (gre0, ip_vti0, tunl0) that are hidden/dormant upon first booting up and show them self upon issuing the command: Default boot (not Xen) root@Tower6Dev:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.150.7 netmask 255.255.255.0 broadcast 10.10.150.255 ether 00:50:56:98:59:66 txqueuelen 1000 (Ethernet) RX packets 75 bytes 14009 (13.6 KiB) RX errors 0 dropped 4 overruns 0 frame 0 TX packets 120 bytes 19336 (18.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 0 (Local Loopback) RX packets 62 bytes 5708 (5.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 62 bytes 5708 (5.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 root@Tower6Dev:~# cd .. root@Tower6Dev:/# cd boot/config root@Tower6Dev:/boot/config# cat network.cfg # Generated settings: USE_DHCP="yes" IPADDR="10.10.150.112" NETMASK="255.255.255.0" GATEWAY="10.10.150.1" DHCP_KEEPRESOLV="no" DNS_SERVER1="10.10.50.151" DNS_SERVER2="10.10.50.150" DNS_SERVER3="" BONDING="no" BONDING_MODE="1" BRIDGING="no" BRNAME="br0" root@Tower6Dev:/boot/config# dhcpcd -n dhcpcd[1309]: version 6.0.5 starting dhcpcd[1309]: gretap0: up_interface: Cannot assign requested address dhcpcd[1309]: forked to background, child pid 1310 root@Tower6Dev:/boot/config# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.150.7 netmask 255.255.255.0 broadcast 10.10.150.255 ether 00:50:56:98:59:66 txqueuelen 1000 (Ethernet) RX packets 192 bytes 29889 (29.1 KiB) RX errors 0 dropped 8 overruns 0 frame 0 TX packets 215 bytes 31336 (30.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 gre0: flags=193<UP,RUNNING,NOARP> mtu 1476 unspec 00-00-00-00-FF-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (U RX packets 2 bytes 764 (764.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2 bytes 724 (724.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ip_vti0: flags=193<UP,RUNNING,NOARP> mtu 1500 tunnel txqueuelen 0 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 2 dropped 0 overruns 0 carrier 2 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 0 (Local Loopback) RX packets 62 bytes 5708 (5.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 62 bytes 5708 (5.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tunl0: flags=193<UP,RUNNING,NOARP> mtu 576 tunnel txqueuelen 0 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 3 dropped 0 overruns 3 carrier 0 collisions 0 Default Boot v5, same exact commands as above. root@Tower5Dev:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:98:2b:ed inet addr:10.10.150.110 Bcast:10.10.150.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:67 errors:0 dropped:12 overruns:0 frame:0 TX packets:100 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:26156 (25.5 KiB) TX bytes:15074 (14.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 B) TX bytes:560 (560.0 B) root@Tower5Dev:~# cd .. root@Tower5Dev:/# cd boot/config root@Tower5Dev:/boot/config# cat network.cfg # Generated settings: USE_DHCP="yes" IPADDR="10.10.150.110" NETMASK="255.255.255.0" GATEWAY="10.10.150.1" DHCP_KEEPRESOLV="no" DNS_SERVER1="10.10.50.151" DNS_SERVER2="10.10.50.150" DNS_SERVER3="" BONDING="no" BONDING_MODE="1" root@Tower5Dev:/boot/config# dhcpcd -n dhcpcd[1552]: version 5.2.7 starting dhcpcd[1552]: forked to background, child pid 1553 root@Tower5Dev:/boot/config# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:98:2b:ed inet addr:10.10.150.110 Bcast:10.10.150.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:183 errors:0 dropped:16 overruns:0 frame:0 TX packets:186 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:42534 (41.5 KiB) TX bytes:26135 (25.5 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

Originally (years ago) I purchase many 2 TB drives and precleared them all, slowly as I needed them I added them to the unRAID server, unRAID always cleared them, never picked up the signature set by preclear. I had no idea why at the time and didn't have any more drive to figure it out. It was long ago between pre-clearing them and adding them in. Well I just picked up (2) 3TB drives. I just finished pre-clearing them and added them to my unRAID 5.0.4 production server, unRAID is clearing them (v1.14) once again, it did not pick up the signature. So only thing I can think of is this. Originally when I first started with unRAID I would preclear drives on the same server with the array up and running. Stopping the array and adding the newly pre-cleared drive(s) worked (signature detected). Once I purchased all those other 2 TB drive to have on hand and now these latest (2) 3 TB drives I have been pre-clearing them from another server. Once the preclear finished I would shut that server down, followed by shutting down the production server, moving the drives to the production server. Powering up the production server and adding the disks to the array. And the signature is not read. So I do know how this all works but it almost seems like running a preclear on a different server than where they will be added to the array is not working... My understanding is the signature written to disk is not hardware specific.. so lost as to why it is not working. The desktop I preclear from is an old AMD desktop MB (SATA MB ports), the prod server is an Intel Server MB (SAS controllers) with Xeon proc.

Thanks for sharing, now that they changed it, lol None around NY , great drives, good deal.

@bonienl, that sounds right. It's no show stopper, but this is finally the best OOB WebGui I've seen come with unRAID, many welcomed small additions the community requested in the past and so far the only small bug I noticed thus far (haven't test a few thing like how new permission's is displayed yet, system info seems to be off when unRAID runs in a VM, will post that later). So if the code in your post is the fix to help polish this up, would be nice to get it into Beta 4.

unRAID v6 Beta 3, lastest preclear script. (1) 3TB Hard drive installed (SATA MB) to test, no other hard drives installed, so array is not started Low memory utilization until writing zero's At Step 2 of 10 - Copying Zeros to remainder of disk to clear it (97% Done) 'Free- l' while at this step above (via screen) total used free shared buffers cached Mem: 8170244 7931528 238716 0 7207300 426780 Low: 8170244 7931528 238716 High: 0 0 0 -/+ buffers/cache: 297448 7872796 Swap: 0 0 0

Maybe some sort of permission being set not allowing it to be viewed (hidden)?

If you type cat /proc/mounts the tmpfs shows up there. Not sure why the 'df' command is not showing it... Its not showing up under the 'mount' command either? here is cat /proc/mounts from my v5.0.4, v6b3 VM, v6b3 Phy (maybe it will help you? I dont get it.) unRAIDv5.0.4: rootfs / rootfs rw,relatime 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /dev tmpfs rw,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 tmpfs /var/log tmpfs rw,relatime,size=2072972k 0 0 /dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0 unRAIDv6 VM: rootfs / rootfs rw 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /run tmpfs rw,relatime,mode=755 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1982016k,nr_inodes=495504,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 cgroup /sys/fs/cgroup cgroup rw,relatime,perf_event,blkio,freezer,devices,memory,cpuacct,cpu,debug,cpuset 0 0 tmpfs /var/log tmpfs rw,relatime,size=131072k,mode=755 0 0 /dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0 unRAID v6 Physical: rootfs / rootfs rw 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /run tmpfs rw,relatime,mode=755 0 0 devtmpfs /dev devtmpfs rw,relatime,size=4010044k,nr_inodes=1002511,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 cgroup /sys/fs/cgroup cgroup rw,relatime,perf_event,blkio,freezer,devices,memory,cpuacct,cpu,debug,cpuset 0 0 tmpfs /var/log tmpfs rw,relatime,size=131072k,mode=755 0 0 /dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0 Just tried: mount -t tmpfs -o remount,size=50% tmpfs /var/log Command succeeded, still not showing up with 'df' or 'mount', but /proc/mounts does display the change in size to tmpfs /var/log size.

Clicking 'Apply' just sets up config info for ntp; ntp sometimes takes a while to actually update the time. Oh ok, thanks for the info.

Done. Thank you sir!

+1 my AFP dependency is not for TM

In Confirmation Preferences, if you set "Uncommitted changes warning:" to "Yes" Main Page: When checking off "Yes I want to do this" for Power Down or Reboot the web gui notify's you that "You have uncommitted form changes" (small bug) If you don't commit to Power Down or Reboot and uncheck "Yes I want to do this", the same notification occurs.

In v6 Beta3 upon booting (physical hardware, no XEN boot, array not set to auto start) I have no tmpfs? v5 I see tmpfs: df -aTh In v6B3 i dont see a tmpfs? v5 rc.S # tmm - Move /var/log to a tmpfs mv /var/log/* /var/empty mount -t tmpfs -o size=128m tmpfs /var/log mv /var/empty/* /var/log v6 rc.S # If /run exists, mount a tmpfs on it (unless the # initrd has already done so): if [ -d /run ]; then if ! grep -wq "tmpfs /run tmpfs" /proc/mounts ; then /sbin/mount -v -n -t tmpfs tmpfs /run -o mode=0755 fi fi ... # Check the root filesystem: if [ ! $READWRITE = yes ]; then .... else # limetech - root filesystem is in RAM so always is read/write # echo "Testing root filesystem status: read-write filesystem" # echo # echo "*** ERROR: Root partition has already been mounted read-write. Cannot check!" # echo # echo "For filesystem checking to work properly, your system must initially mount" # echo "the root partition as read only. Please modify your kernel with 'rdev' so that" # echo "it does this. If you're booting with LILO, add a line:" # echo # echo " read-only" # echo # echo "to the Linux section in your /etc/lilo.conf and type 'lilo' to reinstall it." # echo # echo "If you boot from a kernel on a floppy disk, put it in the drive and type:" # echo " rdev -R /dev/fd0 1" # echo # echo "If you boot from a bootdisk, or with Loadlin, you can add the 'ro' flag." # echo # echo "This will fix the problem *AND* eliminate this annoying message. :^)" # echo # echo -n "Press ENTER to continue. " # read junk; # limetech - move /var/log to a tmpfs mv /var/log/* /var/empty mount -t tmpfs -o size=128m,mode=0755 tmpfs /var/log mv /var/empty/* /var/log fi # Done checking root filesystem

When setting NTP to Yes and specifying same internal NTP server as set in production v5 server, time is 12 minutes ahead on the v6 server. I can click apply (NTP page) on both servers, v5 has the same time as clients and NTP source, v6 is 12 minutes ahead. Reboot of v6 Beta3 server still 12 minutes ahead. Update (day later): Created a VM under esxi to test unRIAD v6b3, set same NTP, time was correct. Booted up physical unRAID v6b3 server again this evening to start some more test, first thing i check on was the time, now it is correct. Not sure what the gitch was on the first day, and reboots did not help.

Tom, In v5 you updated smartmontools to version 6.2 as requested (smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build)) In v6Beta 3 smartmontools is version 5.43 (smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.10.24p-unRAID] (local build)) Can't update HD DB (/usr/sbin/update-smart-drivedb) Please update for v6 Beta 4.

Problem maybe that not enough people have the equipment and/or time to test a beta like this at this point because its not recommended or supported on a production system. So as an example someone in a country who spent a great amount of money (thats how pricing goes in some countries) on a media player with NFS3 support only and only has 1 system can't chime in (not in the know). Or someone with a complex system with say one component being attaching an esx server(s) to unraid but doesn't have the time to follow the threads only realizes later as v6 comes out of beta (just an example here) what changed (removal of NFS3). Not a happy camper. This is why i firmly believe a v5 counterpart as the first v6 (64 bit) would go a long way to keep the vast client base happy. I can't speak for Tom, but if he was willing to work with 3 forks (made up labels here->) v5-32bit/v6-64bit/v6.1-64bit-Xen/Samba4/NFS4/No AFP/NFS3 whatever else, would be great. Or without knowing why he doesn't wish to have NFS3&4/AFP keep going, so for now with v6 keep them going would be another option. I (just my opinion) don't believe never giving what was already in v5 in a 64 bit flavor is the way to go, and tell people stay on v5 if thats what you want, not that he official made that stance, but the remarks being made is so he is aware to hopefully make the right call. Many of us are still trying to put something together hardware wise to even begin testing, i'll be starting v6 in a VM soon as the first round of testing, as my HW and budget are coming together at a slow pace personally.

Yes and no; Yes it is 64 bit but it has newer modules (I'm not referring to xmail, etc.), and the newer kernel is understandable but a lot of code changes, so it could lead to skewed results. Hate to pollute this thread about all this, if you want to fork these posts of my here please do.

Interesting as whenever anyone states memory issues, and thats why we just want a 64 bit version of unRAID that is LIKE the 32bit 5 version of unRAID with no other bells and whistles, bunch of people jump all over on what memory issues? But since we can't get a 64 bit counterpart its really hard to show a before and after.

Not supported? It not as simple as enable or not, you have to have the means to set AFP Security setting per disk and/or TM settings as well, with no native emHTTP support, how so? Only thing some of us do and Tom didn't provide is set the DB to a non array disk so we don't lose it and its data when a reboot is require of unRAID. No interest to use anything someone outside of Tom attempts to make. IF so same should be done with NFS, make it an addon. No interest in Xen nor VM, need AFP at the unRAID layer as all supported protocol have been. IF so, off load NFS to a VM as well.

You start talking crap about AFP in this thread, when you yourself stated to wait from Tom on a AFP thread, now you are no longer happy so your deleting post and now state "The debate got quite passionate and heated there with nor real technical content"? Really?

Sure no problem, keep blabing. Not what product, its unRAID that takes a crap with products running under AFP, if parity check is running you cant access anything at all. Tom knows all this, we had discussions, logs submits. I couldnt care less what you think nor owe an explanation or prove anything to you. What product use NFS3 and cannot run that NFS3 needs to be dropped?

Your at liberty to say what you want, I stated my piece as well. Just remember since your not using it you shouldnt be so quick to express your view on those who do.

Who cares? the people requesting it be update in unRAID and have dependancies on it. Endorsed? What are you talking about, it is supported today by them and will be until the day they finish with the dependancies and third party dev make the move as well. That isnt happening today nor tomorrow. But Tom clearly stated he would not compile the lastest version and add it in the v5 series and that he would do it with the start of v6. So once again people make crap us as it pleases them. Im going by what the developer of the product stated, which just threw a curve ball by entertaining the notion to back pedal on AFP altogether. Drop all versions of NFS in v6, I dont use it and see no benefit, what you want it? use v5 then. After all Tom couldn't get NFS3 working properly, like other companys have. Wasting time to see if he can get NFS4 to work, I see no benefit. Just this sound better and fair to you?

For someone who has no interest in reading about it (nor use's AFP), you have alot to say. Whats the benefit to dropping it? There is no benefits to dropping AFP at this time, Apple isnt going to get everything working overnight and neither are the apps we work with. Like many of you like to say, if your not using it then dont, and dont enable it, how does it bother you. I've been waiting for 64 bit unRAID and the lastest AFP bundle, which Tom stated AFP would be upgrading in v6, so no i would be very unhappy with having to stay on v5 and older AFP. Easy for someone to state when they have no care or use for it. If Tom complied and added the updated AFP in the next v6 Beta, his promise is kept and things would move on, instead of these ramblings.

This is why people are speaking up in regards to AFP. I have AFP dependencies with unRAID. Tom, I have waited patiently for the upgrade to AFP 3.x in unRAID (right now 3.1.0 or 3.0.7) that you promised you would take that up in v6 of unRAID. You were left alone to fix other things and now started up v6 betas, so please add it already, its been way too long waiting on this. With time you probably will not need to upgrade/maintain it past 3.0.7/3.1.0 and drop it altogether in another version of unRAID, but some of us have been waiting and waiting and now to hear talks about eliminating entirely without ever delivering is not cool. P.S. there's no disagreement that its crap, but the peace of sh^t of a protocol is needed (upgraded) for now.