mrjofus1959

OK so when I (finally) upgraded from 4.7 to 5.0.6 yesterday I followed the instructions here: http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta_Release_Notes Since I was coming from 4.7 I used the section for Version 4.7 which only had me copy bzroot and bzimage from the downloaded zip file to the root of my USB flash drive. No syslinux.cfg, syslinux.exe or menu.c32. The system booted fine and everything seems to be working fine (other than accessing unMenu which I mentioned in a separate post), so should I just plug along happily? Thanks!

Thanks WeeboTech, that did the trick. I've never been a Linux wizard.

Now that I finally upgraded from unRAID 4.7 to 5.0.6 I'm getting emails with what I perceive to be an odd "From" source. With 4.7 all of the system emails sent to me by unRAID root came with a FROM address of [email protected]. Now they're coming with FROM showing up as "Console and webGui login account", which when I evaluate in my email does show the [email protected]. Is there a way to change this? I know it's not a big deal, but I liked the previous format and I've been unable to figure out how to change this behavior. Thanks!

So I finally upgraded from 4.7 to 5.0.6 today. Yes I know, wow! My media server was running just fine the past 3+ years but today I decided I wanted to play around with Plex. Anyway I followed the upgrade instructions and everything seems to be working fine as far as accessing the server itself. But after installing the latest unMenu I'm getting some marginal behavior from when I go to http://media-server:8080. I am getting frequent errors stating that the web page isn't available. If I continue to refresh it will finally come up. This is happening when I'm trying to move around the various menus within unMenu itself. Can anyone tell me what I might try to "fix" this? Thanks!

Thanks, that's good to know! -Kevin (also)

That would certainly seem to be the case. Perhaps a better question is do I have anything to be concerned about with respect to having an NFS share source on my unRAID 4.7 server?

So over this past weekend I set about putting my PCH C-200 back in use in our family room. I've been using an HTPC in our pseudo-home theater room for a while so the C-200 was in retirement. Anyway, the HTPC has no problems whatsoever streaming Blu-ray movies (ISOs) from our new unRAID server using the default Samba share for that folder on the server. I sat through Beauty and the Beast with my granddaughters Saturday evening and there were no problems. But when I got the C-200 back online and tried streaming a Blu-ray ISO I was getting horrible stuttering. Remembering a similar problem back when I first started using WHSv1 to stream to the C-200 where I had to use NFS shares on the WHSv1 server, I setup NFS for the Blu-ray-Movies user share on unRAID using *(ro). I updated that share on my C-200 and viola!, it works just fine now streaming a Blu-ray ISO. So my question is, is this behavior to be expected or have others at least seen the same thing?

And not to be too a-retentive, but I have a printout of the unRAID main screen showing all 22 of my drives with serial numbers versus parity, disk#, and cache. I slid it in the outer sleeve of a 3-ring binder that I use for storing unRAID documentation. It came in very handy when I switched motherboards recently.

Updated to reflect level 1 tested on unRAID 4.7 And for the record I have successfully copied 6-7 TB of data over the network from my Windows 7 PC to this unRAID server using the motherboard's built-in Realtek NIC. Server "standby" power (i.e. all drives spun down) is about 63W per my APC UPS. I credit the Supermicro SASLP boards for about half that power. But I can live with that being on 24x7 as it will cost less than $50 per year for standby mode. I prefer that to my old WHSv1 setup where I used LightsOut to put it to sleep.

Updated to reflect level 1 tested on unRAID 4.7 Also I copied about 400GB data to this temporary setup over the network from my Windows 7 PC using the mobo's built-in Realtek NIC.

Thanks for the detailed explanation Joe. That makes sense to me now. Once I'm done restoring all of my old WHSv1 data this will pretty much become a non-issue.

OK so here's what I just did. Mover was in the middle of copying a 37GB ISO from the cache disk to disk12 in my 20-disk array. I disabled spinup groups as suggested. I then did a manual spindown of all disks except parity, disk12 and cache. There was still about 30GB to go on the file after all disks were spun down. So I refreshed the myMain window of unmenu periodically while the file move continued. As soon as mover completed the rsync of the 37GB file to disk12, there was a pause in all activity in the myMain window with respect to disk reads & writes. And then lo and behold as soon as the next file transfer showed up after a page refresh in the "System Log (last 15 lines)" section of the screen there were other drives that had been spun up. After a couple more refreshes all disks were once again spinning. I'm stumped. This does not seem like "normal" behavior to me, but then again I've only been using unRAID for a few weeks now. Any other suggestions as to what I might try? Or is this just the way it is?

*BUMP* So should the mover script cause all disks to spinup when running? I have spinup groups enabled and each drive in my setups has a unique spinup group. Thanks, Kevin

Again my bad - I'm using 4.7. No issues with the NIC on this one either. I'll have to find some extra HDDs to do level 1 on this one, but I will try to do so.

Sorry I just have stated version 4.7. I haven't seen any issues with the NIC after about 10 days. I will definitely pull together the requirements for level 1 certified.

This is now my primary unRAID motherboard. Initially I wasn't to sure about it since while changing BIOS settings it went through some strange reboot looping, but it now appears to be a very solid setup. I'm using all 6 mobo SATA ports, plus 2 SASLP-MV8 controllers with a total of 22 drives (20 data, 1 parity, 1 cache). Update: Syslog attached confirming level 1 tested th67b-syslog-2011-10-17.txt

Just a quick FYI that this motherboard works fine for me for unRAID. I started out with this mobo and a single SASLP-MV8 and 10 drives total. It has now been relegated to a backup unRAID setup that's just used for preclearing drives at the moment. Update: Syslog attached confirming level 1 tested p8h61-syslog-2011-10-14.txt

As I've been copying terabytes of data over to my new unRAID server there have been a couple of times where I would have liked to terminate the mover script so I could cleanly shutdown the system and add another precleared hard drive (from another system where I'm preclearing drives). I have been searching for an answer in the forums but with no luck, so can anyone tell me if there's a nice clean way of killing the mover script and its rsync processes? I tried just killing them from within top but that didn't seem to do the trick. (FYI - Linux is new to me as far as working at this level of putting together a system.) Thanks, Kevin

Yes they are enabled but I have each drive assigned to its own group, where group=<disk name>, e.g. "parity", "disk1", "disk2", etc. I did that after I noticed multiple drive spinning up when accessing a file. I thought it was behaving correctly, but maybe not???

(Running unRAID 4.7) So not that I have my unRAID server up and running I'm going through the tedious process of moving data from my old WHSv1 NTFS drives to the new file system. I have a 2TB cache drive on my server, so when I copy files to the server they go straight to the cache drive as expected. When I invoke the mover script, or it starts as set, the data starts moving off the cache drive to the data disks within the unRAID array. But what surprises me is that all 11 of my data disks are spinning up even though a single drive is being written to. At first I had my spindown times set to 15 minutes. Then I noticed that when moving a very large file that takes more than that spindown down (like a 40GB+ Blu-ray ISO) the non-used drives would spindown. But as soon as the next file started moving all drives would spin up. Clearly I don't want the drives all spinning up and down that frequently so I reset my spindown times to 30 minutes so that now the drives are all spinned up until the mover process is finished. So to my question, am I correct it believing that as each file is being copied the unRAID system/driver is polling all drives to see where they stand relative to the high water mark? Is that normal system behavior? I'm sure that once I've got all my data moved this won't be a big deal since I won't be moving 1TB+ chunks of data off the cache drive on a daily basis, but I just want to make sure I'm not missing something in the way I have things setup. Thanks, Kevin

It appears you've started several screen sessions on your unRAID server so you need to go through each one to find out which one is running the preclear script. For example, screen -r 943.pds-0.UR1 will get you to the first detached screen session. If nothing is running in there I'd say you should "exit" that screen session. Then do the same for each screen process until you have just the one running that contains the preclear session. I'm a new user here but the way I've been running preclears is to telnet to my server with putty, start a screen session, start a preclear, enter ctrl-a then ctrl-d to leave the screen session running in the background, and then exit the putty telnet session (or not). I only start one screen process and if I want to preclear more than one drive I follow the above flow but instead of ctrl-a/ctrl-d I enter ctrl-a/c to create another process within which to start another preclear. Hope that makes sense.?

First a correction to my last post - I am using the ntfs-3g driver and was using it before at the time of the error I posted at the beginning of this topic. So to follow up further on my last post, I shut down the server and moved the NTFS drive back to the SASLP-MV8 controller. I have 2 of these controllers in my system and this NTFS drive was on the "2nd" controller and was the only drive there. I brought the server back online and mounted the NTFS drive through unmenu disk management: /dev/sdi1 mounted on /mnt/disk/sdi1 Using command: mount -r -o umask=111,dmask=000 -t ntfs-3g /dev/sdi1 /mnt/disk/sdi1 2>&1 I then trying using rsync to copy some DVD .iso files from the NTFS drive to the unRAID disks and I got the same error as I posted above. It then occurred to me that the NTFS drive was on the 2nd controller and that the 2nd controller had not been used before. Maybe it's bad? So I powered down and moved the NTFS drive to the last open slot on the 1st SASLP-MV8 and went through the process again. I got the same error! So it would appear that copying from the NTFS drive connected to a mobo SATA port works just fine, but using the SASLP is a problem. I guess I can live with that, but it would be nice to know if others have seen a similar issue???

I'm using the ntfs that's part of 4.7 at the moment, but I did try ntfs-3g yesterday and still had the problem. However after browsing the forum some more I noticed something about 4.7 unRAID not being compatible with hot swap disks. So I stopped and powered down my system this evening. That took care of the hot swap factor. But at the same time I moved the nfts drive from the SASLP controller to one of the mobo SATA ports. I rebooted and remounted the drive through unmenu disk management. I then went into a screen session to start copying files and voila!, it's working now. Unfortunately I changed 2 variables at the same time, so I'll retry later by powering down and moving the drive back to the SASLP to confirm whether or not it was just the hot swap issue. And once confirmed I'll mark this as solved. Thanks!

Thanks for the lead - I can give that a shot this evening. But having said that will it make a difference relative to how I was already mounting the NTFS drive in my system? I just read the S.N.A.P. original topic and didn't see anything there to tell me how it might be different with respect to the error I saw. Also once I've transferred the data from the original NTFS drive I will be doing a preclear and adding that drive to my array.

So now that I have my new unRAID 4.7 server up and running I still have several drives left over from my WHSv1 server that contain data I need to transfer to unRAID. I have tried mounting one of those NTFS drives within the server itself using both the unMenu Disk Management approach, and using mount from a console. In either case when I start copying the files using rsync within a console the system errors out showing the syslog snippet below. My full syslog is also attached. If I take that same drive and install it on a Windows 7 box I can copy the files to my unRAID server over the network with no issues. Any suggestions as to what might be causing this? The NTFS drive is attached to one of my two SASLP-MV8 controllers. Oct 5 05:53:01 media-server kernel: ------------[ cut here ]------------ Oct 5 05:53:01 media-server kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308() Oct 5 05:53:01 media-server kernel: Hardware name: TH67B Oct 5 05:53:01 media-server kernel: Modules linked in: ntfs md_mod xor ahci r8169 mvsas libsas scst scsi_transport_sas Oct 5 05:53:01 media-server kernel: Pid: 5108, comm: smartctl Tainted: G W 2.6.32.9-unRAID #8 Oct 5 05:53:01 media-server kernel: Call Trace: Oct 5 05:53:01 media-server kernel: [<c102449e>] warn_slowpath_common+0x60/0x77 Oct 5 05:53:01 media-server kernel: [<c10244c2>] warn_slowpath_null+0xd/0x10 Oct 5 05:53:01 media-server kernel: [<c11b624d>] ata_qc_issue+0x10b/0x308 Oct 5 05:53:01 media-server kernel: [<c11ac0ba>] ? scsi_init_sgtable+0x5b/0x76 Oct 5 05:53:01 media-server kernel: [<c11ba260>] ata_scsi_translate+0xd1/0xff Oct 5 05:53:01 media-server kernel: [<c11a816c>] ? scsi_done+0x0/0xd Oct 5 05:53:01 media-server kernel: [<c11a816c>] ? scsi_done+0x0/0xd Oct 5 05:53:01 media-server kernel: [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7 Oct 5 05:53:01 media-server kernel: [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d Oct 5 05:53:01 media-server kernel: [<f842769a>] sas_queuecommand+0x65/0x20d [libsas] Oct 5 05:53:01 media-server kernel: [<c11a816c>] ? scsi_done+0x0/0xd Oct 5 05:53:01 media-server kernel: [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181 Oct 5 05:53:01 media-server kernel: [<c11ace4d>] scsi_request_fn+0x351/0x376 Oct 5 05:53:01 media-server kernel: [<c11269a8>] __generic_unplug_device+0x26/0x29 Oct 5 05:53:01 media-server kernel: [<c112934a>] blk_execute_rq_nowait+0x56/0x73 Oct 5 05:53:01 media-server kernel: [<c11293dc>] blk_execute_rq+0x75/0x91 Oct 5 05:53:01 media-server kernel: [<c11292cc>] ? blk_end_sync_rq+0x0/0x28 Oct 5 05:53:01 media-server kernel: [<c11295fa>] ? blk_recount_segments+0x16/0x24 Oct 5 05:53:01 media-server kernel: [<c11250c6>] ? blk_rq_bio_prep+0x47/0x78 Oct 5 05:53:01 media-server kernel: [<c11ac58a>] scsi_execute+0xbf/0x113 Oct 5 05:53:01 media-server kernel: [<c11bb6d0>] ata_cmd_ioctl+0xf8/0x1ba Oct 5 05:53:01 media-server kernel: [<c11bb940>] ata_sas_scsi_ioctl+0x1ae/0x1e8 Oct 5 05:53:01 media-server kernel: [<f842733d>] sas_ioctl+0x36/0x43 [libsas] Oct 5 05:53:01 media-server kernel: [<c11a94c8>] scsi_ioctl+0x299/0x2ad Oct 5 05:53:01 media-server kernel: [<f8427307>] ? sas_ioctl+0x0/0x43 [libsas] Oct 5 05:53:01 media-server kernel: [<c101d443>] ? enqueue_task_fair+0x96/0x9d Oct 5 05:53:01 media-server kernel: [<c11b326d>] sd_ioctl+0x80/0x8c Oct 5 05:53:01 media-server kernel: [<c112a420>] __blkdev_driver_ioctl+0x50/0x62 Oct 5 05:53:01 media-server kernel: [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc Oct 5 05:53:01 media-server kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Oct 5 05:53:01 media-server kernel: [<c112b0f8>] ? get_disk+0x4a/0x61 Oct 5 05:53:01 media-server kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Oct 5 05:53:01 media-server kernel: [<c1131e2d>] ? kobject_get+0x12/0x17 Oct 5 05:53:01 media-server kernel: [<c1192208>] ? get_device+0x11/0x18 Oct 5 05:53:01 media-server kernel: [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf Oct 5 05:53:01 media-server kernel: [<c104a179>] ? filemap_fault+0xb8/0x305 Oct 5 05:53:01 media-server kernel: [<c1048c43>] ? unlock_page+0x18/0x1b Oct 5 05:53:01 media-server kernel: [<c1057c63>] ? __do_fault+0x3a7/0x3da Oct 5 05:53:01 media-server kernel: [<c10757d4>] ? do_filp_open+0x3d8/0x6d1 Oct 5 05:53:01 media-server kernel: [<c105985f>] ? handle_mm_fault+0x42d/0x8f1 Oct 5 05:53:01 media-server kernel: [<c108b6c6>] block_ioctl+0x2a/0x32 Oct 5 05:53:01 media-server kernel: [<c108b69c>] ? block_ioctl+0x0/0x32 Oct 5 05:53:01 media-server kernel: [<c10769d5>] vfs_ioctl+0x22/0x67 Oct 5 05:53:01 media-server kernel: [<c1076f33>] do_vfs_ioctl+0x478/0x4ac Oct 5 05:53:01 media-server kernel: [<c106afbf>] ? fd_install+0x1e/0x43 Oct 5 05:53:01 media-server kernel: [<c106b14e>] ? do_sys_open+0xdc/0xe7 Oct 5 05:53:01 media-server kernel: [<c1076f93>] sys_ioctl+0x2c/0x45 Oct 5 05:53:01 media-server kernel: [<c1002935>] syscall_call+0x7/0xb Oct 5 05:53:01 media-server kernel: ---[ end trace 1301ecc83af4f640 ]--- syslog-2011-10-05.txt