alikuenkano Posted February 2, 2013 Share Posted February 2, 2013 Upgraded from 4.7 to rc11... All OK here... =) Quote Link to comment
MartinQ Posted February 2, 2013 Share Posted February 2, 2013 RC11a is up. I guess this should say, 'Changes from 5.0-rc11...' " Changes from 5.0-rc10 to 5.0-rc11a ---------------------------------- - shfs: return correct extended attribute value length - webGui: for 'FTP user(s)', permit multiple usernames separated by spaces " Quote Link to comment
RobJ Posted February 2, 2013 Share Posted February 2, 2013 RC11a is up. I guess this should say, 'Changes from 5.0-rc11...' " Changes from 5.0-rc10 to 5.0-rc11a ---------------------------------- - shfs: return correct extended attribute value length - webGui: for 'FTP user(s)', permit multiple usernames separated by spaces " This is NOT a good idea, mentioning this in a release thread. It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue. It would NOT be a good idea for others to use this unofficial version, and then want support for it. Please wait for an official statement from Tom. Quote Link to comment
limetech Posted February 2, 2013 Author Share Posted February 2, 2013 RC11a is up. I guess this should say, 'Changes from 5.0-rc11...' " Changes from 5.0-rc10 to 5.0-rc11a ---------------------------------- - shfs: return correct extended attribute value length - webGui: for 'FTP user(s)', permit multiple usernames separated by spaces " This is NOT a good idea, mentioning this in a release thread. It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue. It would NOT be a good idea for others to use this unofficial version, and then want support for it. Please wait for an official statement from Tom. Man nothing gets past you guys! Right this is just -rc11 with a couple bug fixes. Didn't want to start another multi-page post fest of, "damn another -rc, when's final???" I have to have some way to distribute these test releases for problems I can't readily reproduce in a timely manner. Once 5.0 has been released, I am going to adopt a different release scheme where I can quickly post releases that have only one or two changes, and get away from the -beta/-rc suffix scheme. Quote Link to comment
MartinQ Posted February 2, 2013 Share Posted February 2, 2013 Man nothing gets past you guys! ... Once 5.0 has been released, I am going to adopt a different release scheme where I can quickly post releases that have only one or two changes, and get away from the -beta/-rc suffix scheme. Thanks Tom. Oh, and you're welcome! Quote Link to comment
mvdzwaan Posted February 2, 2013 Share Posted February 2, 2013 Is it intended behaviour the FTP service does not honor user rights and/or share settings ? Everything gets published and everything is available to each account. Quote Link to comment
nars Posted February 2, 2013 Share Posted February 2, 2013 Yes, it's normal (for now), Tom did mention it. Quote Link to comment
Johnm Posted February 2, 2013 Share Posted February 2, 2013 Yesterday i had 2 more drives redball yesterday. I was unable to do anything with it since I am out of town. I had the server reboot from and older flash backup (RC5). it came right up all errors went away. I performed a parity check. zero errors. I copied a few GB to each individual disk, verified the copy and then deleted the data. zero errors. I need to upgrade the server again and see if i can recreate the issues. this will have to wait until i get back in a week or two.. Quote Link to comment
optiman Posted February 2, 2013 Share Posted February 2, 2013 wow Johnm - sounds scary to me. I would think it's not a hardware issue if you rollback and everything checks out ok. You list a few systems in your sig, which hardware had this issue with rc11? What mb, type of ram, sata cards? It sounds like a driver issue that was changed in recent releases. In any case, I hope you return soon with a syslog so it can be confirmed. redball drives are like the plague in unraid world. Quote Link to comment
pras1011 Posted February 2, 2013 Share Posted February 2, 2013 This is why I have stayed on rc5. Rc6 and rc8 have reballed one drive for no reason. Quote Link to comment
Johnm Posted February 2, 2013 Share Posted February 2, 2013 Hardware was X9 SCM Xeon 1240 RAM (4 GB when a VM and 32 when bare metal) 1x M1015 (with 4 drives) 2x SASLP-MV8 (with 8 drives each) Original crash was under hypervisor. all subsequent reboots were as baremetal. Not having my original syslog is huge. that is the missing key to the issue. i swore i downloaded it to my laptop but i cant find it and it is not on my flash. hopefully there is a clue in the second reboot syslog. Quote Link to comment
RobJ Posted February 2, 2013 Share Posted February 2, 2013 Yesterday i had 2 more drives redball yesterday. I was unable to do anything with it since I am out of town. I had the server reboot from and older flash backup (RC5). it came right up all errors went away. I performed a parity check. zero errors. I copied a few GB to each individual disk, verified the copy and then deleted the data. zero errors. I need to upgrade the server again and see if i can recreate the issues. this will have to wait until i get back in a week or two.. This is extremely unlikely to have anything to do with a particular OS release! Disabled drives are caused by hard disk issues or cable issues or controller issues or power issues, almost never by software issues. It is extremely probable that your RC11 flash drive would have had the same positive results. Two red-balled drives is generally a problem with the controller card that both are connected to, or one had issues and is on an IDE channel (emulated or real) and took down the other, or there was a power issue such as an electrical spike of significant size, or someone was messing with the cables or they were bad or loose. About the only time I can remember when it was software related, was because of a lost interrupt, which could be because of a motherboard or card BIOS problem or a buggy driver, and this has been extremely rare. The most important syslog is the one that covers the period where the issue happened, so I really hope you do find it. Now that it is working OK, I suspect we won't be able to see anything in new syslogs. Fellow users, please don't cause panics unnecessarily, before anyone has had time to investigate. Hard disk issues are just hard disk issues, and happen with every operating system (that accesses hard disks!). This is why I have stayed on rc5. Rc6 and rc8 have reballed one drive for no reason. Without more information, I would respectfully but strongly recommend you upgrade to RC11, not go back to RC5, not that any of these releases would have anything to do with your red balls. If we could see the syslogs relevant to those red balls, perhaps we could determine what is happening to that drive. At this point, I cannot think of any way that there is a connection to any particular release. At some point, it might be best to take this support issue to its own thread, as it is very unlikely to be related to RC11. Quote Link to comment
limetech Posted February 2, 2013 Author Share Posted February 2, 2013 Is it intended behaviour the FTP service does not honor user rights and/or share settings ? Yes that is a limitation at present. Everything gets published and everything is available to each account. That should not be true in -rc11. Only the user specified in the "FTP user(s)" field should be allowed access (though that user will have full access as mentioned above). In -rc11a you can enter a list of users separated by spaces. Prior to -rc11 any user could access via FTP. The FTP app on the Network Services page along with this functionality was added in rc11 precisely to "lock down" FTP so that only a specific user could access via FTP - otherwise known as a "bandaid solution" Quote Link to comment
mvdzwaan Posted February 2, 2013 Share Posted February 2, 2013 Everything gets published and everything is available to each account. That should not be true in -rc11. Only the user specified in the "FTP user(s)" field should be allowed access (though that user will have full access as mentioned above). In -rc11a you can enter a list of users separated by spaces. Prior to -rc11 any user could access via FTP. The FTP app on the Network Services page along with this functionality was added in rc11 precisely to "lock down" FTP so that only a specific user could access via FTP - otherwise known as a "bandaid solution" You're right, only the ftp specific users get all rights. I circumvented my problem with using it by changing the local root to the desired user share. With all its limitations it's actually exactly enough for what I wanted to do with ftp. Quote Link to comment
Johnm Posted February 3, 2013 Share Posted February 3, 2013 This is extremely unlikely to have anything to do with a particular OS release! In general this is the case, but we have seen more then once it was a driver error (or driver error with a certain hardware firmware) taking out an entire controller. this very system was plagued with the same errors back in 5B6 was it? It did turn out to be a bug. changing of kernels and drivers can had odd unpredictable (and sometimes hard to replicate) effects. the fact that all of the drives showing issues were on a single SAS plug would make me think bad backplane or loose wire (hard to say wire on system thats been racked for months). the flashdrive passed windows scan disks. the fact that i have now run 2 parity checks (correct off) after the downgrade with no hardware errors (but yes there are sync errors) has me thinking it is not a hardware issue. this is not my main concern. my concern was that unraid appeared to be correcting parity AFTER a failed Drive/controller. (and yes i could be very wrong about , i need the log files) After downgrading. i have run parity checks twice and will a third time. every time it is showing the same 500ish sync errors each pass the question i have; are these sync errors because unraid adjusted parity after a dropped controller or because files were written to the redballed system and it lost track of them after the system unflagged the drive. Quote Link to comment
RobJ Posted February 3, 2013 Share Posted February 3, 2013 This is extremely unlikely to have anything to do with a particular OS release! In general this is the case, but we have seen more then once it was a driver error (or driver error with a certain hardware firmware) taking out an entire controller. this very system was plagued with the same errors back in 5B6 was it? It did turn out to be a bug. You are right, that is rare, but possible. Usually though, it's a known quantity, a specific driver/controller/etc combination, known to be suspect. You would know if you have a suspect condition. The other issues you mention do concern me, but I believe they are being reported/discussed elsewhere, so I won't touch them here. Quote Link to comment
Albin Posted February 3, 2013 Share Posted February 3, 2013 I did the following for this upgrade (after first backing up the flash drive) Copied the files bzimage and bzroot from the zip file to the root of your flash device Deleted config/passwd Deleted config/shadow Deleted config/smbpasswd Delete the file config/super.dat Booted up server re-assign hard drives to their correct device location The cache disk was already assigned to its correct location I am not seeing "Stopped Configuration Valid" but rather "Stopped. Initial configuration" I do not see "MBR: error", or "MBR: unknown" I have attached a syslog I am getting Blue Balls next to each of the devices (except for cache and flash... they are green) Do I need to check the box "Parity is Valid" and then click "START" next to "Start will record all disk information, bring the array on-line, and start Parity-Sync (if parity is present). The array is immediately available, but is unprotected until Parity-Sync completes."? I did not click on "Identify" tower2_syslog.txt Quote Link to comment
limetech Posted February 3, 2013 Author Share Posted February 3, 2013 I did the following for this upgrade (after first backing up the flash drive) Copied the files bzimage and bzroot from the zip file to the root of your flash device Deleted config/passwd Deleted config/shadow Deleted config/smbpasswd Delete the file config/super.dat Booted up server re-assign hard drives to their correct device location The cache disk was already assigned to its correct location I am not seeing "Stopped Configuration Valid" but rather "Stopped. Initial configuration" I do not see "MBR: error", or "MBR: unknown" I have attached a syslog I am getting Blue Balls next to each of the devices (except for cache and flash... they are green) Do I need to check the box "Parity is Valid" and then click "START" next to "Start will record all disk information, bring the array on-line, and start Parity-Sync (if parity is present). The array is immediately available, but is unprotected until Parity-Sync completes."? I did not click on "Identify" You didn't need to delete 'super.dat', but no mater. If you are certain parity is assigned correctly click 'Start'. Quote Link to comment
PeterB Posted February 3, 2013 Share Posted February 3, 2013 I did the following for this upgrade (after first backing up the flash drive) Copied the files bzimage and bzroot from the zip file to the root of your flash device Deleted config/passwd Deleted config/shadow Deleted config/smbpasswd Delete the file config/super.dat Booted up server ..... You didn't need to delete 'super.dat', but no mater. If you are certain parity is assigned correctly click 'Start'. Since the flash drive was backed up, Albin should be able to re-instate the super.dat file. Quote Link to comment
Albin Posted February 3, 2013 Share Posted February 3, 2013 I did the following for this upgrade (after first backing up the flash drive) Copied the files bzimage and bzroot from the zip file to the root of your flash device Deleted config/passwd Deleted config/shadow Deleted config/smbpasswd Delete the file config/super.dat Booted up server ..... You didn't need to delete 'super.dat', but no mater. If you are certain parity is assigned correctly click 'Start'. Since the flash drive was backed up, Albin should be able to re-instate the super.dat file. I did back up the flash drive, so I just restored config/super.dat and now all the drives are green balled, and I am getting "configuration valid" I originally went from 4.7 to 5.0-beta12a a long time back, and had some issues with permissions. With this upgrade, I did not see specific instructions for going from 5.0-beta12a to 5.0-rc11, so I thought I may need to get rid of the Super.dat file and doing so might in someway help with my permissions issue (I am only guessing at that though). Should I keep the old super.dat (the one I restored) or should I remove it and do a "start" with out the super.dat file? I will hold off on starting the array, until I hear back. Thanks for your input on this Albin Quote Link to comment
trurl Posted February 3, 2013 Share Posted February 3, 2013 I did back up the flash drive, so I just restored config/super.dat and now all the drives are green balled, and I am getting "configuration valid" I originally went from 4.7 to 5.0-beta12a a long time back, and had some issues with permissions. With this upgrade, I did not see specific instructions for going from 5.0-beta12a to 5.0-rc11, so I thought I may need to get rid of the Super.dat file and doing so might in someway help with my permissions issue (I am only guessing at that though). Should I keep the old super.dat (the one I restored) or should I remove it and do a "start" with out the super.dat file? I will hold off on starting the array, until I hear back. Thanks for your input on this Albin Keep it like it is. Your configuration is valid. When you removed super.dat before you made it forget all about your configuration and so it saw everything as new disks. Now you are back to normal. There is a link in the first post of this thread with the release notes. See the section labeled All previous 5.0-beta and 5.0-rc versions including 5.0-rc8a Specifically, you need to run the the New Permissions Utility. It will take a while. Don't close the browser window until it completes. Quote Link to comment
PeterB Posted February 3, 2013 Share Posted February 3, 2013 Specifically, you need to run the the New Permissions Utility. It will take a while. Don't close the browser window until it completes. The problem with running the New Permissions script is that it clobbers everything. Some applications need ownership/permissions different to those which the script imposes. For instance, my mail folders don't use the default settings, nor the SqueezeboxServer files. I'm wary, in particular, of disrupting my mail and so have not run the New Permissions. In any case, there is still something in unRAID which sometimes makes files/directories inaccessible. For instance, I ran mkvmerge on my Ubuntu desktop, the other evening, writing the output file to a user share on unRAID. That process completed normally. I then went to open the share I'd just written to, and I no longer had permission to read it. I know that all the files are there, including the new one, because I can still access them via disk shares and from a telnet session. I have detailed this problem on the forum in the past, but no one seems to have picked up on it - it also happens when I run jdownloader on the Ubuntu desktop, writing to user shares. Quote Link to comment
pantner Posted February 3, 2013 Share Posted February 3, 2013 RC11a is up. I guess this should say, 'Changes from 5.0-rc11...' " Changes from 5.0-rc10 to 5.0-rc11a ---------------------------------- - shfs: return correct extended attribute value length - webGui: for 'FTP user(s)', permit multiple usernames separated by spaces " This is NOT a good idea, mentioning this in a release thread. It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue. It would NOT be a good idea for others to use this unofficial version, and then want support for it. Please wait for an official statement from Tom. Man nothing gets past you guys! Right this is just -rc11 with a couple bug fixes. Didn't want to start another multi-page post fest of, "damn another -rc, when's final???" I have to have some way to distribute these test releases for problems I can't readily reproduce in a timely manner. Once 5.0 has been released, I am going to adopt a different release scheme where I can quickly post releases that have only one or two changes, and get away from the -beta/-rc suffix scheme. is this available for download? been having some issues with my RC8 install, think I have it all sorted (running a data rebuild and will then do a parity check) and want to upgrade to the latest RC. Quote Link to comment
RobJ Posted February 3, 2013 Share Posted February 3, 2013 Changes from 5.0-rc10 to 5.0-rc11a ---------------------------------- - shfs: return correct extended attribute value length - webGui: for 'FTP user(s)', permit multiple usernames separated by spaces is this available for download? been having some issues with my RC8 install, think I have it all sorted (running a data rebuild and will then do a parity check) and want to upgrade to the latest RC. Are you having issues specifically with shfs and extended attributes, or with multiple users and vsftp? If not, then you should upgrade to RC11, found in the first post of this thread. Quote Link to comment
mikejp Posted February 3, 2013 Share Posted February 3, 2013 http://download.lime-technology.com/download/ Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.