JohnO Posted June 7, 2015 Share Posted June 7, 2015 Upgrading from 5.0.6 to 6.0-rc4. Which method did you use to upgrade? Did you format your flash drive, or manually move things around? I did the whole format process moving from 5.0.6 a few weeks ago, and it went very smoothly. Link to comment
trurl Posted June 7, 2015 Share Posted June 7, 2015 Upgrading from 5.0.6 to 6.0-rc4. Which method did you use to upgrade? Did you format your flash drive, or manually move things around? I did the whole format process moving from 5.0.6 a few weeks ago, and it went very smoothly. Did you clear your browser cache? Link to comment
Joe L. Posted June 7, 2015 Share Posted June 7, 2015 Upgrading from 5.0.6 to 6.0-rc4. Which method did you use to upgrade? Did you format your flash drive, or manually move things around? I did the whole format process moving from 5.0.6 a few weeks ago, and it went very smoothly. Did you clear your browser cache? I did not. But clearing it made no difference. (I just tried) I did not do a complete reformat. I did rename everything and disable everything, and never used dynamix ever previously. Link to comment
trurl Posted June 7, 2015 Share Posted June 7, 2015 There is this wiki: Upgrading to UnRAID v6 Link to comment
limetech Posted June 7, 2015 Author Share Posted June 7, 2015 Upgrading from 5.0.6 to 6.0-rc4. Many small issues... Are you sure there is nothing being installed via /boot/plugins or /boot/config/plugins or your 'go' file? We are working on an unRaid-5 style plugin that will upgrade unRaid-5 to unRaid-6 upon installation. Link to comment
Joe L. Posted June 7, 2015 Share Posted June 7, 2015 There is this wiki: Upgrading to UnRAID v6 Yes, I know, and I followed its instructions specifically. (and followed the section for ADVANCED users who did not wish to re-format the flash drive.) Tom... root@Tower:~# ls -l /boot/extra total 0 root@Tower:~# ls -l /boot/plugins total 352 -rwxrwxrwx 1 root root 1510 Aug 10 2013 webGui-latest.plg* -rwxrwxrwx 1 root root 333600 Aug 10 2013 webGui-latest.txz* root@Tower:~# grep -v "#" /boot/config/go /usr/local/sbin/emhttp & root@Tower:~# I'm guessing the files in the plugins directory should not be there. (I've never used unRAID plugins, so I'm guessing these were for the stock unRAID interface) I did not install them specifically, I did copy the "plugins folder from the distribution to the flash drive, but that would have left previous contents. I'll try removing those two files and let you know what happens when I reboot. Joe L. Link to comment
Joe L. Posted June 7, 2015 Share Posted June 7, 2015 I'll try removing those two files and let you know what happens when I reboot. Joe L. That was it. I'll update the wiki to make it more clear for the next "expert" Joe L. Link to comment
RobJ Posted June 7, 2015 Share Posted June 7, 2015 However, there appears to be a state where the drive spin status is considered 'spun down', yet the drive is spinning, and temps are showing and being updated. That's what happened in both my and reggie's cases. Once in this state, it appears the 'monitor' process(?) won't check the spin status because it *thinks* it can't, because it *thinks* the drive is not spinning? But whatever process is obtaining the temps could either reset the spin status, or notify the 'monitor' that the drive must be spinning. It would be nice if one of the processes above (like monitor?) would just use 'hdparm -C' to check, but perhaps that command is problematic with Areca's and other non-standard controllers? Just trying to get everything back in sync (displayed status with true status) ... Some logic has been built in emhttp to keep track of the disk being active/stand-by and the updating of the disk temperature. Both monitor and webGUI rely on this logic for proper handling and display of the temperatures. If/when something goes out of sync, it is usually restored when the poll_attribute timer kicks-in. That sounds great, what *should* happen, but isn't. My poll_attribute has been set to either 180 or 60, and I've waited many hours, with no change. Happened again yesterday, 4 drives only. Happened to at least 2 or 3 of the drives when I was checking the Help text for SMART info, after clicking on the drive, with the Help enabled. It briefly seemed to indicate SMART info would not be available until drive was spun up, then in a few seconds the SMART info all appeared (looked really great by the way, with a new Download button!). Returned to the Main screen, and drive still showed spun down (grey ball), but a temp was showing! The temp continued to show and be updated for quite a few hours. (I know by now you must be getting tired of my posts!) Link to comment
craigr Posted June 7, 2015 Share Posted June 7, 2015 Wonderful release. I love the new disc settings layout page with all the SMART information displayed. I like the changes to the shares page as well. Because of the improved GUI I discovered a share that was not private that definitely should have been! The new GUI made that obvious right away. Thanks guys, craigr Link to comment
RobJ Posted June 8, 2015 Share Posted June 8, 2015 Howdy Joe L, great to see you back! First, "failed to load COM32 file menu.c32 when I first attempted to boot my flash drive. To get it to boot I had to copy menu.c32 from the syslinux folder on the flash drive to the root of the flash drive. Between early v5 betas and the current v6, syslinux support has been updated a couple of times, and moved to the syslinux folder, but without any announcements. So at some point in the progression from v4.7 to the current, I believe everyone has run into one of several problems related to that, and had to make the necessary tweaks. The syslinux updates required a larger buffer for booting, so sooner or later most of us have done an upgrade, but failed to boot, and needed to run syslinux (usually through make_bootable) to update the support. The other problem was that in v5.0.4, all syslinux support files were moved to a syslinux folder, causing the problem you saw. Most of us veterans just copy bzroot et al, so it didn't immediately affect us, but sooner or later again, we needed to manually update our flash drives and syslinux.cfg to use the new location. That's another reason, among others, that we now strongly recommend reformatting the flash and starting fresh. It appears to me as if going straight from 5.0.6 to 6-rc4 is going to be an issue for some. That is true, no matter what release you come from, and the main reason I started the upgrade guide (with help from many others). But I knew there were users like you and me, old crusty veterans who would refuse to re-format! I'm afraid you may have been the first user, the first beta tester of that no-format section! I can see I need to add a few more comments to it, if you don't do it yourself. It needs a comment that there may be one or more of the folders with files in them that you the user did not put there, and they too have to be removed! Plus, it needs a comment explaining the syslinux move, how it's all in the syslinux folder now, and any older syslinux files need to be removed from the root. Once Tom releases the v5 to v6 upgrade plugin, I'll need to update the guide for that too. Link to comment
ponack Posted June 8, 2015 Share Posted June 8, 2015 So far RC4 has been pretty rock solid for me. I'm taking upgrading my motherboard\CPU\RAM shortly simply to take more advantage than I already am of the Virtualization\Docker options - I just have to say, nice work guys, the hard work really shows! Link to comment
alt Posted June 8, 2015 Share Posted June 8, 2015 Upgrading from 6.0b15 to RC4 from the WebGui plugin page. How long should the update take to complete? System has been steady at "syncing..." for 20+min. *Update* I Closed the Update window that was still showing "syncing..." Reboot Required showed up. After Reboot RC4 came up. Link to comment
bonienl Posted June 8, 2015 Share Posted June 8, 2015 However, there appears to be a state where the drive spin status is considered 'spun down', yet the drive is spinning, and temps are showing and being updated. That's what happened in both my and reggie's cases. Once in this state, it appears the 'monitor' process(?) won't check the spin status because it *thinks* it can't, because it *thinks* the drive is not spinning? But whatever process is obtaining the temps could either reset the spin status, or notify the 'monitor' that the drive must be spinning. It would be nice if one of the processes above (like monitor?) would just use 'hdparm -C' to check, but perhaps that command is problematic with Areca's and other non-standard controllers? Just trying to get everything back in sync (displayed status with true status) ... Some logic has been built in emhttp to keep track of the disk being active/stand-by and the updating of the disk temperature. Both monitor and webGUI rely on this logic for proper handling and display of the temperatures. If/when something goes out of sync, it is usually restored when the poll_attribute timer kicks-in. That sounds great, what *should* happen, but isn't. My poll_attribute has been set to either 180 or 60, and I've waited many hours, with no change. Happened again yesterday, 4 drives only. Happened to at least 2 or 3 of the drives when I was checking the Help text for SMART info, after clicking on the drive, with the Help enabled. It briefly seemed to indicate SMART info would not be available until drive was spun up, then in a few seconds the SMART info all appeared (looked really great by the way, with a new Download button!). Returned to the Main screen, and drive still showed spun down (grey ball), but a temp was showing! The temp continued to show and be updated for quite a few hours. (I know by now you must be getting tired of my posts!) Yeah for every one line answer I get ten lines of questions back, that is a heavy burden But ... you did make an interesting observation ! When users look at the SMART information in the GUI, the GUI will issue a smartctl command in the background to obtain the necessary information. This is done without knowledge to emhttp itself and it can bring emhttp out of sync if a disk got spun-up due to an executed SMART command (do you happen to have Seagate disks?) It seems that the poll attribute timer updates the temperature reading for an active disk (it uses hdparm and smartctl for that), but emhttp itself doesn't get updated about the state of the disk if it has changed. I believe Tom made a remark about that, and advises to let control of disk spin-up/spin-down solely be done by emhttp. A solution might be to extend the poll attribute functionality with a disk state update feature if changed state is detected, this approach doesn't give an immediate sync but at least at some point things get straightened. This however is up to LT to decide/implement. Perhaps a 'defect report' can help? Link to comment
johnodon Posted June 8, 2015 Share Posted June 8, 2015 I honestly don't know if this is RC4 related... I see this in my syslog: Jun 8 06:33:52 unRAID ntpd[1855]: kernel reports TIME_ERROR: 0x41: pll unsync Resource temporarily unavailable I have enabled NTP on my unraid box and it points to my pfsense box which is running as an NTP server: Link to comment
sparklyballs Posted June 8, 2015 Share Posted June 8, 2015 I honestly don't know if this is RC4 related... I see this in my syslog: Jun 8 06:33:52 unRAID ntpd[1855]: kernel reports TIME_ERROR: 0x41: pll unsync Resource temporarily unavailable I have enabled NTP on my unraid box and it points to my pfsense box which is running as an NTP server: i also use my pfsense as an NTP server and have these entries in my log, some predate rc4. Link to comment
archedraft Posted June 8, 2015 Share Posted June 8, 2015 Seems like when trying to "edit XML" a stopped VM sometimes kills unraids GUI. I have to close the web browser and try again. Sometimes it does work though? Link to comment
RobJ Posted June 8, 2015 Share Posted June 8, 2015 I honestly don't know if this is RC4 related... I see this in my syslog: Jun 8 06:33:52 unRAID ntpd[1855]: kernel reports TIME_ERROR: 0x41: pll unsync Resource temporarily unavailable I have enabled NTP on my unraid box and it points to my pfsense box which is running as an NTP server: I get exactly the same, beginning with 6.0-rc1. I do not have pfsense here, but I do point my NTP to my NTP server, which is my Windows box, my only always-on box. It appears to be harmless. Link to comment
trurl Posted June 8, 2015 Share Posted June 8, 2015 ... I do point my NTP to my NTP server, which is my Windows box, my only always-on box... I do the opposite. My unRAID gets its time from internet, and my PC gets its time from unRAID. Link to comment
garycase Posted June 9, 2015 Share Posted June 9, 2015 Hmm, all of my shares show the yellow triangle meaning: Some or all files are on unprotected storage.... Parity is ok and I'm not using a cache drive. Any ideas? This is a known bug => I reported it very early in this thread; others have noted the same; and Tom is aware of it ... ... Yeah that's a bug. Just confirmed that RC5 resolves this display issue => the shares now show the correct status. I've confirmed with/without parity, but don't have a cache drive assigned, so can't confirm the impact it has ... but I suspect all is well. Link to comment
JimPhreak Posted June 11, 2015 Share Posted June 11, 2015 I can report that RC4 running on ESXi still gives this error in syslog over and over again: kernel: usb 1-1: reset high-speed USB device number 2 using ehci-pci I can report that I'm having this same issue but it appears to be more of a VMware issue as the vmkernel.log shows the same errors even when connecting the USB to a Windows VM as opposed to unRAID. Trying to determine why it's doing this. Link to comment
jonp Posted June 12, 2015 Share Posted June 12, 2015 Similar to the beta15 thread, I'm locking this one as we are currently on rc5. We will make a habit of locking these as new releases are posted going forward. Link to comment
Recommended Posts